Re: [Freedreno] [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface
On 12/2/2022 4:27 AM, Bjorn Andersson wrote: > On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: > @Ulf, Akhil has a power-domain for a piece of hardware which may be > voted active by multiple different subsystems (co-processors/execution > contexts) in the system. > > As such, during the powering down sequence we don't wait for the > power-domain to turn off. But in the event of an error, the recovery > mechanism relies on waiting for the hardware to settle in a powered off > state. > > The proposal here is to use the reset framework to wait for this state > to be reached, before continuing with the recovery mechanism in the > client driver. > > Given our other discussions on quirky behavior, do you have any > input/suggestions on this? > >> 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. > @Akhil, this description is fairly generic. As we've reached the state > where the hardware has settled and we return to the client, what > prevents it from being powered up again? > > Or is it simply a question of it hitting the powered-off state, not > necessarily staying there? Correct. It doesn't need to stay there. The intention is to hit the powered-off state at least once to clear all the internal hw states (basically a hw reset). -Akhil. > > Regards, > Bjorn > >> This series is rebased on top of qcom/linux:for-next branch. >> >> Related discussion: https://patchwork.freedesktop.org/patch/493144/ >> >> Changes in v7: >> - Update commit message (Bjorn) >> - Rebased on top of qcom/linux:for-next branch. >> >> Changes in v6: >> - No code changes in this version. Just captured the Acked-by tags >> >> Changes in v5: >> - Nit: Remove a duplicate blank line (Krzysztof) >> >> Changes in v4: >> - Update gpu dt-binding schema >> - Typo fix in commit text >> >> Changes in v3: >> - Use pointer to const for "struct qcom_reset_ops" in qcom_reset_map >> (Krzysztof) >> >> Changes in v2: >> - Return error when a particular custom reset op is not implemented. (Dmitry) >> >> Akhil P Oommen (6): >> dt-bindings: clk: qcom: Support gpu cx gdsc reset >> clk: qcom: Allow custom reset ops >> clk: qcom: gdsc: Add a reset op to poll gdsc collapse >> clk: qcom: gpucc-sc7280: Add cx collapse reset support >> dt-bindings: drm/msm/gpu: Add optional resets >> arm64: dts: qcom: sc7280: Add Reset support for gpu >> >> .../devicetree/bindings/display/msm/gpu.yaml | 6 + >> 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| 10 >> drivers/clk/qcom/reset.c | 27 >> +- >> drivers/clk/qcom/reset.h | 8 +++ >> include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++ >> 8 files changed, 82 insertions(+), 5 deletions(-) >> >> -- >> 2.7.4 >>
Re: [PATCH v7 0/5] Add data-lanes and link-frequencies to dp_out endpoint
On 02/12/2022 00:17, Kuogee Hsieh wrote: Add DP both data-lanes and link-frequencies property to dp_out endpoint and support functions to DP driver. Kuogee Hsieh (5): arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint dt-bindings: msm/dp: add data-lanes and link-frequencies property drm/msm/dp: parser data-lanes as property of dp_out endpoint drm/msm/dp: parser link-frequencies as property of dp_out endpoint drm/msm/dp: add support of max dp link rate Also, please fix the email address list you are using. .../bindings/display/msm/dp-controller.yaml| 22 + arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +++- arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +++- drivers/gpu/drm/msm/dp/dp_display.c| 4 +++ drivers/gpu/drm/msm/dp/dp_panel.c | 7 ++-- drivers/gpu/drm/msm/dp/dp_panel.h | 1 + drivers/gpu/drm/msm/dp/dp_parser.c | 38 ++ drivers/gpu/drm/msm/dp/dp_parser.h | 2 ++ 8 files changed, 68 insertions(+), 18 deletions(-) -- With best wishes Dmitry
Re: [PATCH v7 0/5] Add data-lanes and link-frequencies to dp_out endpoint
On 02/12/2022 00:17, Kuogee Hsieh wrote: Add DP both data-lanes and link-frequencies property to dp_out endpoint and support functions to DP driver. Kuogee Hsieh (5): arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint dt-bindings: msm/dp: add data-lanes and link-frequencies property drm/msm/dp: parser data-lanes as property of dp_out endpoint drm/msm/dp: parser link-frequencies as property of dp_out endpoint drm/msm/dp: add support of max dp link rate Patches 1-3 are missing, patches 4 and 5 don't have proper threading. Please resend the whole series using a single git send-email command. .../bindings/display/msm/dp-controller.yaml| 22 + arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +++- arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +++- drivers/gpu/drm/msm/dp/dp_display.c| 4 +++ drivers/gpu/drm/msm/dp/dp_panel.c | 7 ++-- drivers/gpu/drm/msm/dp/dp_panel.h | 1 + drivers/gpu/drm/msm/dp/dp_parser.c | 38 ++ drivers/gpu/drm/msm/dp/dp_parser.h | 2 ++ 8 files changed, 68 insertions(+), 18 deletions(-) -- With best wishes Dmitry
[git pull] drm fixes for 6.1-rc8
Hi Linus, Things do seem to have finally settled down, just 4 i915 and one amdgpu this week. Probably won't have much for next week if you do push rc8 out. Dave. drm-fixes-2022-12-02: drm fixes for 6.1-rc8 i915: - Fix dram info readout - Remove non-existent pipes from bigjoiner pipe mask - Fix negative value passed as remaining time - Never return 0 if not all requests retired amdgpu: - VCN fix for vangogh The following changes since commit b7b275e60bcd5f89771e865a8239325f86d9927d: Linux 6.1-rc7 (2022-11-27 13:31:48 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-12-02 for you to fetch changes up to c082fbd687ad70a92e0a8be486a7555a66f03079: Merge tag 'amd-drm-fixes-6.1-2022-12-01' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2022-12-02 09:12:46 +1000) drm fixes for 6.1-rc8 i915: - Fix dram info readout - Remove non-existent pipes from bigjoiner pipe mask - Fix negative value passed as remaining time - Never return 0 if not all requests retired amdgpu: - VCN fix for vangogh Dave Airlie (2): Merge tag 'drm-intel-fixes-2022-12-01' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'amd-drm-fixes-6.1-2022-12-01' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Janusz Krzysztofik (2): drm/i915: Fix negative value passed as remaining time drm/i915: Never return 0 if not all requests retired Leo Liu (1): drm/amdgpu: enable Vangogh VCN indirect sram mode Radhakrishna Sripada (1): drm/i915/mtl: Fix dram info readout Ville Syrjälä (1): drm/i915: Remove non-existent pipes from bigjoiner pipe mask drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 3 +++ drivers/gpu/drm/i915/display/intel_display.c | 10 +++--- drivers/gpu/drm/i915/gt/intel_gt.c | 9 +++-- drivers/gpu/drm/i915/gt/intel_gt_requests.c | 2 +- drivers/gpu/drm/i915/intel_dram.c| 3 +-- 5 files changed, 19 insertions(+), 8 deletions(-)
Re: [PATCH] drm/fourcc: Document open source user waiver
Acked-by: Bas Nieuwenhuizen
On Thu, Dec 1, 2022 at 8:47 PM Jason Ekstrand wrote:
>
> Acked-by: Jason Ekstrand
>
> On Thu, Dec 1, 2022 at 4:22 AM Daniel Vetter wrote:
>>
>> On Thu, 1 Dec 2022 at 11:07, Daniel Vetter wrote:
>> >
>> > On Wed, Nov 23, 2022 at 08:24:37PM +0100, Daniel Vetter wrote:
>> > > It's a bit a FAQ, and we really can't claim to be the authoritative
>> > > source for allocating these numbers used in many standard extensions
>> > > if we tell closed source or vendor stacks in general to go away.
>> > >
>> > > Iirc this was already clarified in some vulkan discussions, but I
>> > > can't find that anywhere anymore. At least not in a public link.
>> > >
>> > > Cc: Maarten Lankhorst
>> > > Cc: Maxime Ripard
>> > > Cc: Thomas Zimmermann
>> > > Cc: David Airlie
>> > > Cc: Daniel Vetter
>> > > Cc: Alex Deucher
>> > > Cc: Daniel Stone
>> > > Cc: Bas Nieuwenhuizen
>> > > Cc: Jason Ekstrand
>> > > Cc: Neil Trevett
>> > > Signed-off-by: Daniel Vetter
>> >
>> > From irc:
>> >
>> > danvet: ack from me
>>
>> Also from irc:
>>
>> danvet: Acked
>>
>> -Daniel
>>
>> > > ---
>> > > include/uapi/drm/drm_fourcc.h | 12
>> > > 1 file changed, 12 insertions(+)
>> > >
>> > > diff --git a/include/uapi/drm/drm_fourcc.h
>> > > b/include/uapi/drm/drm_fourcc.h
>> > > index bc056f2d537d..de703c6be969 100644
>> > > --- a/include/uapi/drm/drm_fourcc.h
>> > > +++ b/include/uapi/drm/drm_fourcc.h
>> > > @@ -88,6 +88,18 @@ extern "C" {
>> > > *
>> > > * The authoritative list of format modifier codes is found in
>> > > * `include/uapi/drm/drm_fourcc.h`
>> > > + *
>> > > + * Open Source User Waiver
>> > > + * ---
>> > > + *
>> > > + * Because this is the authoritative source for pixel formats and
>> > > modifiers
>> > > + * referenced by GL, Vulkan extensions and other standards and hence
>> > > used both
>> > > + * by open source and closed source driver stacks, the usual
>> > > requirement for an
>> > > + * upstream in-kernel or open source userspace user does not apply.
>> > > + *
>> > > + * To ensure, as much as feasible, compatibility across stacks and avoid
>> > > + * confusion with incompatible enumerations stakeholders for all
>> > > relevant driver
>> > > + * stacks should approve additions.
>> > > */
>> > >
>> > > #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
>> > > --
>> > > 2.37.2
>> > >
>> >
>> > --
>> > Daniel Vetter
>> > Software Engineer, Intel Corporation
>> > http://blog.ffwll.ch
>>
>>
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
[PATCH v7 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915
Starting with MTL, there will be two GT-tiles, a render and media tile. PXP as a service for supporting workloads with protected contexts and protected buffers can be subscribed by process workloads on any tile. However, depending on the platform, only one of the tiles is used for control events pertaining to PXP operation (such as creating the arbitration session and session tear-down). PXP as a global feature is accessible via batch buffer instructions on any engine/tile and the coherency across tiles is handled implicitly by the HW. In fact, for the foreseeable future, we are expecting this single-control-tile for the PXP subsystem. In MTL, it's the standalone media tile (not the root tile) because it contains the VDBOX and KCR engine (among the assets PXP relies on for those events). Looking at the current code design, each tile is represented by the intel_gt structure while the intel_pxp structure currently hangs off the intel_gt structure. Keeping the intel_pxp structure within the intel_gt structure makes some internal functionalities more straight forward but adds code complexity to code readibility and maintainibility to many external-to-pxp subsystems which may need to pick the correct intel_gt structure. An example of this would be the intel_pxp_is_active or intel_pxp_is_enabled functionality which should be viewed as a global level inquiry, not a per-gt inquiry. That said, this series promotes the intel_pxp structure into the drm_i915_private structure making it a top-level subsystem and the PXP subsystem will select the control gt internally and keep a pointer to it for internal reference. Changes from prior revs: v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported because : [1] introduction of 'ctrl_gt' means we correct this for MTL's upcoming series now. [2] Also, this has little impact globally as its only used by PXP-internal callers at the moment. - Change intel_pxp_init/fini to take in i915 as its input to avoid ptr-to-ptr in init/fini calls.(Jani). - Remove the backpointer from pxp->i915 since we can use pxp->ctrl_gt->i915 if we need it. (Rodrigo). v5: - Switch from series to single patch (Rodrigo). - change function name from pxp_get_kcr_owner_gt to pxp_get_ctrl_gt. - Fix CI BAT failure by removing redundant call to intel_pxp_fini from driver-remove. - NOTE: remaining open still persists on using ptr-to-ptr and back-ptr. v4: - Instead of maintaining intel_pxp as an intel_gt structure member and creating a number of convoluted helpers that takes in i915 as input and redirects to the correct intel_gt or takes any intel_gt and internally replaces with the correct intel_gt, promote it to be a top-level i915 structure. v3: - Rename gt level helper functions to "intel_pxp_is_enabled/ supported/ active_on_gt" (Daniele) - Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is supported as the new intel_pxp_is_supported_on_gt to check for PXP feature support vs the tee support for huc authentication. Fix pxp-debugfs-registration to use only the former to decide support. (Daniele) - Couple minor optimizations. v2: - Avoid introduction of new device info or gt variables and use existing checks / macros to differentiate the correct GT->PXP control ownership (Daniele Ceraolo Spurio) - Don't reuse the updated global-checkers for per-GT callers (such as other files within PXP) to avoid unnecessary GT-reparsing, expose a replacement helper like the prior ones. (Daniele). v1: - Add one more patch to the series for the intel_pxp suspend/resume for similar refactoring Signed-off-by: Alan Previn --- .../drm/i915/display/skl_universal_plane.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +- drivers/gpu/drm/i915/gt/intel_gt.c| 5 -- drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 1 - drivers/gpu/drm/i915/gt/intel_gt_irq.c| 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 8 -- drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 - drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +- drivers/gpu/drm/i915/i915_driver.c| 18 + drivers/gpu/drm/i915/i915_drv.h | 7 +- drivers/gpu/drm/i915/pxp/intel_pxp.c | 74 +++ drivers/gpu/drm/i915/pxp/intel_pxp.h | 10 ++- drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 8 +- drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 44 +++ drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.h | 4 +- drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 10 ++- drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 4 +- drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 8 +-
[PATCH] drm: tidss: Fix pixel format definition
There was a long-standing bug from a typo that created 2 ARGB1555 and
ABGR1555 pixel format entries. Weston 10 has a sanity check that alerted
me to this issue.
According to the Supported Pixel Data formats table we have the later
entries should have been for Alpha-X instead.
Signed-off-by: Randolph Sapp
---
drivers/gpu/drm/tidss/tidss_dispc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index ad93acc9abd2..16301bdfead1 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -1858,8 +1858,8 @@ static const struct {
{ DRM_FORMAT_XBGR, 0x21, },
{ DRM_FORMAT_RGBX, 0x22, },
- { DRM_FORMAT_ARGB1555, 0x25, },
- { DRM_FORMAT_ABGR1555, 0x26, },
+ { DRM_FORMAT_XRGB1555, 0x25, },
+ { DRM_FORMAT_XBGR1555, 0x26, },
{ DRM_FORMAT_XRGB, 0x27, },
{ DRM_FORMAT_XBGR, 0x28, },
--
2.34.1
Re: [Intel-gfx] [PATCH v6 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915
i just realized nothing external to PXP is calling HAS_PXP so I'll probably drop this macro and create a helper for pxp_debugfs (the only caller). ...alan On Thu, 2022-12-01 at 23:55 +, Teres Alexis, Alan Previn wrote: > > On Tue, 2022-11-29 at 18:02 -0800, Teres Alexis, Alan Previn wrote: > Alan: [snip] > > + newpxp->ctrl_gt = pxp_get_ctrl_gt(newpxp->i915); > > + > > + if (!newpxp->ctrl_gt) > > + return -ENODEV; > > > > /* > > * If HuC is loaded by GSC but PXP is disabled, we can skip the init of > > * the full PXP session/object management and just init the tee channel. > > */ > > - if (HAS_PXP(gt->i915)) > > - pxp_init_full(pxp); > > - else if (intel_huc_is_loaded_by_gsc(>uc.huc) && > > intel_uc_uses_huc(>uc)) > > - intel_pxp_tee_component_init(pxp); > > + if (HAS_PXP(newpxp->i915)) > > + pxp_init_full(newpxp); > > I realize with rev6 now having pxp as top-level and defining ctrl_gt properly > in the header, its actually the correct > time to switch HAS_PXP(i915) to HAS_PXP(pxp) so we can check the VDBOX mask > on the ctrl_gt (instead of root gt as it is > now). This assures HAS_PXP continues to be a global-macro as was it was > originally intended. > > ...alan
Re: [PATCH v2 3/3] dt-bindings: display: panel: mipi-dbi-spi: Add io-supply
On Thu, 01 Dec 2022 17:02:45 +0100, Otto Pflüger wrote: > Add documentation for the new io-supply property, which specifies the > regulator for the I/O voltage supply on platforms where the panel > panel power and I/O supplies are separate. > > Signed-off-by: Otto Pflüger > --- > .../bindings/display/panel/panel-mipi-dbi-spi.yaml| 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
Re: [PATCH v6 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915
On Tue, 2022-11-29 at 18:02 -0800, Teres Alexis, Alan Previn wrote: Alan: [snip] > + newpxp->ctrl_gt = pxp_get_ctrl_gt(newpxp->i915); > + > + if (!newpxp->ctrl_gt) > + return -ENODEV; > > /* >* If HuC is loaded by GSC but PXP is disabled, we can skip the init of >* the full PXP session/object management and just init the tee channel. >*/ > - if (HAS_PXP(gt->i915)) > - pxp_init_full(pxp); > - else if (intel_huc_is_loaded_by_gsc(>uc.huc) && > intel_uc_uses_huc(>uc)) > - intel_pxp_tee_component_init(pxp); > + if (HAS_PXP(newpxp->i915)) > + pxp_init_full(newpxp); I realize with rev6 now having pxp as top-level and defining ctrl_gt properly in the header, its actually the correct time to switch HAS_PXP(i915) to HAS_PXP(pxp) so we can check the VDBOX mask on the ctrl_gt (instead of root gt as it is now). This assures HAS_PXP continues to be a global-macro as was it was originally intended. ...alan
Re: [PATCH V4 1/3] dt-bindings: display: panel: Add Samsung AMS495QA01
On Tue, 29 Nov 2022 11:29:10 -0600, Chris Morgan wrote: > From: Chris Morgan > > Add documentation for the Samsung AMS495QA01 panel. > > Signed-off-by: Chris Morgan > Signed-off-by: Maya Matuszczyk > --- > .../display/panel/samsung,ams495qa01.yaml | 57 +++ > 1 file changed, 57 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml > Reviewed-by: Rob Herring
[PATCH] [RFC] drm/etnaviv: Disable softpin
Currently softpin suffers from assorted race conditions exposed by newer
versions of mesa 22.2.y and 22.3.y . Those races are difficult to fix in
older kernel versions due to massive amount of backports necessary to do
so. Disable softpin by default until Linux 6.1.y is out, which contains
the necessary fixes to make softpin work reliably.
Fixes: 00ddc0b20 ("drm/etnaviv: implement softpin")
Signed-off-by: Marek Vasut
---
Cc: Christian Gmeiner
Cc: Daniel Vetter
Cc: David Airlie
Cc: Lucas Stach
Cc: Russell King
Cc: etna...@lists.freedesktop.org
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 51320eeebfcff..326c9696cccea 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -146,10 +146,7 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
param, u64 *value)
break;
case ETNAVIV_PARAM_SOFTPIN_START_ADDR:
- if (priv->mmu_global->version == ETNAVIV_IOMMU_V2)
- *value = ETNAVIV_SOFTPIN_START_ADDRESS;
- else
- *value = ~0ULL;
+ *value = ~0ULL;
break;
case ETNAVIV_PARAM_GPU_PRODUCT_ID:
--
2.35.1
Re: [PATCH v2 01/21] dt-bindings: display: tegra: add Tegra20 VIP
On Mon, Nov 28, 2022 at 04:23:16PM +0100, Luca Ceresoli wrote: > VIP is the parallel video capture component within the video input > subsystem of Tegra20 (and other Tegra chips, apparently). > > Signed-off-by: Luca Ceresoli > > --- > > Changed in v2 (suggested by Krzysztof Kozlowski): > - remove redundant "bindings" from subject line > - remove $nodename > - add channel@0 description > - add reg: const: 0 > --- > .../display/tegra/nvidia,tegra20-vip.yaml | 63 +++ > MAINTAINERS | 7 +++ > 2 files changed, 70 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml > > diff --git > a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml > b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml > new file mode 100644 > index ..44be2e16c9b4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml > @@ -0,0 +1,63 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-vip.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: NVIDIA Tegra VIP (parallel video capture) controller > + > +maintainers: > + - Luca Ceresoli > + > +properties: > + compatible: > +enum: > + - nvidia,tegra20-vip > + > + "#address-cells": > +const: 1 > + > + "#size-cells": > +const: 0 > + > + channel@0: Kind of odd there is only 1 channel with a unit-address. Are more channels coming? Please make the binding as complete as possible even if no driver support yet. > +description: parallel video capture interface for the VI > +type: object > + > +properties: > + reg: > +const: 0 > + > + ports: > +$ref: /schemas/graph.yaml#/properties/ports > + > +properties: > + port@0: > +$ref: /schemas/graph.yaml#/properties/port > +description: > + Port receiving the video stream from the sensor > + > + port@1: > +$ref: /schemas/graph.yaml#/properties/port > +description: > + Port sending the video stream to the VI > + > +required: > + - port@0 > + - port@1 > + > +additionalProperties: false A bit easier to read the indented cases if this is above 'properties'. > + > +required: > + - reg > + - ports > + > +unevaluatedProperties: false > + > +required: > + - compatible > + - "#address-cells" > + - "#size-cells" > + - channel@0 > + > +# see nvidia,tegra20-vi.yaml for an example > diff --git a/MAINTAINERS b/MAINTAINERS > index 69565ac0c224..92c762f85f17 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -20315,6 +20315,13 @@ S: Maintained > F: > Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml > F: drivers/staging/media/tegra-video/ > > +TEGRA VIDEO DRIVER FOR TEGRA20 VIP (PARALLEL VIDEO CAPTURE) > +M: Luca Ceresoli > +L: linux-me...@vger.kernel.org > +L: linux-te...@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml > + > TEGRA XUSB PADCTL DRIVER > M: JC Kuo > S: Supported > -- > 2.34.1 > >
Re: [PATCH v2 02/21] dt-bindings: display: tegra: vi: add 'vip' property and example
On Mon, Nov 28, 2022 at 04:23:17PM +0100, Luca Ceresoli wrote:
> The Tegra20 VI peripheral can receive parallel input from the VIP parallel
> input module. Add it to the allowed properties and augment the existing
> nvidia,tegra20-vi example to show a 'vip' property.
>
> Reviewed-by: Krzysztof Kozlowski
> Signed-off-by: Luca Ceresoli
>
> ---
>
> Changed in v2 (suggested by Krzysztof Kozlowski):
> - rename "i2c3" -> "ic2"
> - add review tag
> ---
> .../display/tegra/nvidia,tegra20-vi.yaml | 68 +++
> MAINTAINERS | 1 +
> 2 files changed, 69 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
> b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
> index 782a4b10150a..5b5583c2b562 100644
> --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
> @@ -74,6 +74,22 @@ properties:
>avdd-dsi-csi-supply:
> description: DSI/CSI power supply. Must supply 1.2 V.
>
> + vip:
> +$ref: /schemas/display/tegra/nvidia,tegra20-vip.yaml
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Input from the VIP (parallel input capture) module
> +
> +properties:
> + endpoint:
> +$ref: /schemas/graph.yaml#/properties/endpoint
You can drop 'endpoint'. You only need port nodes if there's no extra
properties in the endpoints.
> +
> patternProperties:
>"^csi@[0-9a-f]+$":
> type: object
> @@ -109,6 +125,22 @@ examples:
> #include
> #include
>
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +camera@48 {
> +compatible = "aptina,mt9v111";
> +reg = <0x48>;
> +clocks = <_clk>;
> +
> +port {
> +mt9v111_out: endpoint {
> +remote-endpoint = <_vip_in>;
> +};
> +};
> +};
> +};
> +
> vi@5408 {
> compatible = "nvidia,tegra20-vi";
> reg = <0x5408 0x0004>;
> @@ -116,6 +148,42 @@ examples:
> clocks = <_car TEGRA20_CLK_VI>;
> resets = <_car 100>;
> reset-names = "vi";
> +
> +vip {
> +compatible = "nvidia,tegra20-vip";
> +#address-cells = <1>;
> +#size-cells = <0>;
> +channel@0 {
> +reg = <0>;
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@0 {
> +reg = <0>;
> +vi_vip_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +port@1 {
> +reg = <1>;
> +vi_vip_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +};
> +};
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@0 {
> +reg = <0>;
> +vi_in: endpoint {
> +remote-endpoint = <_vip_out>;
> +};
> +};
> +};
> };
>
>- |
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 92c762f85f17..0c97ce22735d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20320,6 +20320,7 @@ M:Luca Ceresoli
> L: linux-me...@vger.kernel.org
> L: linux-te...@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
> F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml
>
> TEGRA XUSB PADCTL DRIVER
> --
> 2.34.1
>
>
Re: [PATCH v5 07/10] dt-bindings: phy: Add Cadence HDP-TX DP PHY
On Mon, Nov 28, 2022 at 03:36:15PM +0800, Sandor Yu wrote:
> Add bindings for Cadence HDP-TX DisplayPort PHY.
>
> Signed-off-by: Sandor Yu
> ---
> .../bindings/phy/cdns,hdptx-dp-phy.yaml | 68 +++
> 1 file changed, 68 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/phy/cdns,hdptx-dp-phy.yaml
>
> diff --git a/Documentation/devicetree/bindings/phy/cdns,hdptx-dp-phy.yaml
> b/Documentation/devicetree/bindings/phy/cdns,hdptx-dp-phy.yaml
> new file mode 100644
> index ..f4f741150c12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/cdns,hdptx-dp-phy.yaml
> @@ -0,0 +1,68 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/cdns,hdptx-dp-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence HDP-TX(HDMI/DisplayPort) PHY for DisplayPort protocol
> +
> +maintainers:
> + - Sandor Yu
> +
> +properties:
> + compatible:
> +enum:
> + - cdns,hdptx-dp-phy
Again, name based on SoC and SoC vendor.
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: PHY reference clock.
> + - description: APB clock.
> +
> + clock-names:
> +items:
> + - const: ref
> + - const: apb
> +
> + "#phy-cells":
> +const: 0
> +
> + cdns,num-lanes:
There is a standard way to define the number of lanes. That goes in
output endpoint for the DP node. Not that convenient to the phy, but the
information is already there, don't duplicate it.
> +description:
> + Number of lanes.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [1, 2, 3, 4]
> +default: 4
> +
> + cdns,max-bit-rate:
Same with this.
> +description:
> + Maximum DisplayPort link bit rate to use, in Mbps
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [2160, 2430, 2700, 3240, 4320, 5400]
> +default: 5400
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +dp_phy: phy@32c0 {
> +compatible = "cdns,hdptx-dp-phy";
> +reg = <0x32c0 0x10>;
> +#phy-cells = <0>;
> +clocks = <_phy_27m>, < IMX8MQ_CLK_DISP_APB_ROOT>;
> +clock-names = "ref", "apb";
> +cdns,num-lanes = <4>;
> +cdns,max-bit-rate = <5400>;
> +};
> --
> 2.34.1
>
>
Re: [PATCH] mm/memremap: Introduce pgmap_request_folio() using pgmap offsets
On Wed, 30 Nov 2022 16:22:50 -0800 Dan Williams wrote: > I think since there is no urgent need for this series to move forward in > v6.2 I can take the time to kill the need for pfn_to_pgmap_offset() and > circle back for this in v6.3. I'll drop v3 of "Fix the DAX-gup mistake" and "mm/memremap: Introduce pgmap_request_folio() using pgmap offsets". a) because Stephen says "no next-next material in next" and b) because its presence in -next might invalidate testing of other things we have queued for the next merge window.
Re: [PATCH v5 05/10] dt-bindings: display: bridge: Add MHDP HDMI for i.MX8MQ
On Mon, Nov 28, 2022 at 03:36:13PM +0800, Sandor Yu wrote:
> Add bindings for i.MX8MQ MHDP HDMI.
>
> Signed-off-by: Sandor Yu
> ---
> .../display/bridge/cdns,mhdp-imx8mq-hdmi.yaml | 102 ++
> 1 file changed, 102 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp-imx8mq-hdmi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp-imx8mq-hdmi.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp-imx8mq-hdmi.yaml
> new file mode 100644
> index ..cca6954a84ff
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp-imx8mq-hdmi.yaml
> @@ -0,0 +1,102 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp-imx8mq-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence MHDP HDMI bridge
> +
> +maintainers:
> + - Sandor Yu
> +
> +description:
> + The Cadence MHDP TX HDMI interface.
What's the difference between this block and the DP block? The binding
looks the same other than compatible, so can they be combined?
> +
> +properties:
> + compatible:
> +enum:
> + - cdns,mhdp-imx8mq-hdmi
Same comment here on naming.
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 1
> +description: MHDP HDMI APB clock.
> +
> + phys:
> +maxItems: 1
> +
> + interrupts:
> +items:
> + - description: Hotplug cable plugin.
> + - description: Hotplug cable plugout.
> +
> + interrupt-names:
> +items:
> + - const: plug_in
> + - const: plug_out
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Input port from display controller output.
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Output port to HDMI connector.
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> + - interrupt-names
> + - phys
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +mhdp_hdmi: hdmi-bridge@32c0 {
> +compatible = "cdns,mhdp-imx8mq-hdmi";
> +reg = <0x32c0 0x10>;
> +interrupts = ,
> + ;
> +interrupt-names = "plug_in", "plug_out";
> +clocks = < IMX8MQ_CLK_DISP_APB_ROOT>;
> +phys = <_phy>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +
> +mhdp_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +
> +mhdp_out: endpoint {
> +remote-endpoint = <_con>;
> +};
> +};
> +};
> +};
> --
> 2.34.1
>
>
Re: [PATCH v5 02/10] dt-bindings: display: bridge: Add MHDP DP for i.MX8MQ
On Mon, Nov 28, 2022 at 03:36:10PM +0800, Sandor Yu wrote:
> Add bindings for i.MX8MQ MHDP DisplayPort.
>
> Signed-off-by: Sandor Yu
> ---
> .../display/bridge/cdns,mhdp-imx8mq-dp.yaml | 102 ++
> 1 file changed, 102 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp-imx8mq-dp.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp-imx8mq-dp.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp-imx8mq-dp.yaml
> new file mode 100644
> index ..21cf87c79766
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp-imx8mq-dp.yaml
> @@ -0,0 +1,102 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp-imx8mq-dp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence MHDP Displayport bridge
> +
> +maintainers:
> + - Sandor Yu
> +
> +description:
> + The Cadence MHDP Displayport TX interface.
> +
> +properties:
> + compatible:
> +enum:
> + - cdns,mhdp-imx8mq-dp
nxp,ixm8mq-mhdp
Cadence is not the vendor for imx8mq. It is doubtful that every vendor
using this IP block will be the same because that rarely/never happens.
And I assume the 'dp in 'mhdp' stands for DisplayPort, so we don't need
it twice.
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 1
> +description: MHDP DP APB clock.
Seems like there would be more than just a bus clock unless all the
function clocks come from the display controller or phy.
> +
> + phys:
> +maxItems: 1
> +
> + interrupts:
> +items:
> + - description: Hotplug cable plugin.
> + - description: Hotplug cable plugout.
> +
> + interrupt-names:
> +items:
> + - const: plug_in
> + - const: plug_out
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Input port from display controller output.
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Output port to DP connector.
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> + - interrupt-names
> + - phys
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +mhdp_dp: dp-bridge@32c0 {
> +compatible = "cdns,mhdp-imx8mq-dp";
> +reg = <0x32c0 0x10>;
> +interrupts = ,
> + ;
> +interrupt-names = "plug_in", "plug_out";
> +clocks = < IMX8MQ_CLK_DISP_APB_ROOT>;
> +phys = <_phy>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +
> +mhdp_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +
> +mhdp_out: endpoint {
> +remote-endpoint = <_con>;
> +};
> +};
> +};
> +};
> --
> 2.34.1
>
>
Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface
On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: > @Ulf, Akhil has a power-domain for a piece of hardware which may be voted active by multiple different subsystems (co-processors/execution contexts) in the system. As such, during the powering down sequence we don't wait for the power-domain to turn off. But in the event of an error, the recovery mechanism relies on waiting for the hardware to settle in a powered off state. The proposal here is to use the reset framework to wait for this state to be reached, before continuing with the recovery mechanism in the client driver. Given our other discussions on quirky behavior, do you have any input/suggestions on this? > 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. @Akhil, this description is fairly generic. As we've reached the state where the hardware has settled and we return to the client, what prevents it from being powered up again? Or is it simply a question of it hitting the powered-off state, not necessarily staying there? Regards, Bjorn > > This series is rebased on top of qcom/linux:for-next branch. > > Related discussion: https://patchwork.freedesktop.org/patch/493144/ > > Changes in v7: > - Update commit message (Bjorn) > - Rebased on top of qcom/linux:for-next branch. > > Changes in v6: > - No code changes in this version. Just captured the Acked-by tags > > Changes in v5: > - Nit: Remove a duplicate blank line (Krzysztof) > > Changes in v4: > - Update gpu dt-binding schema > - Typo fix in commit text > > Changes in v3: > - Use pointer to const for "struct qcom_reset_ops" in qcom_reset_map > (Krzysztof) > > Changes in v2: > - Return error when a particular custom reset op is not implemented. (Dmitry) > > Akhil P Oommen (6): > dt-bindings: clk: qcom: Support gpu cx gdsc reset > clk: qcom: Allow custom reset ops > clk: qcom: gdsc: Add a reset op to poll gdsc collapse > clk: qcom: gpucc-sc7280: Add cx collapse reset support > dt-bindings: drm/msm/gpu: Add optional resets > arm64: dts: qcom: sc7280: Add Reset support for gpu > > .../devicetree/bindings/display/msm/gpu.yaml | 6 + > 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| 10 > drivers/clk/qcom/reset.c | 27 > +- > drivers/clk/qcom/reset.h | 8 +++ > include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++ > 8 files changed, 82 insertions(+), 5 deletions(-) > > -- > 2.7.4 >
Re: [PATCH 4/6] drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
On 12/1/2022 2:40 PM, Teres Alexis, Alan Previn wrote:
Few nits - most of which are repeats from existing review comments.
I did have 1 feedback. Functionally, code logic is correct.
To speed things up, I'll provide a conditional R-b if you address the feedback
below + fix the the BIT3->to-BIT4 uncore-
flags fix. Others are nits in my book:
(conditional) Reviewed-by: Alan Previn
On Mon, 2022-11-21 at 15:16 -0800, Ceraolo Spurio, Daniele wrote:
If the GSC was loaded, the only way to stop it during the driver unload
flow is to do a driver-FLR.
The driver-FLR is not the same as PCI config space FLR in that
it doesn't reset the SGUnit and doesn't modify the PCI config
space. Thus, it doesn't require a re-enumeration of the PCI BARs.
However, the driver-FLR does cause a memory wipe of graphics memory
on all discrete GPU platforms or a wipe limited to stolen memory
on the integrated GPU platforms.
Alan: [snip]
+ /*
+* Once the GSC FW is loaded, the only way to kill it on driver unload
+* is to do a driver FLR. Given this is a very disruptive action, we
+* want to do it as the last action before releasing the access to the
+* MMIO bar, which means we need to do it as part of the primary uncore
+* cleanup.
+*/
+ intel_uncore_set_flr_on_fini(>i915->uncore);
Alan: Nit: Perhaps define what disruptive (i.e. the whole memory wiping impact)
- aligns with what Rodrigo commented i
think?
I'll add it in the FLR function and refer to that one
Alan: Nit: Might be important for developers debugging issues to state (in
comments) that the security FW has been
provided a dynamically allocated memory which is why it MUST be killed on
unload (unlike prior Gen SOCs).
Alan: Feedback: I think intel_uncore_set_flr_on_fini should called before
gsc_fw_load() (or after but still called if
loading failed with and error indicating the instruction was already sent such
as the timeout error, before the bail).
This would be better to ensure a clean slate is set upon unload even if gsc
firmware was attempted to get loaded.
Ok, I'll move it to before.
Alan: [snip]
+ /*
+* Make sure any pending FLR requests have cleared by waiting for the
+* FLR trigger bit to go to zero. Also clear GU_DEBUG's DRIVERFLR_STATUS
+* to make sure it's not still set from a prior attempt (it's a write to
+* clear bit).
+* Note that we should never be in a situation where a previous attempt
+* is still pending (unless the HW is totally dead), but better to be
+* safe in case something unexpected happens
+*/
+ ret = intel_wait_for_register_fw(uncore, GU_CNTL, DRIVERFLR, 0,
flr_timeout_ms);
+ if (ret) {
+ drm_err(>drm,
+ "Failed to wait for Driver-FLR bit to clear! %d\n",
+ ret);
+ return;
+ }
+ intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
+
Alan: Nit: with the current definition of MTL registers, nothing is wrong with
above code but for the sake of code-
intent-readability, perhaps better to use intel_uncore_rmw_fw on above too.
This can't be a rmw, this register has a bunch of bits that are write to
clear/take action, so we must write only the FLR bit.
Daniele
Alan: [snip]
@@ -153,6 +153,7 @@ struct intel_uncore {
#define UNCORE_HAS_FPGA_DBG_UNCLAIMED BIT(1)
#define UNCORE_HAS_DBG_UNCLAIMED BIT(2)
#define UNCORE_HAS_FIFO BIT(3)
+#define UNCORE_NEEDS_FLR_ON_FINI BIT(3)
Alan: Fix: yeah - this needs to be 4 - u already caught that.
Re: [PATCH] drm/vmwgfx: Don't use screen objects when SEV is active
On 12/1/22 09:53, Zack Rusin wrote:
> From: Zack Rusin
>
> When SEV is enabled gmr's and mob's are explicitly disabled because
> the encrypted system memory can not be used by the hypervisor.
>
> The driver was disabling GMR's but the presentation code, which depends
> on GMR's, wasn't honoring it which lead to black screen on hosts
> with SEV enabled.
>
> Make sure screen objects presentation is not used when guest memory
> regions have been disabled to fix presentation on SEV enabled hosts.
>
> Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is
> active")
> Cc: # v5.7+
> Signed-off-by: Zack Rusin
> Reported-by: Nicholas Hunt
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> index 8db61c541a80..e1f36a09c59c 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> @@ -926,6 +926,10 @@ int vmw_kms_sou_init_display(struct vmw_private
> *dev_priv)
> struct drm_device *dev = _priv->drm;
> int i;
>
> + /* Screen objects won't work if GMR's aren't available */
> + if (!dev_priv->has_gmr)
> + return -ENOSYS;
> +
> if (!(dev_priv->capabilities & SVGA_CAP_SCREEN_OBJECT_2)) {
> return -ENOSYS;
> }
LGTM
--
Maaz Mombasawala (VMware)
Re: [PATCH 4/6] drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
Few nits - most of which are repeats from existing review comments.
I did have 1 feedback. Functionally, code logic is correct.
To speed things up, I'll provide a conditional R-b if you address the feedback
below + fix the the BIT3->to-BIT4 uncore-
flags fix. Others are nits in my book:
(conditional) Reviewed-by: Alan Previn
On Mon, 2022-11-21 at 15:16 -0800, Ceraolo Spurio, Daniele wrote:
> If the GSC was loaded, the only way to stop it during the driver unload
> flow is to do a driver-FLR.
> The driver-FLR is not the same as PCI config space FLR in that
> it doesn't reset the SGUnit and doesn't modify the PCI config
> space. Thus, it doesn't require a re-enumeration of the PCI BARs.
> However, the driver-FLR does cause a memory wipe of graphics memory
> on all discrete GPU platforms or a wipe limited to stolen memory
> on the integrated GPU platforms.
Alan: [snip]
> > + /*
> + * Once the GSC FW is loaded, the only way to kill it on driver unload
> + * is to do a driver FLR. Given this is a very disruptive action, we
> + * want to do it as the last action before releasing the access to the
> + * MMIO bar, which means we need to do it as part of the primary uncore
> + * cleanup.
> + */
> + intel_uncore_set_flr_on_fini(>i915->uncore);
Alan: Nit: Perhaps define what disruptive (i.e. the whole memory wiping impact)
- aligns with what Rodrigo commented i
think?
Alan: Nit: Might be important for developers debugging issues to state (in
comments) that the security FW has been
provided a dynamically allocated memory which is why it MUST be killed on
unload (unlike prior Gen SOCs).
Alan: Feedback: I think intel_uncore_set_flr_on_fini should called before
gsc_fw_load() (or after but still called if
loading failed with and error indicating the instruction was already sent such
as the timeout error, before the bail).
This would be better to ensure a clean slate is set upon unload even if gsc
firmware was attempted to get loaded.
Alan: [snip]
> + /*
> + * Make sure any pending FLR requests have cleared by waiting for the
> + * FLR trigger bit to go to zero. Also clear GU_DEBUG's DRIVERFLR_STATUS
> + * to make sure it's not still set from a prior attempt (it's a write to
> + * clear bit).
> + * Note that we should never be in a situation where a previous attempt
> + * is still pending (unless the HW is totally dead), but better to be
> + * safe in case something unexpected happens
> + */
> + ret = intel_wait_for_register_fw(uncore, GU_CNTL, DRIVERFLR, 0,
> flr_timeout_ms);
> + if (ret) {
> + drm_err(>drm,
> + "Failed to wait for Driver-FLR bit to clear! %d\n",
> + ret);
> + return;
> + }
> + intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
> +
Alan: Nit: with the current definition of MTL registers, nothing is wrong with
above code but for the sake of code-
intent-readability, perhaps better to use intel_uncore_rmw_fw on above too.
Alan: [snip]
> @@ -153,6 +153,7 @@ struct intel_uncore {
> #define UNCORE_HAS_FPGA_DBG_UNCLAIMEDBIT(1)
> #define UNCORE_HAS_DBG_UNCLAIMED BIT(2)
> #define UNCORE_HAS_FIFO BIT(3)
> +#define UNCORE_NEEDS_FLR_ON_FINI BIT(3)
>
Alan: Fix: yeah - this needs to be 4 - u already caught that.
[PATCH v7 5/5] drm/msm/dp: add support of max dp link rate
By default, HBR2 (5.4G) is the max link link be supported. This patch add
the capability to support max link rate at HBR3 (8.1G).
Changes in v2:
-- add max link rate from dtsi
Changes in v3:
-- parser max_data_lanes and max_dp_link_rate from dp_out endpoint
Changes in v4:
-- delete unnecessary pr_err
Changes in v5:
-- split parser function into different patch
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 4
drivers/gpu/drm/msm/dp/dp_panel.c | 7 ---
drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index bfd0aef..edee550 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -390,6 +390,10 @@ static int dp_display_process_hpd_high(struct
dp_display_private *dp)
struct edid *edid;
dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
+ dp->panel->max_dp_link_rate = dp->parser->max_dp_link_rate;
+
+ drm_dbg_dp(dp->drm_dev, "max_lanes=%d max_link_rate=%d\n",
+ dp->panel->max_dp_lanes, dp->panel->max_dp_link_rate);
rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
if (rc)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 5149ceb..933fa9c 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -75,12 +75,13 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
link_info->rate = drm_dp_bw_code_to_link_rate(dpcd[DP_MAX_LINK_RATE]);
link_info->num_lanes = dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
+ /* Limit data lanes from data-lanes of endpoint properity of dtsi */
if (link_info->num_lanes > dp_panel->max_dp_lanes)
link_info->num_lanes = dp_panel->max_dp_lanes;
- /* Limit support upto HBR2 until HBR3 support is added */
- if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
- link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
+ /* Limit link rate from link-frequencies of endpoint properity of dtsi
*/
+ if (link_info->rate > dp_panel->max_dp_link_rate)
+ link_info->rate = dp_panel->max_dp_link_rate;
drm_dbg_dp(panel->drm_dev, "version: %d.%d\n", major, minor);
drm_dbg_dp(panel->drm_dev, "link_rate=%d\n", link_info->rate);
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h
b/drivers/gpu/drm/msm/dp/dp_panel.h
index d861197a..f04d021 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -50,6 +50,7 @@ struct dp_panel {
u32 vic;
u32 max_dp_lanes;
+ u32 max_dp_link_rate;
u32 max_bw_code;
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v7 4/5] drm/msm/dp: parser link-frequencies as property of dp_out endpoint
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_parser.c | 19 +--
drivers/gpu/drm/msm/dp/dp_parser.h | 2 ++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index b5f7e70..037dad8 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -94,15 +94,28 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
static int dp_parser_misc(struct dp_parser *parser)
{
struct device_node *of_node = parser->pdev->dev.of_node;
+ struct device_node *endpoint;
+ u64 frequency;
int cnt;
/*
* data-lanes is the property of dp_out endpoint
*/
cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1,
DP_MAX_NUM_DP_LANES);
- if (cnt > 0)
+ if (cnt > 0) {
parser->max_dp_lanes = cnt;
- else {
+
+ endpoint = of_graph_get_endpoint_by_regs(of_node, 1, 0); /*
port@1 */
+ cnt = of_property_count_u64_elems(endpoint, "link-frequencies");
+ if (cnt > 0) {
+ of_property_read_u64_index(endpoint, "link-frequencies",
+ cnt - 1, );
+ frequency /= 10;/* from symbol rate to link
rate */
+ parser->max_dp_link_rate = (frequency / 1000); /* kbits
*/
+ } else {
+ parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54
khz */
+ }
+ } else {
/*
* legacy code, data-lanes is the property of mdss_dp node
*/
@@ -111,6 +124,8 @@ static int dp_parser_misc(struct dp_parser *parser)
parser->max_dp_lanes = cnt;
else
parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes
*/
+
+ parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 khz */
}
return 0;
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 866c1a8..3ddf639 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -15,6 +15,7 @@
#define DP_LABEL "MDSS DP DISPLAY"
#define DP_MAX_PIXEL_CLK_KHZ 675000
#define DP_MAX_NUM_DP_LANES4
+#define DP_LINK_RATE_HBR2 54
enum dp_pm_type {
DP_CORE_PM,
@@ -119,6 +120,7 @@ struct dp_parser {
struct dp_io io;
struct dp_display_data disp_data;
u32 max_dp_lanes;
+ u32 max_dp_link_rate;
struct drm_bridge *next_bridge;
int (*parse)(struct dp_parser *parser);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] drm/i915/gen12: Apply recommended L3 hashing mask
The TGL/RKL/DG1/ADL performance tuning guide suggests programming a
literal value of 0x2FC0100F for this register. The register's hardware
default value is 0x2FC0108F, so this translates to just clearing one
bit.
Take this opportunity to also clean up the register definition and
re-write its existing bits/fields in the preferred notation.
Bspec: 31870
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 9 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 61a5c9a83b1b..f8eb807b56f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -958,10 +958,11 @@
#define GEN7_DISABLE_SAMPLER_PREFETCH(1 << 30)
#define GEN8_GARBCNTL _MMIO(0xb004)
-#define GEN9_GAPS_TSV_CREDIT_DISABLE (1 << 7)
-#define GEN11_ARBITRATION_PRIO_ORDER_MASK(0x3f << 22)
-#define GEN11_HASH_CTRL_EXCL_MASK(0x7f << 0)
-#define GEN11_HASH_CTRL_EXCL_BIT0(1 << 0)
+#define GEN11_ARBITRATION_PRIO_ORDER_MASKREG_GENMASK(27, 22)
+#define GEN12_BUS_HASH_CTL_BIT_EXC REG_BIT(7)
+#define GEN9_GAPS_TSV_CREDIT_DISABLE REG_BIT(7)
+#define GEN11_HASH_CTRL_EXCL_MASKREG_GENMASK(6, 0)
+#define GEN11_HASH_CTRL_EXCL_BIT0
REG_FIELD_PREP(GEN11_HASH_CTRL_EXCL_MASK, 0x1)
#define GEN9_SCRATCH_LNCF1 _MMIO(0xb008)
#define GEN9_LNCF_NONIA_COHERENT_ATOMICS_ENABLE REG_BIT(0)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 85822ebb0d64..2f13a92f77d3 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2937,6 +2937,10 @@ add_render_compute_tuning_settings(struct
drm_i915_private *i915,
if (INTEL_INFO(i915)->tuning_thread_rr_after_dep)
wa_mcr_masked_field_set(wal, GEN9_ROW_CHICKEN4,
THREAD_EX_ARB_MODE,
THREAD_EX_ARB_MODE_RR_AFTER_DEP);
+
+ if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12,
50)) {
+ wa_write_clr(wal, GEN8_GARBCNTL, GEN12_BUS_HASH_CTL_BIT_EXC);
+ }
}
/*
--
2.38.1
[PATCH v7 0/5] Add data-lanes and link-frequencies to dp_out endpoint
Add DP both data-lanes and link-frequencies property to dp_out endpoint and support functions to DP driver. Kuogee Hsieh (5): arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint dt-bindings: msm/dp: add data-lanes and link-frequencies property drm/msm/dp: parser data-lanes as property of dp_out endpoint drm/msm/dp: parser link-frequencies as property of dp_out endpoint drm/msm/dp: add support of max dp link rate .../bindings/display/msm/dp-controller.yaml| 22 + arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +++- arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +++- drivers/gpu/drm/msm/dp/dp_display.c| 4 +++ drivers/gpu/drm/msm/dp/dp_panel.c | 7 ++-- drivers/gpu/drm/msm/dp/dp_panel.h | 1 + drivers/gpu/drm/msm/dp/dp_parser.c | 38 ++ drivers/gpu/drm/msm/dp/dp_parser.h | 2 ++ 8 files changed, 68 insertions(+), 18 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 1/2] adreno: Shutdown the GPU properly
On Thu, Dec 1, 2022 at 10:06 PM Rob Clark wrote:
>
> On Thu, Dec 1, 2022 at 12:08 PM Joel Fernandes wrote:
> >
> > On Sat, Nov 12, 2022 at 6:44 PM Rob Clark wrote:
> > >
> > > On Fri, Nov 11, 2022 at 1:08 PM Joel Fernandes
> > > wrote:
> > > >
> > > >
> > > >
> > > > > On Nov 11, 2022, at 2:50 PM, Joel Fernandes (Google)
> > > > > wrote:
> > > > >
> > > > > During kexec on ARM device, we notice that device_shutdown() only
> > > > > calls
> > > > > pm_runtime_force_suspend() while shutting down the GPU. This means
> > > > > the GPU
> > > > > kthread is still running and further, there maybe active submits.
> > > > >
> > > > > This causes all kinds of issues during a kexec reboot:
> > > > >
> > > > > Warning from shutdown path:
> > > > >
> > > > > [ 292.509662] WARNING: CPU: 0 PID: 6304 at [...]
> > > > > adreno_runtime_suspend+0x3c/0x44
> > > > > [ 292.509863] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
> > > > > [ 292.509872] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
> > > > > BTYPE=--)
> > > > > [ 292.509881] pc : adreno_runtime_suspend+0x3c/0x44
> > > > > [ 292.509891] lr : pm_generic_runtime_suspend+0x30/0x44
> > > > > [ 292.509905] sp : ffc014473bf0
> > > > > [...]
> > > > > [ 292.510043] Call trace:
> > > > > [ 292.510051] adreno_runtime_suspend+0x3c/0x44
> > > > > [ 292.510061] pm_generic_runtime_suspend+0x30/0x44
> > > > > [ 292.510071] pm_runtime_force_suspend+0x54/0xc8
> > > > > [ 292.510081] adreno_shutdown+0x1c/0x28
> > > > > [ 292.510090] platform_shutdown+0x2c/0x38
> > > > > [ 292.510104] device_shutdown+0x158/0x210
> > > > > [ 292.510119] kernel_restart_prepare+0x40/0x4c
> > > > >
> > > > > And here from GPU kthread, an SError OOPs:
> > > > >
> > > > > [ 192.648789] el1h_64_error+0x7c/0x80
> > > > > [ 192.648812] el1_interrupt+0x20/0x58
> > > > > [ 192.648833] el1h_64_irq_handler+0x18/0x24
> > > > > [ 192.648854] el1h_64_irq+0x7c/0x80
> > > > > [ 192.648873] local_daif_inherit+0x10/0x18
> > > > > [ 192.648900] el1h_64_sync_handler+0x48/0xb4
> > > > > [ 192.648921] el1h_64_sync+0x7c/0x80
> > > > > [ 192.648941] a6xx_gmu_set_oob+0xbc/0x1fc
> > > > > [ 192.648968] a6xx_hw_init+0x44/0xe38
> > > > > [ 192.648991] msm_gpu_hw_init+0x48/0x80
> > > > > [ 192.649013] msm_gpu_submit+0x5c/0x1a8
> > > > > [ 192.649034] msm_job_run+0xb0/0x11c
> > > > > [ 192.649058] drm_sched_main+0x170/0x434
> > > > > [ 192.649086] kthread+0x134/0x300
> > > > > [ 192.649114] ret_from_fork+0x10/0x20
> > > > >
> > > > > Fix by calling adreno_system_suspend() in the device_shutdown() path.
> > > > >
> > > > > Cc: Rob Clark
> > > > > Cc: Steven Rostedt
> > > > > Cc: Ricardo Ribalda
> > > > > Cc: Ross Zwisler
> > > > > Signed-off-by: Joel Fernandes (Google)
> > > > > ---
> > > > > drivers/gpu/drm/msm/adreno/adreno_device.c | 5 -
> > > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > > index 24b489b6129a..f0cff62812c3 100644
> > > > > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > > @@ -607,9 +607,12 @@ static int adreno_remove(struct platform_device
> > > > > *pdev)
> > > > >return 0;
> > > > > }
> > > > >
> > > > > +static int adreno_system_suspend(struct device *dev);
> > > > > static void adreno_shutdown(struct platform_device *pdev)
> > > > > {
> > > > > -pm_runtime_force_suspend(>dev);
> > > > > +struct msm_gpu *gpu = dev_to_gpu(>dev);
> > > > > +
> > > >
> > > > This local variable definition should go to patch 2/2. Will fix in v2.
> > > >
> > > > Thanks,
> > > >
> > > > - Joel
> > > >
> > > >
> > > > > +WARN_ON_ONCE(adreno_system_suspend(>dev));
> > >
> > > I think maybe adreno_unbind() needs the same treatment? Any path
> > > where we yank out the power cord without ensuring the scheduler is
> > > parked means we'd be racing with jobs in the scheduler queue. Ie.
> > > userspace could queue a job before it is frozen, but the drm/scheduler
> > > kthread hasn't yet called the msm_job_run() callback (which does
> > > various touching of the now powered off hw). So I think we need to
> > > ensure that the scheduler is parked in all paths that call
> > > pm_runtime_force_suspend() (as that bypasses the runpm reference that
> > > would otherwise unsure the hw is powered before msm_job_run pokes at
> > > registers)
> >
> > a6xx_gmu_remove() calls pm_runtime_force_suspend() , would that need a
> > treatment too?
> >
> > Though, adreno_system_suspend() is a static function in adreno_device.cc
>
> Naw, you get there indirectly from adreno_unbind()
Ah gotcha, thanks.
- Joel
Re: [PATCH 1/2] adreno: Shutdown the GPU properly
On Thu, Dec 1, 2022 at 12:08 PM Joel Fernandes wrote:
>
> On Sat, Nov 12, 2022 at 6:44 PM Rob Clark wrote:
> >
> > On Fri, Nov 11, 2022 at 1:08 PM Joel Fernandes
> > wrote:
> > >
> > >
> > >
> > > > On Nov 11, 2022, at 2:50 PM, Joel Fernandes (Google)
> > > > wrote:
> > > >
> > > > During kexec on ARM device, we notice that device_shutdown() only calls
> > > > pm_runtime_force_suspend() while shutting down the GPU. This means the
> > > > GPU
> > > > kthread is still running and further, there maybe active submits.
> > > >
> > > > This causes all kinds of issues during a kexec reboot:
> > > >
> > > > Warning from shutdown path:
> > > >
> > > > [ 292.509662] WARNING: CPU: 0 PID: 6304 at [...]
> > > > adreno_runtime_suspend+0x3c/0x44
> > > > [ 292.509863] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
> > > > [ 292.509872] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
> > > > BTYPE=--)
> > > > [ 292.509881] pc : adreno_runtime_suspend+0x3c/0x44
> > > > [ 292.509891] lr : pm_generic_runtime_suspend+0x30/0x44
> > > > [ 292.509905] sp : ffc014473bf0
> > > > [...]
> > > > [ 292.510043] Call trace:
> > > > [ 292.510051] adreno_runtime_suspend+0x3c/0x44
> > > > [ 292.510061] pm_generic_runtime_suspend+0x30/0x44
> > > > [ 292.510071] pm_runtime_force_suspend+0x54/0xc8
> > > > [ 292.510081] adreno_shutdown+0x1c/0x28
> > > > [ 292.510090] platform_shutdown+0x2c/0x38
> > > > [ 292.510104] device_shutdown+0x158/0x210
> > > > [ 292.510119] kernel_restart_prepare+0x40/0x4c
> > > >
> > > > And here from GPU kthread, an SError OOPs:
> > > >
> > > > [ 192.648789] el1h_64_error+0x7c/0x80
> > > > [ 192.648812] el1_interrupt+0x20/0x58
> > > > [ 192.648833] el1h_64_irq_handler+0x18/0x24
> > > > [ 192.648854] el1h_64_irq+0x7c/0x80
> > > > [ 192.648873] local_daif_inherit+0x10/0x18
> > > > [ 192.648900] el1h_64_sync_handler+0x48/0xb4
> > > > [ 192.648921] el1h_64_sync+0x7c/0x80
> > > > [ 192.648941] a6xx_gmu_set_oob+0xbc/0x1fc
> > > > [ 192.648968] a6xx_hw_init+0x44/0xe38
> > > > [ 192.648991] msm_gpu_hw_init+0x48/0x80
> > > > [ 192.649013] msm_gpu_submit+0x5c/0x1a8
> > > > [ 192.649034] msm_job_run+0xb0/0x11c
> > > > [ 192.649058] drm_sched_main+0x170/0x434
> > > > [ 192.649086] kthread+0x134/0x300
> > > > [ 192.649114] ret_from_fork+0x10/0x20
> > > >
> > > > Fix by calling adreno_system_suspend() in the device_shutdown() path.
> > > >
> > > > Cc: Rob Clark
> > > > Cc: Steven Rostedt
> > > > Cc: Ricardo Ribalda
> > > > Cc: Ross Zwisler
> > > > Signed-off-by: Joel Fernandes (Google)
> > > > ---
> > > > drivers/gpu/drm/msm/adreno/adreno_device.c | 5 -
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > index 24b489b6129a..f0cff62812c3 100644
> > > > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > @@ -607,9 +607,12 @@ static int adreno_remove(struct platform_device
> > > > *pdev)
> > > >return 0;
> > > > }
> > > >
> > > > +static int adreno_system_suspend(struct device *dev);
> > > > static void adreno_shutdown(struct platform_device *pdev)
> > > > {
> > > > -pm_runtime_force_suspend(>dev);
> > > > +struct msm_gpu *gpu = dev_to_gpu(>dev);
> > > > +
> > >
> > > This local variable definition should go to patch 2/2. Will fix in v2.
> > >
> > > Thanks,
> > >
> > > - Joel
> > >
> > >
> > > > +WARN_ON_ONCE(adreno_system_suspend(>dev));
> >
> > I think maybe adreno_unbind() needs the same treatment? Any path
> > where we yank out the power cord without ensuring the scheduler is
> > parked means we'd be racing with jobs in the scheduler queue. Ie.
> > userspace could queue a job before it is frozen, but the drm/scheduler
> > kthread hasn't yet called the msm_job_run() callback (which does
> > various touching of the now powered off hw). So I think we need to
> > ensure that the scheduler is parked in all paths that call
> > pm_runtime_force_suspend() (as that bypasses the runpm reference that
> > would otherwise unsure the hw is powered before msm_job_run pokes at
> > registers)
>
> a6xx_gmu_remove() calls pm_runtime_force_suspend() , would that need a
> treatment too?
>
> Though, adreno_system_suspend() is a static function in adreno_device.cc
Naw, you get there indirectly from adreno_unbind()
BR,
-R
> Thanks.
Re: [Intel-gfx] [PATCH 0/2] drm/i915: Remove frontbuffer tracking from gem.
Hi I was given a link to https://patchwork.freedesktop.org/series/111494/ but can't seem to find it on the mailing list, so I'll reply here. On Thu, 2022-08-25 at 08:46 +0200, Maarten Lankhorst wrote: > Frontbuffer tracking in gem is used in old drivers, but nowadays everyone > calls dirtyfb explicitly. Remove frontbuffer tracking from gem, and > isolate it to display only. Ok, but then how can the Kernel know if the user space running is an "old driver" or a new one? Assuming everybody is following the new policy is at least risky. (crazy idea: have an ioctl for user space to tell whether it knows how to DirtyFB and another where it can even say it will never be touching frontbuffers at all) Also, when I wrote igt/kms_frontbuffer_tracking, it was agreed that whatever was there was a representation of the "rules" of the frontbfuffer writing contract/API. And I see on the link above that the basic tests of kms_frontbuffer_tracking fail. If kms_frontbuffer_tracking requires change due to i915.ko having changed the frontbuffer writing rules, then we should do it, and possibly have those rules written somewhere. But then, having the Kernel change expectations like that is not exactly what I learned we should be doing, because it's the recipe to break user space. I'm confused, please clarify us a little more. More sentences in the commit messages would be absolutely great. Thanks, Paulo > > Maarten Lankhorst (2): > drm/i915: Remove gem and overlay frontbuffer tracking > drm/i915: Remove special frontbuffer type > > drivers/gpu/drm/i915/display/intel_cursor.c | 6 +- > drivers/gpu/drm/i915/display/intel_display.c | 4 +- > .../drm/i915/display/intel_display_types.h| 8 +- > drivers/gpu/drm/i915/display/intel_fb.c | 11 +- > drivers/gpu/drm/i915/display/intel_fbdev.c| 7 +- > .../gpu/drm/i915/display/intel_frontbuffer.c | 103 ++ > .../gpu/drm/i915/display/intel_frontbuffer.h | 65 ++- > drivers/gpu/drm/i915/display/intel_overlay.c | 14 --- > .../drm/i915/display/intel_plane_initial.c| 3 +- > drivers/gpu/drm/i915/display/intel_psr.c | 1 + > drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4 - > drivers/gpu/drm/i915/gem/i915_gem_domain.c| 7 -- > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 - > drivers/gpu/drm/i915/gem/i915_gem_object.c| 25 - > drivers/gpu/drm/i915/gem/i915_gem_object.h| 22 > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 4 - > drivers/gpu/drm/i915/i915_driver.c| 1 + > drivers/gpu/drm/i915/i915_drv.h | 1 - > drivers/gpu/drm/i915/i915_gem.c | 8 -- > drivers/gpu/drm/i915/i915_gem_gtt.c | 1 - > drivers/gpu/drm/i915/i915_vma.c | 12 -- > 21 files changed, 35 insertions(+), 274 deletions(-) >
Re: [PATCH 3/6] drm/i915/gsc: GSC firmware loading
I only have one minor nits below. Rodrigo already captured other minor issues. Functionally, all LGTM so Reviewed-by: Alan Previn On Mon, 2022-11-21 at 15:16 -0800, Ceraolo Spurio, Daniele wrote: > GSC FW is loaded by submitting a dedicated command via the GSC engine. > The memory area used for loading the FW is then re-purposed as local > memory for the GSC itself, so we use a separate allocation instead of > using the one where we keep the firmware stored for reload. > > @@ -206,6 +206,7 @@ i915-y += gt/uc/intel_uc.o \ > gt/uc/intel_huc.o \ > gt/uc/intel_huc_debugfs.o \ > gt/uc/intel_huc_fw.o \ > + gt/uc/intel_gsc_fw.o \ > gt/uc/intel_gsc_uc.o > Nit: Perhaps while here, you fix above to be alphabetical - i think thats the practice? > >
Re: [PATCH 3/4] dt-bindings: display: panel: mipi-dbi-spi: Add missing power-supply
On Sun, Nov 27, 2022 at 08:14:32PM +0100, Otto Pflüger wrote: > The power-supply property is only mentioned in the description and not > listed in the properties section of the binding. Add it there. That's because it is described in panel-common.yaml already. But I guess it is somewhat useful to define it corresponds to Vdd. > > Signed-off-by: Otto Pflüger > --- > .../devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Rob Herring
Re: [PATCH 2/3] drm/amdgpu: add GART and GTT to glossary
On 2022-12-01 10:38, Peter Maucher wrote: GART and GTT are two abbreviations that should be mentioned in the glossary. Signed-off-by: Peter Maucher --- Documentation/gpu/amdgpu/amdgpu-glossary.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst index 326896e9800d..d86bea7926dc 100644 --- a/Documentation/gpu/amdgpu/amdgpu-glossary.rst +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst @@ -30,6 +30,12 @@ we have a dedicated glossary for Display Core at EOP End Of Pipe/Pipeline +GART + Graphics Aperture Table The "R" stands for "Remapping". I've usually seen this as "Graphics Address Remapping Table", but "... Aperture ..." would work too. Regards, Felix + +GTT + Graphics Translation Table, mostly synonymous to GART + GC Graphics and Compute
Re: [PATCH v3 5/5] drm/i915/mtl: Hold forcewake and MCR lock over PPAT setup
On Thu, Dec 01, 2022 at 02:56:30PM +0530, Balasubramani Vivekanandan wrote:
> On 30.11.2022 07:58, Matt Roper wrote:
> > PPAT setup involves a series of multicast writes. This can be optimized
> > slightly be acquiring forcewake and the steering lock just once for the
> > entire sequence.
> >
> > v2:
> > - We should use FW_REG_WRITE instead of FW_REG_READ. (Bala)
> >
> > Suggested-by: Balasubramani Vivekanandan
> >
> > Signed-off-by: Matt Roper
>
> Reviewed-by: Balasubramani Vivekanandan
Thanks. Since this patch is independent of patch #4 (the only one that
hasn't been reviewed yet), I went ahead and pushed this one to
drm-intel-gt-next. BTW, I noticed I wrote "mtl" in the patch title
where I actually meant to have "mcr" (this isn't a MTL-specific change),
so I corrected that typo while pushing as well.
Matt
>
> Regards,
> Bala
>
> > ---
> > drivers/gpu/drm/i915/gt/intel_gtt.c | 27 +++
> > 1 file changed, 19 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
> > b/drivers/gpu/drm/i915/gt/intel_gtt.c
> > index 2ba3983984b9..e37164a60d37 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> > @@ -482,14 +482,25 @@ static void tgl_setup_private_ppat(struct
> > intel_uncore *uncore)
> >
> > static void xehp_setup_private_ppat(struct intel_gt *gt)
> > {
> > - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0), GEN8_PPAT_WB);
> > - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1), GEN8_PPAT_WC);
> > - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2), GEN8_PPAT_WT);
> > - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3), GEN8_PPAT_UC);
> > - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4), GEN8_PPAT_WB);
> > - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(5), GEN8_PPAT_WB);
> > - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(6), GEN8_PPAT_WB);
> > - intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(7), GEN8_PPAT_WB);
> > + enum forcewake_domains fw;
> > + unsigned long flags;
> > +
> > + fw = intel_uncore_forcewake_for_reg(gt->uncore,
> > _MMIO(XEHP_PAT_INDEX(0).reg),
> > + FW_REG_WRITE);
> > + intel_uncore_forcewake_get(gt->uncore, fw);
> > +
> > + intel_gt_mcr_lock(gt, );
> > + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(0), GEN8_PPAT_WB);
> > + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(1), GEN8_PPAT_WC);
> > + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(2), GEN8_PPAT_WT);
> > + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(3), GEN8_PPAT_UC);
> > + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(4), GEN8_PPAT_WB);
> > + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(5), GEN8_PPAT_WB);
> > + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(6), GEN8_PPAT_WB);
> > + intel_gt_mcr_multicast_write_fw(gt, XEHP_PAT_INDEX(7), GEN8_PPAT_WB);
> > + intel_gt_mcr_unlock(gt, flags);
> > +
> > + intel_uncore_forcewake_put(gt->uncore, fw);
> > }
> >
> > static void icl_setup_private_ppat(struct intel_uncore *uncore)
> > --
> > 2.38.1
> >
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
Re: [PATCH v6 1/4] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint
On 12/1/2022 9:49 AM, Dmitry Baryshkov wrote:
On 01/12/2022 19:32, Kuogee Hsieh wrote:
On 11/30/2022 4:21 PM, Dmitry Baryshkov wrote:
On 01/12/2022 02:07, Dmitry Baryshkov wrote:
On 01/12/2022 01:51, Kuogee Hsieh wrote:
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi
Changes in v6:
-- add data-lanes and link-frequencies to yaml
Signed-off-by: Kuogee Hsieh
---
.../devicetree/bindings/display/msm/dp-controller.yaml | 17
+
Separate patch. Also you didn't check the get_maintainers output,
so required parties were not included into the distribution.
Also as you'd check the get_maintainers output, please fix other
email addresses too.
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +-
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 94bc6e1..af70343 100644
---
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -90,6 +90,20 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+
+ properties:
+ link-frequencies: true
+ data-lanes: true
No. Use $ref for both of them.
+
+ required:
+ - link-frequencies
+ - data-lanes
No, they are not required.
+
+ additionalProperties: false
+
deprecation of old data-lanes property?
required:
- compatible
- reg
@@ -158,6 +172,9 @@ examples:
reg = <1>;
endpoint {
remote-endpoint = <>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <16000
27000
s/1600/1620
+ 54000 81000>;
I guess the number of zeroes is wrong here. This is 160 MHz ... 810
Mhz, rather than 1.6 GHz ... 8.1 GHz
Ok, I was wrong here. The old code definitely defaults to 570
mega-something. Now I'd really like to read your description for the
link-frequencies property, because the
phy_configure_opts_dp::link_rate is clearly specified in Mb/s and it
takes a fixed set of values from 1.62 Gb/s up to 8.1 Gb/s.
I think the drm_dp_bw_code_to_link_rate() function is incorrect by
itself, as it multiplies with 27000 (27 Mbps) rather than 27
(0.27 Gbps) as required by the standard. So first, we should fix the
function, then all the rates would become logical.
no, drm_dp_bw_code_to_link_rate() is correct and should not be
changes since it impact to other dp drivers too.
0.27Gbps/lane is specified at DP spec.
DP use 8b/10b coding rule (10 bits symbol contains 8 bits data).
At least it should get documentation that it returns Kylo-bytes per
second.
But, getting back to link-frequencies. The documentation clearly says
that it should be allowed data bus _frequencies_. And frequencies are
measured in Hz, not in bits/sec or bytes/sec.
ok, in the case, we can specify link frequency (symbol rate), such as
810 (8.1G hz), at dtsi to match link-frequencies cocumentation.
then at parser, we have to divided by 10 to convert back to link rate
and then divided by 1000 to convert to kb.
is this work for you?
};
};
};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 754d2d6..39f0844 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -812,7 +812,11 @@ hp_i2c: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <16000 27000 54000>;
Same comment here.
};
_adc {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 93e39fc..b7c343d 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -440,7 +440,11 @@ ap_i2c_tpm: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <16000 27000 54000
81000>;
And here.
};
_mdp {
Re: [PATCH v2 0/6] drm/gud: Use the shadow plane helper
Den 01.12.2022 15.16, skrev Konstantin Ryabitsev: > On Thu, Dec 01, 2022 at 02:34:41PM +0100, Javier Martinez Canillas wrote: Konstantin, Can you add a rule in b4 to exclude sta...@vger.kernel.org (sta...@kernel.org as well?) from getting the whole patchset? >>> >>> sta...@kernel.org is a pipe to /dev/null so that's not needed to be >>> messed with. >>> >>> As for this needing special casing in b4, it's rare that you send out a >>> patch series and only want 1 or 2 of them in stable, right? >>> >> >> Not really, it's very common for a patch-series to contain fixes (that could >> go to stable if applicable) and change that are not suitable for stable. The >> problem as Noralf mentioned is that the b4 tool doesn't seem to allow Cc'ing >> individual patches to different recipients, and everyone get the whole set. >> >> So either b4 needs to have this support, exclude sta...@vger.kernel.org when >> sending a set or sta...@vger.kernel.org ignore patches without a Fixes: tag. > > I think what I can do is a special logic for Cc: trailers: > > - Any Cc: trailers we find in the cover letter receive the entire series > - Any Cc: trailers in individual patches only receive these individual patches > That should cover my use cases. I can now do 'b4 prep --auto-to-cc' and then trim down the cc list in the cover letter if necessary. > Thank you for being patient -- we'll get this right, I promise. > Thanks for getting it right. b4 can replace parts of my own tooling and do it smoother so I think I'll continue to use it. Noralf.
[PATCH v2] adreno: Shutdown the GPU properly
During kexec on ARM device, we notice that device_shutdown() only calls
pm_runtime_force_suspend() while shutting down the GPU. This means the GPU
kthread is still running and further, there maybe active submits.
This causes all kinds of issues during a kexec reboot:
Warning from shutdown path:
[ 292.509662] WARNING: CPU: 0 PID: 6304 at [...]
adreno_runtime_suspend+0x3c/0x44
[ 292.509863] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
[ 292.509872] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 292.509881] pc : adreno_runtime_suspend+0x3c/0x44
[ 292.509891] lr : pm_generic_runtime_suspend+0x30/0x44
[ 292.509905] sp : ffc014473bf0
[...]
[ 292.510043] Call trace:
[ 292.510051] adreno_runtime_suspend+0x3c/0x44
[ 292.510061] pm_generic_runtime_suspend+0x30/0x44
[ 292.510071] pm_runtime_force_suspend+0x54/0xc8
[ 292.510081] adreno_shutdown+0x1c/0x28
[ 292.510090] platform_shutdown+0x2c/0x38
[ 292.510104] device_shutdown+0x158/0x210
[ 292.510119] kernel_restart_prepare+0x40/0x4c
And here from GPU kthread, an SError OOPs:
[ 192.648789] el1h_64_error+0x7c/0x80
[ 192.648812] el1_interrupt+0x20/0x58
[ 192.648833] el1h_64_irq_handler+0x18/0x24
[ 192.648854] el1h_64_irq+0x7c/0x80
[ 192.648873] local_daif_inherit+0x10/0x18
[ 192.648900] el1h_64_sync_handler+0x48/0xb4
[ 192.648921] el1h_64_sync+0x7c/0x80
[ 192.648941] a6xx_gmu_set_oob+0xbc/0x1fc
[ 192.648968] a6xx_hw_init+0x44/0xe38
[ 192.648991] msm_gpu_hw_init+0x48/0x80
[ 192.649013] msm_gpu_submit+0x5c/0x1a8
[ 192.649034] msm_job_run+0xb0/0x11c
[ 192.649058] drm_sched_main+0x170/0x434
[ 192.649086] kthread+0x134/0x300
[ 192.649114] ret_from_fork+0x10/0x20
Fix by calling adreno_system_suspend() in the device_shutdown() path.
[ Applied Rob Clark feedback on fixing adreno_unbind() similarly, also
tested as above. ]
Cc: Rob Clark
Cc: Steven Rostedt
Cc: Ricardo Ribalda
Cc: Ross Zwisler
Signed-off-by: Joel Fernandes (Google)
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 24b489b6129a..c7e26659ba33 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -551,13 +551,14 @@ static int adreno_bind(struct device *dev, struct device
*master, void *data)
return 0;
}
+static int adreno_system_suspend(struct device *dev);
static void adreno_unbind(struct device *dev, struct device *master,
void *data)
{
struct msm_drm_private *priv = dev_get_drvdata(master);
struct msm_gpu *gpu = dev_to_gpu(dev);
- pm_runtime_force_suspend(dev);
+ WARN_ON_ONCE(adreno_system_suspend(dev));
gpu->funcs->destroy(gpu);
priv->gpu_pdev = NULL;
@@ -609,7 +610,7 @@ static int adreno_remove(struct platform_device *pdev)
static void adreno_shutdown(struct platform_device *pdev)
{
- pm_runtime_force_suspend(>dev);
+ WARN_ON_ONCE(adreno_system_suspend(>dev));
}
static const struct of_device_id dt_match[] = {
--
2.39.0.rc0.267.gcb52ba06e7-goog
[PATCH v6 3/5] drm/i915: Introduce guard pages to i915_vma
From: Chris Wilson Introduce the concept of padding the i915_vma with guard pages before and after. The major consequence is that all ordinary uses of i915_vma must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size directly, as the drm_mm_node will include the guard pages that surround our object. The biggest connundrum is how exactly to mix requesting a fixed address with guard pages, particularly through the existing uABI. The user does not know about guard pages, so such must be transparent to the user, and so the execobj.offset must be that of the object itself excluding the guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages. The caveat is that some placements will be impossible with guard pages, as wrap arounds need to be avoided, and the vma itself will require a larger node. We must not report EINVAL but ENOSPC as these are unavailable locations within the GTT rather than conflicting user requirements. In the next patch, we start using guard pages for scanout objects. While these are limited to GGTT vma, on a few platforms these vma (or at least an alias of the vma) is shared with userspace, so we may leak the existence of such guards if we are not careful to ensure that the execobj.offset is transparent and excludes the guards. (On such platforms like ivb, without full-ppgtt, userspace has to use relocations so the presence of more untouchable regions within its GTT such be of no further issue.) Signed-off-by: Chris Wilson Signed-off-by: Tejas Upadhyay Signed-off-by: Tvrtko Ursulin Signed-off-by: Andi Shyti --- Hi Tvrtko, I removed your r-b in this version because I restored the original value of the guard being aligned with the vma size alignment. Turns out that CI failed with the latest version because the guard was becoming too big (we would have hit the GEM_BUG_ON)[*]. The reason why now the guard is aligned with the vma alignment is that the area is already aligned and if we use as a starting address start + guard, guard needs to be aligned, otherwise we screw up all the memory alignment. Let me know if it makes sense to you. Thanks, Andi Changelog = v5 -> v6: - restore the original alignment of guard so that it's aligned coherently with the vma area's alignment. v4 -> v5: - remove again the GEM_BUG_ON() - fix an oversight where the rounding was called without assigning the value to the guard. v1 -> v4: - refer to the cover letter. [*] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110720v5/fi-rkl-11600/igt@i915_module_l...@load.html#dmesg-warnings300 drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 +--- drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- drivers/gpu/drm/i915/i915_vma.c | 43 drivers/gpu/drm/i915/i915_vma.h | 5 +-- drivers/gpu/drm/i915/i915_vma_resource.c | 4 +-- drivers/gpu/drm/i915/i915_vma_resource.h | 7 +++- drivers/gpu/drm/i915/i915_vma_types.h| 1 + 7 files changed, 60 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 7644738b9cdbe..784d4a8c43ba9 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -296,8 +296,11 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm, */ gte = (gen8_pte_t __iomem *)ggtt->gsm; - gte += vma_res->start / I915_GTT_PAGE_SIZE; - end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE; + gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE; + end = gte + vma_res->guard / I915_GTT_PAGE_SIZE; + while (gte < end) + gen8_set_pte(gte++, vm->scratch[0]->encode); + end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE; for_each_sgt_daddr(addr, iter, vma_res->bi.pages) gen8_set_pte(gte++, pte_encode | addr); @@ -347,9 +350,12 @@ static void gen6_ggtt_insert_entries(struct i915_address_space *vm, dma_addr_t addr; gte = (gen6_pte_t __iomem *)ggtt->gsm; - gte += vma_res->start / I915_GTT_PAGE_SIZE; - end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE; + gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE; + end = gte + vma_res->guard / I915_GTT_PAGE_SIZE; + while (gte < end) + iowrite32(vm->scratch[0]->encode, gte++); + end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE; for_each_sgt_daddr(addr, iter, vma_res->bi.pages) iowrite32(vm->pte_encode(addr, level, flags), gte++); GEM_BUG_ON(gte > end); diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index 8c2f57eb5ddaa..2434197830523 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -44,7 +44,8 @@ int i915_gem_gtt_insert(struct i915_address_space *vm, #define PIN_HIGH BIT_ULL(5) #define PIN_OFFSET_BIAS
[pull] amdgpu drm-fixes-6.1
Hi Dave, Daniel, Just one last fix for 6.1. The following changes since commit b7b275e60bcd5f89771e865a8239325f86d9927d: Linux 6.1-rc7 (2022-11-27 13:31:48 -0800) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.1-2022-12-01 for you to fetch changes up to 9a8cc8cabc1e351614fd7f9e774757a5143b6fe8: drm/amdgpu: enable Vangogh VCN indirect sram mode (2022-12-01 15:09:49 -0500) amd-drm-fixes-6.1-2022-12-01: amdgpu: - VCN fix for vangogh Leo Liu (1): drm/amdgpu: enable Vangogh VCN indirect sram mode drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 3 +++ 1 file changed, 3 insertions(+)
Re: [PATCH 1/2] adreno: Shutdown the GPU properly
On Sat, Nov 12, 2022 at 6:44 PM Rob Clark wrote:
>
> On Fri, Nov 11, 2022 at 1:08 PM Joel Fernandes wrote:
> >
> >
> >
> > > On Nov 11, 2022, at 2:50 PM, Joel Fernandes (Google)
> > > wrote:
> > >
> > > During kexec on ARM device, we notice that device_shutdown() only calls
> > > pm_runtime_force_suspend() while shutting down the GPU. This means the GPU
> > > kthread is still running and further, there maybe active submits.
> > >
> > > This causes all kinds of issues during a kexec reboot:
> > >
> > > Warning from shutdown path:
> > >
> > > [ 292.509662] WARNING: CPU: 0 PID: 6304 at [...]
> > > adreno_runtime_suspend+0x3c/0x44
> > > [ 292.509863] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
> > > [ 292.509872] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
> > > BTYPE=--)
> > > [ 292.509881] pc : adreno_runtime_suspend+0x3c/0x44
> > > [ 292.509891] lr : pm_generic_runtime_suspend+0x30/0x44
> > > [ 292.509905] sp : ffc014473bf0
> > > [...]
> > > [ 292.510043] Call trace:
> > > [ 292.510051] adreno_runtime_suspend+0x3c/0x44
> > > [ 292.510061] pm_generic_runtime_suspend+0x30/0x44
> > > [ 292.510071] pm_runtime_force_suspend+0x54/0xc8
> > > [ 292.510081] adreno_shutdown+0x1c/0x28
> > > [ 292.510090] platform_shutdown+0x2c/0x38
> > > [ 292.510104] device_shutdown+0x158/0x210
> > > [ 292.510119] kernel_restart_prepare+0x40/0x4c
> > >
> > > And here from GPU kthread, an SError OOPs:
> > >
> > > [ 192.648789] el1h_64_error+0x7c/0x80
> > > [ 192.648812] el1_interrupt+0x20/0x58
> > > [ 192.648833] el1h_64_irq_handler+0x18/0x24
> > > [ 192.648854] el1h_64_irq+0x7c/0x80
> > > [ 192.648873] local_daif_inherit+0x10/0x18
> > > [ 192.648900] el1h_64_sync_handler+0x48/0xb4
> > > [ 192.648921] el1h_64_sync+0x7c/0x80
> > > [ 192.648941] a6xx_gmu_set_oob+0xbc/0x1fc
> > > [ 192.648968] a6xx_hw_init+0x44/0xe38
> > > [ 192.648991] msm_gpu_hw_init+0x48/0x80
> > > [ 192.649013] msm_gpu_submit+0x5c/0x1a8
> > > [ 192.649034] msm_job_run+0xb0/0x11c
> > > [ 192.649058] drm_sched_main+0x170/0x434
> > > [ 192.649086] kthread+0x134/0x300
> > > [ 192.649114] ret_from_fork+0x10/0x20
> > >
> > > Fix by calling adreno_system_suspend() in the device_shutdown() path.
> > >
> > > Cc: Rob Clark
> > > Cc: Steven Rostedt
> > > Cc: Ricardo Ribalda
> > > Cc: Ross Zwisler
> > > Signed-off-by: Joel Fernandes (Google)
> > > ---
> > > drivers/gpu/drm/msm/adreno/adreno_device.c | 5 -
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > index 24b489b6129a..f0cff62812c3 100644
> > > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > @@ -607,9 +607,12 @@ static int adreno_remove(struct platform_device
> > > *pdev)
> > >return 0;
> > > }
> > >
> > > +static int adreno_system_suspend(struct device *dev);
> > > static void adreno_shutdown(struct platform_device *pdev)
> > > {
> > > -pm_runtime_force_suspend(>dev);
> > > +struct msm_gpu *gpu = dev_to_gpu(>dev);
> > > +
> >
> > This local variable definition should go to patch 2/2. Will fix in v2.
> >
> > Thanks,
> >
> > - Joel
> >
> >
> > > +WARN_ON_ONCE(adreno_system_suspend(>dev));
>
> I think maybe adreno_unbind() needs the same treatment? Any path
> where we yank out the power cord without ensuring the scheduler is
> parked means we'd be racing with jobs in the scheduler queue. Ie.
> userspace could queue a job before it is frozen, but the drm/scheduler
> kthread hasn't yet called the msm_job_run() callback (which does
> various touching of the now powered off hw). So I think we need to
> ensure that the scheduler is parked in all paths that call
> pm_runtime_force_suspend() (as that bypasses the runpm reference that
> would otherwise unsure the hw is powered before msm_job_run pokes at
> registers)
a6xx_gmu_remove() calls pm_runtime_force_suspend() , would that need a
treatment too?
Though, adreno_system_suspend() is a static function in adreno_device.cc
Thanks.
Re: [PATCH 2/2] adreno: Detect shutdown during get_param()
On Thu, Dec 1, 2022 at 7:33 PM Rob Clark wrote:
>
> On Thu, Dec 1, 2022 at 10:42 AM Joel Fernandes wrote:
> >
> > On Sat, Nov 12, 2022 at 6:35 PM Rob Clark wrote:
> > >
> > > On Fri, Nov 11, 2022 at 1:28 PM Akhil P Oommen
> > > wrote:
> > > >
> > > > On 11/12/2022 1:19 AM, Joel Fernandes (Google) wrote:
> > > > > Even though the GPU is shut down, during kexec reboot we can have
> > > > > userspace
> > > > > still running. This is especially true if KEXEC_JUMP is not enabled,
> > > > > because we
> > > > > do not freeze userspace in this case.
> > > > >
> > > > > To prevent crashes, track that the GPU is shutdown and prevent
> > > > > get_param() from
> > > > > accessing GPU resources if we find it shutdown.
> > > > >
> > > > > This fixes the following crash during kexec reboot on an ARM64 device
> > > > > with adreno GPU:
> > > > >
> > > > > [ 292.534314] Kernel panic - not syncing: Asynchronous SError
> > > > > Interrupt
> > > > > [ 292.534323] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
> > > > > [ 292.534326] Call trace:
> > > > > [ 292.534328] dump_backtrace+0x0/0x1d4
> > > > > [ 292.534337] show_stack+0x20/0x2c
> > > > > [ 292.534342] dump_stack_lvl+0x60/0x78
> > > > > [ 292.534347] dump_stack+0x18/0x38
> > > > > [ 292.534352] panic+0x148/0x3b0
> > > > > [ 292.534357] nmi_panic+0x80/0x94
> > > > > [ 292.534364] arm64_serror_panic+0x70/0x7c
> > > > > [ 292.534369] do_serror+0x0/0x7c
> > > > > [ 292.534372] do_serror+0x54/0x7c
> > > > > [ 292.534377] el1h_64_error_handler+0x34/0x4c
> > > > > [ 292.534381] el1h_64_error+0x7c/0x80
> > > > > [ 292.534386] el1_interrupt+0x20/0x58
> > > > > [ 292.534389] el1h_64_irq_handler+0x18/0x24
> > > > > [ 292.534395] el1h_64_irq+0x7c/0x80
> > > > > [ 292.534399] local_daif_inherit+0x10/0x18
> > > > > [ 292.534405] el1h_64_sync_handler+0x48/0xb4
> > > > > [ 292.534410] el1h_64_sync+0x7c/0x80
> > > > > [ 292.534414] a6xx_gmu_set_oob+0xbc/0x1fc
> > > > > [ 292.534422] a6xx_get_timestamp+0x40/0xb4
> > > > > [ 292.534426] adreno_get_param+0x12c/0x1e0
> > > > > [ 292.534433] msm_ioctl_get_param+0x64/0x70
> > > > > [ 292.534440] drm_ioctl_kernel+0xe8/0x158
> > > > > [ 292.534448] drm_ioctl+0x208/0x320
> > > > > [ 292.534453] __arm64_sys_ioctl+0x98/0xd0
> > > > > [ 292.534461] invoke_syscall+0x4c/0x118
> > > > > [ 292.534467] el0_svc_common+0x98/0x104
> > > > > [ 292.534473] do_el0_svc+0x30/0x80
> > > > > [ 292.534478] el0_svc+0x20/0x50
> > > > > [ 292.534481] el0t_64_sync_handler+0x78/0x108
> > > > > [ 292.534485] el0t_64_sync+0x1a4/0x1a8
> > > > > [ 292.534632] Kernel Offset: 0x1a5f80 from 0xffc00800
> > > > > [ 292.534635] PHYS_OFFSET: 0x8000
> > > > > [ 292.534638] CPU features: 0x40018541,a3300e42
> > > > > [ 292.534644] Memory Limit: none
> > > > >
> > > > > Cc: Rob Clark
> > > > > Cc: Steven Rostedt
> > > > > Cc: Ricardo Ribalda
> > > > > Cc: Ross Zwisler
> > > > > Signed-off-by: Joel Fernandes (Google)
> > > > > ---
> > > > > drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
> > > > > drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
> > > > > drivers/gpu/drm/msm/msm_gpu.h | 3 +++
> > > > > 3 files changed, 5 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > > index f0cff62812c3..03d912dc0130 100644
> > > > > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > > @@ -612,6 +612,7 @@ static void adreno_shutdown(struct
> > > > > platform_device *pdev)
> > > > > {
> > > > > struct msm_gpu *gpu = dev_to_gpu(>dev);
> > > > >
> > > > > + gpu->is_shutdown = true;
> > > > > WARN_ON_ONCE(adreno_system_suspend(>dev));
> > > > > }
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > index 382fb7f9e497..6903c6892469 100644
> > > > > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > > @@ -251,7 +251,7 @@ int adreno_get_param(struct msm_gpu *gpu, struct
> > > > > msm_file_private *ctx,
> > > > > struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> > > > >
> > > > > /* No pointer params yet */
> > > > > - if (*len != 0)
> > > > > + if (*len != 0 || gpu->is_shutdown)
> > > > > return -EINVAL;
> > > > This will race with shutdown. Probably, propagating back the return
> > > > value of pm_runtime_get() in every possible ioctl call path is the right
> > > > thing to do.
> > > >
> > > > I have never thought about this scenario. Do you know why userspace is
> > > > not freezed before kexec?
> > >
> > > So userspace not being frozen seems like the root issue, and is likely
> > > to cause all sorts of other whack-a-mole problems. I guess I'd like
> > > to know if this is the expected
Re: [PATCH v2 01/12] dt-bindings: display: msm: Rename mdss node name in example
On 30/11/2022 22:09, Adam Skladowski wrote:
Follow other YAMLs and replace mdss name into display-subystem.
Signed-off-by: Adam Skladowski
Reviewed-by: Dmitry Baryshkov
We will pick this into msm-fixes during the next cycle.
---
.../devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 2 +-
.../devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
index d6f043a4b08d..4795e13c7b59 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
@@ -72,7 +72,7 @@ examples:
#include
#include
-mdss@5e0 {
+display-subsystem@5e0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "qcom,qcm2290-mdss";
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
index a86d7f53fa84..886858ef6700 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
@@ -62,7 +62,7 @@ examples:
#include
#include
-mdss@5e0 {
+display-subsystem@5e0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "qcom,sm6115-mdss";
--
With best wishes
Dmitry
Re: [PATCH] drm/fourcc: Document open source user waiver
Acked-by: Jason Ekstrand
On Thu, Dec 1, 2022 at 4:22 AM Daniel Vetter wrote:
> On Thu, 1 Dec 2022 at 11:07, Daniel Vetter wrote:
> >
> > On Wed, Nov 23, 2022 at 08:24:37PM +0100, Daniel Vetter wrote:
> > > It's a bit a FAQ, and we really can't claim to be the authoritative
> > > source for allocating these numbers used in many standard extensions
> > > if we tell closed source or vendor stacks in general to go away.
> > >
> > > Iirc this was already clarified in some vulkan discussions, but I
> > > can't find that anywhere anymore. At least not in a public link.
> > >
> > > Cc: Maarten Lankhorst
> > > Cc: Maxime Ripard
> > > Cc: Thomas Zimmermann
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > Cc: Alex Deucher
> > > Cc: Daniel Stone
> > > Cc: Bas Nieuwenhuizen
> > > Cc: Jason Ekstrand
> > > Cc: Neil Trevett
> > > Signed-off-by: Daniel Vetter
> >
> > From irc:
> >
> > danvet: ack from me
>
> Also from irc:
>
> danvet: Acked
>
> -Daniel
>
> > > ---
> > > include/uapi/drm/drm_fourcc.h | 12
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > > index bc056f2d537d..de703c6be969 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -88,6 +88,18 @@ extern "C" {
> > > *
> > > * The authoritative list of format modifier codes is found in
> > > * `include/uapi/drm/drm_fourcc.h`
> > > + *
> > > + * Open Source User Waiver
> > > + * ---
> > > + *
> > > + * Because this is the authoritative source for pixel formats and
> modifiers
> > > + * referenced by GL, Vulkan extensions and other standards and hence
> used both
> > > + * by open source and closed source driver stacks, the usual
> requirement for an
> > > + * upstream in-kernel or open source userspace user does not apply.
> > > + *
> > > + * To ensure, as much as feasible, compatibility across stacks and
> avoid
> > > + * confusion with incompatible enumerations stakeholders for all
> relevant driver
> > > + * stacks should approve additions.
> > > */
> > >
> > > #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
> > > --
> > > 2.37.2
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
Re: [PATCH v2 02/12] dt-bindings: thermal: tsens: Add SM6115 compatible
On Wed, 30 Nov 2022 21:09:40 +0100, Adam Skladowski wrote: > Document compatible for tsens on Qualcomm SM6115 platform > according to downstream dts it ship v2.4 of IP > > Signed-off-by: Adam Skladowski > Acked-by: Krzysztof Kozlowski > --- > Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + > 1 file changed, 1 insertion(+) > Since Daniel is out, applied, thanks!
Re: [PATCH 2/2] adreno: Detect shutdown during get_param()
On Thu, Dec 1, 2022 at 10:42 AM Joel Fernandes wrote:
>
> On Sat, Nov 12, 2022 at 6:35 PM Rob Clark wrote:
> >
> > On Fri, Nov 11, 2022 at 1:28 PM Akhil P Oommen
> > wrote:
> > >
> > > On 11/12/2022 1:19 AM, Joel Fernandes (Google) wrote:
> > > > Even though the GPU is shut down, during kexec reboot we can have
> > > > userspace
> > > > still running. This is especially true if KEXEC_JUMP is not enabled,
> > > > because we
> > > > do not freeze userspace in this case.
> > > >
> > > > To prevent crashes, track that the GPU is shutdown and prevent
> > > > get_param() from
> > > > accessing GPU resources if we find it shutdown.
> > > >
> > > > This fixes the following crash during kexec reboot on an ARM64 device
> > > > with adreno GPU:
> > > >
> > > > [ 292.534314] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > > [ 292.534323] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
> > > > [ 292.534326] Call trace:
> > > > [ 292.534328] dump_backtrace+0x0/0x1d4
> > > > [ 292.534337] show_stack+0x20/0x2c
> > > > [ 292.534342] dump_stack_lvl+0x60/0x78
> > > > [ 292.534347] dump_stack+0x18/0x38
> > > > [ 292.534352] panic+0x148/0x3b0
> > > > [ 292.534357] nmi_panic+0x80/0x94
> > > > [ 292.534364] arm64_serror_panic+0x70/0x7c
> > > > [ 292.534369] do_serror+0x0/0x7c
> > > > [ 292.534372] do_serror+0x54/0x7c
> > > > [ 292.534377] el1h_64_error_handler+0x34/0x4c
> > > > [ 292.534381] el1h_64_error+0x7c/0x80
> > > > [ 292.534386] el1_interrupt+0x20/0x58
> > > > [ 292.534389] el1h_64_irq_handler+0x18/0x24
> > > > [ 292.534395] el1h_64_irq+0x7c/0x80
> > > > [ 292.534399] local_daif_inherit+0x10/0x18
> > > > [ 292.534405] el1h_64_sync_handler+0x48/0xb4
> > > > [ 292.534410] el1h_64_sync+0x7c/0x80
> > > > [ 292.534414] a6xx_gmu_set_oob+0xbc/0x1fc
> > > > [ 292.534422] a6xx_get_timestamp+0x40/0xb4
> > > > [ 292.534426] adreno_get_param+0x12c/0x1e0
> > > > [ 292.534433] msm_ioctl_get_param+0x64/0x70
> > > > [ 292.534440] drm_ioctl_kernel+0xe8/0x158
> > > > [ 292.534448] drm_ioctl+0x208/0x320
> > > > [ 292.534453] __arm64_sys_ioctl+0x98/0xd0
> > > > [ 292.534461] invoke_syscall+0x4c/0x118
> > > > [ 292.534467] el0_svc_common+0x98/0x104
> > > > [ 292.534473] do_el0_svc+0x30/0x80
> > > > [ 292.534478] el0_svc+0x20/0x50
> > > > [ 292.534481] el0t_64_sync_handler+0x78/0x108
> > > > [ 292.534485] el0t_64_sync+0x1a4/0x1a8
> > > > [ 292.534632] Kernel Offset: 0x1a5f80 from 0xffc00800
> > > > [ 292.534635] PHYS_OFFSET: 0x8000
> > > > [ 292.534638] CPU features: 0x40018541,a3300e42
> > > > [ 292.534644] Memory Limit: none
> > > >
> > > > Cc: Rob Clark
> > > > Cc: Steven Rostedt
> > > > Cc: Ricardo Ribalda
> > > > Cc: Ross Zwisler
> > > > Signed-off-by: Joel Fernandes (Google)
> > > > ---
> > > > drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
> > > > drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
> > > > drivers/gpu/drm/msm/msm_gpu.h | 3 +++
> > > > 3 files changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > index f0cff62812c3..03d912dc0130 100644
> > > > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > > @@ -612,6 +612,7 @@ static void adreno_shutdown(struct platform_device
> > > > *pdev)
> > > > {
> > > > struct msm_gpu *gpu = dev_to_gpu(>dev);
> > > >
> > > > + gpu->is_shutdown = true;
> > > > WARN_ON_ONCE(adreno_system_suspend(>dev));
> > > > }
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > index 382fb7f9e497..6903c6892469 100644
> > > > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > > @@ -251,7 +251,7 @@ int adreno_get_param(struct msm_gpu *gpu, struct
> > > > msm_file_private *ctx,
> > > > struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> > > >
> > > > /* No pointer params yet */
> > > > - if (*len != 0)
> > > > + if (*len != 0 || gpu->is_shutdown)
> > > > return -EINVAL;
> > > This will race with shutdown. Probably, propagating back the return
> > > value of pm_runtime_get() in every possible ioctl call path is the right
> > > thing to do.
> > >
> > > I have never thought about this scenario. Do you know why userspace is
> > > not freezed before kexec?
> >
> > So userspace not being frozen seems like the root issue, and is likely
> > to cause all sorts of other whack-a-mole problems. I guess I'd like
> > to know if this is the expected behavior?
>
> We tried that. Freezing before kexec seems to cause issues for ALSA as
> Ricardo found:
> https://lore.kernel.org/lkml/202211281209.mnblzq2i-...@intel.com/T/
>
> That patch is still TBD due to disagreement on the right approach to
> fix, so I don't think freezing
Re: [Intel-gfx] [PATCH v6 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915
On Wed, 2022-11-30 at 17:42 +, Vivi, Rodrigo wrote: > On Wed, 2022-11-30 at 09:32 -0800, Matt Roper wrote: > > On Tue, Nov 29, 2022 at 06:02:45PM -0800, Alan Previn wrote: > > > Starting with MTL, there will be two GT-tiles, a render and media > > > tile. PXP as a service for supporting workloads with protected > > > > Drive-by comment: we've been a bit inconsistent about terminology in > > the past, but my understanding is that we're trying to standardize on > > "GT" for the unit that MTL has two of, and keeping the term "tile" > > for > > the PVC-style unit that is a combination of (GT+lmem). > > I agree that this gets really confusing... but it will be hard to > standardize this I'm afraid. Specially when we do the PVC-style-tile a > intel_gt struct and we apparently are doing the same on MTL, no?! > > So, unless the topology gets organized in the code with a standard > name, it is hard to demand everyone to use the same one. > > Besides that whenever we were discussing the pvc's one we all had > agreed that the term "tile" was bad, hence we focused on keep the > intel_gt ready for that. > > Whenever I hear tile I think of the display buffer organization... > and there are other "tiles" examples iirc. > > Yeah... GPU is so complex these days, a single subssytem is like a whole SOC back in the day ... beside display tiling formats, media's HEVC has "tiles" that is kinda like macro-blocks and who can forget render's tiled-rendering (all 3 similar but can be completely orthogonal depending on the hw config / buffer state / usage). I'm assuming this conversation is a nit. Please correct me otherwise.
Re: [PATCH] drm/vmwgfx: Don't use screen objects when SEV is active
From: Martin Krastev
LGTM!
Reviewed-by: Martin Krastev
Regards,
Martin
On 1.12.22 г. 19:53 ч., Zack Rusin wrote:
From: Zack Rusin
When SEV is enabled gmr's and mob's are explicitly disabled because
the encrypted system memory can not be used by the hypervisor.
The driver was disabling GMR's but the presentation code, which depends
on GMR's, wasn't honoring it which lead to black screen on hosts
with SEV enabled.
Make sure screen objects presentation is not used when guest memory
regions have been disabled to fix presentation on SEV enabled hosts.
Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is
active")
Cc: # v5.7+
Signed-off-by: Zack Rusin
Reported-by: Nicholas Hunt
---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 8db61c541a80..e1f36a09c59c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -926,6 +926,10 @@ int vmw_kms_sou_init_display(struct vmw_private *dev_priv)
struct drm_device *dev = _priv->drm;
int i;
+ /* Screen objects won't work if GMR's aren't available */
+ if (!dev_priv->has_gmr)
+ return -ENOSYS;
+
if (!(dev_priv->capabilities & SVGA_CAP_SCREEN_OBJECT_2)) {
return -ENOSYS;
}
Re: [Intel-gfx] [PATCH v8 22/22] drm/i915/vm_bind: Support capture of persistent mappings
On Thu, Dec 01, 2022 at 07:27:31AM -0800, Niranjana Vishwanathapura wrote:
On Thu, Dec 01, 2022 at 10:49:15AM +, Matthew Auld wrote:
On 29/11/2022 07:26, Niranjana Vishwanathapura wrote:
Support dump capture of persistent mappings upon user request.
Signed-off-by: Brian Welty
Signed-off-by: Niranjana Vishwanathapura
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 11 +++
drivers/gpu/drm/i915/gt/intel_gtt.c | 3 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 5 +
drivers/gpu/drm/i915/i915_gpu_error.c | 19 +++
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 ++
include/uapi/drm/i915_drm.h | 3 ++-
7 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 78e7c0642c5f..50969613daf6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -88,6 +88,11 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma,
bool release_obj)
{
lockdep_assert_held(>vm->vm_bind_lock);
+ spin_lock(>vm->vm_capture_lock);
+ if (!list_empty(>vm_capture_link))
+ list_del_init(>vm_capture_link);
+ spin_unlock(>vm->vm_capture_lock);
+
spin_lock(>vm->vm_rebind_lock);
if (!list_empty(>vm_rebind_link))
list_del_init(>vm_rebind_link);
@@ -357,6 +362,12 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
continue;
}
+ if (va->flags & I915_GEM_VM_BIND_CAPTURE) {
+ spin_lock(>vm_capture_lock);
+ list_add_tail(>vm_capture_link,
>vm_capture_list);
+ spin_unlock(>vm_capture_lock);
+ }
+
list_add_tail(>vm_bind_link, >vm_bound_list);
i915_vm_bind_it_insert(vma, >va);
if (!obj->priv_root)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index ebf6830574a0..bdabe13fc30e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -297,6 +297,9 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
spin_lock_init(>vm_rebind_lock);
spin_lock_init(>userptr_invalidated_lock);
INIT_LIST_HEAD(>userptr_invalidated_list);
+
+ INIT_LIST_HEAD(>vm_capture_list);
+ spin_lock_init(>vm_capture_lock);
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 87e5b6568a00..8e4ddd073348 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -281,6 +281,11 @@ struct i915_address_space {
/** @root_obj: root object for dma-resv sharing by private objects */
struct drm_i915_gem_object *root_obj;
+ /* @vm_capture_list: list of vm captures */
+ struct list_head vm_capture_list;
+ /* @vm_capture_lock: protects vm_capture_list */
+ spinlock_t vm_capture_lock;
+
/* Global GTT */
bool is_ggtt:1;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64..3b2b12a739f7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1460,6 +1460,22 @@ capture_vma(struct intel_engine_capture_vma *next,
return next;
}
+static struct intel_engine_capture_vma *
+capture_user_vm(struct intel_engine_capture_vma *capture,
+ struct i915_address_space *vm, gfp_t gfp)
+{
+ struct i915_vma *vma;
+
+ spin_lock(>vm_capture_lock);
Does it make sense to move this into the eb3 submission stage, like
we do for eb2? IIRC the gfp flags here are quite limiting due to
potentially being in a fence critical section. If we can use
rq->capture_list for eb3, we shouldn't need to change much here?
But that will add latency on submission path as we will have to iterate
over capture_list in each submission. Besides, unlike eb2 case, we can't
just transfer the list to rq->capture_list as we will have to do this
for each submission. It was discussed long time back and decided not to
bother the fast path (submision) scenario with this error capture which
is only required upon gpu hang (slow path).
Also there is the existing CONFIG_DRM_I915_CAPTURE_ERROR. Should we
take that into account?
Ok, will fix.
+ /* vma->resource must be valid here as persistent vmas are bound */
+ list_for_each_entry(vma, >vm_capture_list, vm_capture_link)
+ capture = capture_vma_snapshot(capture, vma->resource,
+ gfp, "user");
+ spin_unlock(>vm_capture_lock);
+
+ return capture;
+}
+
static struct
Re: [PATCH 2/2] adreno: Detect shutdown during get_param()
On Sat, Nov 12, 2022 at 6:35 PM Rob Clark wrote:
>
> On Fri, Nov 11, 2022 at 1:28 PM Akhil P Oommen
> wrote:
> >
> > On 11/12/2022 1:19 AM, Joel Fernandes (Google) wrote:
> > > Even though the GPU is shut down, during kexec reboot we can have
> > > userspace
> > > still running. This is especially true if KEXEC_JUMP is not enabled,
> > > because we
> > > do not freeze userspace in this case.
> > >
> > > To prevent crashes, track that the GPU is shutdown and prevent
> > > get_param() from
> > > accessing GPU resources if we find it shutdown.
> > >
> > > This fixes the following crash during kexec reboot on an ARM64 device
> > > with adreno GPU:
> > >
> > > [ 292.534314] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > [ 292.534323] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
> > > [ 292.534326] Call trace:
> > > [ 292.534328] dump_backtrace+0x0/0x1d4
> > > [ 292.534337] show_stack+0x20/0x2c
> > > [ 292.534342] dump_stack_lvl+0x60/0x78
> > > [ 292.534347] dump_stack+0x18/0x38
> > > [ 292.534352] panic+0x148/0x3b0
> > > [ 292.534357] nmi_panic+0x80/0x94
> > > [ 292.534364] arm64_serror_panic+0x70/0x7c
> > > [ 292.534369] do_serror+0x0/0x7c
> > > [ 292.534372] do_serror+0x54/0x7c
> > > [ 292.534377] el1h_64_error_handler+0x34/0x4c
> > > [ 292.534381] el1h_64_error+0x7c/0x80
> > > [ 292.534386] el1_interrupt+0x20/0x58
> > > [ 292.534389] el1h_64_irq_handler+0x18/0x24
> > > [ 292.534395] el1h_64_irq+0x7c/0x80
> > > [ 292.534399] local_daif_inherit+0x10/0x18
> > > [ 292.534405] el1h_64_sync_handler+0x48/0xb4
> > > [ 292.534410] el1h_64_sync+0x7c/0x80
> > > [ 292.534414] a6xx_gmu_set_oob+0xbc/0x1fc
> > > [ 292.534422] a6xx_get_timestamp+0x40/0xb4
> > > [ 292.534426] adreno_get_param+0x12c/0x1e0
> > > [ 292.534433] msm_ioctl_get_param+0x64/0x70
> > > [ 292.534440] drm_ioctl_kernel+0xe8/0x158
> > > [ 292.534448] drm_ioctl+0x208/0x320
> > > [ 292.534453] __arm64_sys_ioctl+0x98/0xd0
> > > [ 292.534461] invoke_syscall+0x4c/0x118
> > > [ 292.534467] el0_svc_common+0x98/0x104
> > > [ 292.534473] do_el0_svc+0x30/0x80
> > > [ 292.534478] el0_svc+0x20/0x50
> > > [ 292.534481] el0t_64_sync_handler+0x78/0x108
> > > [ 292.534485] el0t_64_sync+0x1a4/0x1a8
> > > [ 292.534632] Kernel Offset: 0x1a5f80 from 0xffc00800
> > > [ 292.534635] PHYS_OFFSET: 0x8000
> > > [ 292.534638] CPU features: 0x40018541,a3300e42
> > > [ 292.534644] Memory Limit: none
> > >
> > > Cc: Rob Clark
> > > Cc: Steven Rostedt
> > > Cc: Ricardo Ribalda
> > > Cc: Ross Zwisler
> > > Signed-off-by: Joel Fernandes (Google)
> > > ---
> > > drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
> > > drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
> > > drivers/gpu/drm/msm/msm_gpu.h | 3 +++
> > > 3 files changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > index f0cff62812c3..03d912dc0130 100644
> > > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > > @@ -612,6 +612,7 @@ static void adreno_shutdown(struct platform_device
> > > *pdev)
> > > {
> > > struct msm_gpu *gpu = dev_to_gpu(>dev);
> > >
> > > + gpu->is_shutdown = true;
> > > WARN_ON_ONCE(adreno_system_suspend(>dev));
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > index 382fb7f9e497..6903c6892469 100644
> > > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > @@ -251,7 +251,7 @@ int adreno_get_param(struct msm_gpu *gpu, struct
> > > msm_file_private *ctx,
> > > struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> > >
> > > /* No pointer params yet */
> > > - if (*len != 0)
> > > + if (*len != 0 || gpu->is_shutdown)
> > > return -EINVAL;
> > This will race with shutdown. Probably, propagating back the return
> > value of pm_runtime_get() in every possible ioctl call path is the right
> > thing to do.
> >
> > I have never thought about this scenario. Do you know why userspace is
> > not freezed before kexec?
>
> So userspace not being frozen seems like the root issue, and is likely
> to cause all sorts of other whack-a-mole problems. I guess I'd like
> to know if this is the expected behavior?
We tried that. Freezing before kexec seems to cause issues for ALSA as
Ricardo found:
https://lore.kernel.org/lkml/202211281209.mnblzq2i-...@intel.com/T/
That patch is still TBD due to disagreement on the right approach to
fix, so I don't think freezing before shutting down devices is viable
at the moment.
I am checking Ricardo if we can do something like util-linux's
shutdown code which sends SIGTERM to all processes:
https://kernel.googlesource.com/pub/scm/utils/util-linux/util-linux/+/v2.8/login-utils/shutdown.c#273
, before
Re: [PATCH v5 5/7] drm/etnaviv: Add nn_core_count to chip feature struct
Am Donnerstag, dem 01.12.2022 um 11:30 +0100 schrieb Tomeu Vizoso:
> We will use these for differentiating between GPUs and NPUs, as the
> downstream driver does.
>
Thanks, patches 5-7 applied to my etnaviv/next branch.
Regards,
Lucas
> Signed-off-by: Tomeu Vizoso
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
> drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 4
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index 85eddd492774..c8f3ad2031ce 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -50,6 +50,9 @@ struct etnaviv_chip_identity {
> /* Number of shader cores. */
> u32 shader_core_count;
>
> + /* Number of Neural Network cores. */
> + u32 nn_core_count;
> +
> /* Size of the vertex cache. */
> u32 vertex_cache_size;
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> index f2fc645c7956..44df273a5aae 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> @@ -16,6 +16,7 @@ static const struct etnaviv_chip_identity
> etnaviv_chip_identities[] = {
> .register_max = 64,
> .thread_count = 128,
> .shader_core_count = 1,
> + .nn_core_count = 0,
> .vertex_cache_size = 8,
> .vertex_output_buffer_size = 1024,
> .pixel_pipes = 1,
> @@ -47,6 +48,7 @@ static const struct etnaviv_chip_identity
> etnaviv_chip_identities[] = {
> .register_max = 64,
> .thread_count = 512,
> .shader_core_count = 2,
> + .nn_core_count = 0,
> .vertex_cache_size = 16,
> .vertex_output_buffer_size = 1024,
> .pixel_pipes = 1,
> @@ -78,6 +80,7 @@ static const struct etnaviv_chip_identity
> etnaviv_chip_identities[] = {
> .register_max = 64,
> .thread_count = 512,
> .shader_core_count = 2,
> + .nn_core_count = 0,
> .vertex_cache_size = 16,
> .vertex_output_buffer_size = 1024,
> .pixel_pipes = 1,
> @@ -109,6 +112,7 @@ static const struct etnaviv_chip_identity
> etnaviv_chip_identities[] = {
> .register_max = 64,
> .thread_count = 1024,
> .shader_core_count = 4,
> + .nn_core_count = 0,
> .vertex_cache_size = 16,
> .vertex_output_buffer_size = 1024,
> .pixel_pipes = 2,
[linux-next:master] BUILD REGRESSION 2934ceb4e967b9233d0f97732e47175574a11406
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 2934ceb4e967b9233d0f97732e47175574a11406 Add linux-next specific files for 20221201 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211090634.ryfkk0ws-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211242021.fdzrfna8-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211242120.mzzvguln-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211301840.y7rrob13-...@intel.com https://lore.kernel.org/oe-kbuild-all/202212011005.7x5xasmg-...@intel.com https://lore.kernel.org/oe-kbuild-all/202212020122.myyqvrxj-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/arm/mach-s3c/devs.c:32:10: fatal error: linux/platform_data/dma-s3c24xx.h: No such file or directory arch/loongarch/kernel/ftrace_dyn.c:47:36: error: invalid use of undefined type 'struct module' arch/powerpc/kernel/kvm_emul.o: warning: objtool: kvm_template_end(): can't find starting instruction arch/powerpc/kernel/optprobes_head.o: warning: objtool: optprobe_template_end(): can't find starting instruction drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:40:20: warning: no previous prototype for 'to_dal_irq_source_dcn201' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous prototype for 'gf100_fifo_nonstall_block' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous prototype for function 'gf100_fifo_nonstall_block' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous prototype for 'nvkm_engn_cgrp_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous prototype for function 'nvkm_engn_cgrp_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for 'tu102_gr_load' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for function 'tu102_gr_load' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype for 'wpr_generic_header_dump' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype for function 'wpr_generic_header_dump' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c:221:21: warning: variable 'loc' set but not used [-Wunused-but-set-variable] drivers/irqchip/irq-loongarch-cpu.c:96:12: warning: no previous prototype for 'loongarch_cpu_irq_of_init' [-Wmissing-prototypes] drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:1849:38: warning: unused variable 'mt8173_jpeg_drvdata' [-Wunused-const-variable] drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:1864:38: warning: unused variable 'mtk_jpeg_drvdata' [-Wunused-const-variable] drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:1890:38: warning: unused variable 'mtk8195_jpegdec_drvdata' [-Wunused-const-variable] drivers/regulator/tps65219-regulator.c:310:60: warning: parameter 'dev' set but not used [-Wunused-but-set-parameter] drivers/regulator/tps65219-regulator.c:370:26: warning: ordered comparison of pointer with integer zero [-Wextra] net/netfilter/nf_conntrack_netlink.c:2674:6: warning: unused variable 'mark' [-Wunused-variable] vmlinux.o: warning: objtool: __btrfs_map_block+0x1d77: unreachable instruction Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-irq-dcn201-irq_service_dcn201.c:warning:no-previous-prototype-for-to_dal_irq_source_dcn201 | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-gf100.c:warning:no-previous-prototype-for-gf100_fifo_nonstall_block | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-runl.c:warning:no-previous-prototype-for-nvkm_engn_cgrp_get | |-- drivers-gpu-drm-nouveau-nvkm-engine-gr-tu102.c:warning:no-previous-prototype-for-tu102_gr_load | |-- drivers-gpu-drm-nouveau-nvkm-nvfw-acr.c:warning:no-previous-prototype-for-wpr_generic_header_dump | |-- drivers-gpu-drm-nouveau-nvkm-subdev-acr-lsfw.c:warning:variable-loc-set-but-not-used | |-- drivers-regulator-tps65219-regulator.c:warning:ordered-comparison-of-pointer-with-integer-zero | `-- drivers-regulator-tps65219-regulator.c:warning:parameter-dev-set-but-not-used |-- alpha-randconfig-r005-20221128 | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-gf100.c:warning:no-previous-prototype-for-gf100_fifo_nonstall_block | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-runl.c:warning:no-previous-prototype-for-nvkm_engn_cgrp_get | |-- drivers-gpu-drm-nouveau-nvkm-engine-gr-tu102.c:warning:no-previous-prototype-for-tu102_gr_load | |-- drivers-gpu-drm-nouveau-nvkm-nvfw-acr.c:warning:no-previous-prototype-for-wpr_generic_header_dump
[PATCH] drm/vmwgfx: Don't use screen objects when SEV is active
From: Zack Rusin
When SEV is enabled gmr's and mob's are explicitly disabled because
the encrypted system memory can not be used by the hypervisor.
The driver was disabling GMR's but the presentation code, which depends
on GMR's, wasn't honoring it which lead to black screen on hosts
with SEV enabled.
Make sure screen objects presentation is not used when guest memory
regions have been disabled to fix presentation on SEV enabled hosts.
Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is
active")
Cc: # v5.7+
Signed-off-by: Zack Rusin
Reported-by: Nicholas Hunt
---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 8db61c541a80..e1f36a09c59c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -926,6 +926,10 @@ int vmw_kms_sou_init_display(struct vmw_private *dev_priv)
struct drm_device *dev = _priv->drm;
int i;
+ /* Screen objects won't work if GMR's aren't available */
+ if (!dev_priv->has_gmr)
+ return -ENOSYS;
+
if (!(dev_priv->capabilities & SVGA_CAP_SCREEN_OBJECT_2)) {
return -ENOSYS;
}
--
2.37.2
Re: [PATCH v6 1/4] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint
On 01/12/2022 19:32, Kuogee Hsieh wrote:
On 11/30/2022 4:21 PM, Dmitry Baryshkov wrote:
On 01/12/2022 02:07, Dmitry Baryshkov wrote:
On 01/12/2022 01:51, Kuogee Hsieh wrote:
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi
Changes in v6:
-- add data-lanes and link-frequencies to yaml
Signed-off-by: Kuogee Hsieh
---
.../devicetree/bindings/display/msm/dp-controller.yaml | 17
+
Separate patch. Also you didn't check the get_maintainers output, so
required parties were not included into the distribution.
Also as you'd check the get_maintainers output, please fix other
email addresses too.
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +-
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 94bc6e1..af70343 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -90,6 +90,20 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+
+ properties:
+ link-frequencies: true
+ data-lanes: true
No. Use $ref for both of them.
+
+ required:
+ - link-frequencies
+ - data-lanes
No, they are not required.
+
+ additionalProperties: false
+
deprecation of old data-lanes property?
required:
- compatible
- reg
@@ -158,6 +172,9 @@ examples:
reg = <1>;
endpoint {
remote-endpoint = <>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <16000 27000
s/1600/1620
+ 54000 81000>;
I guess the number of zeroes is wrong here. This is 160 MHz ... 810
Mhz, rather than 1.6 GHz ... 8.1 GHz
Ok, I was wrong here. The old code definitely defaults to 570
mega-something. Now I'd really like to read your description for the
link-frequencies property, because the
phy_configure_opts_dp::link_rate is clearly specified in Mb/s and it
takes a fixed set of values from 1.62 Gb/s up to 8.1 Gb/s.
I think the drm_dp_bw_code_to_link_rate() function is incorrect by
itself, as it multiplies with 27000 (27 Mbps) rather than 27 (0.27
Gbps) as required by the standard. So first, we should fix the
function, then all the rates would become logical.
no, drm_dp_bw_code_to_link_rate() is correct and should not be changes
since it impact to other dp drivers too.
0.27Gbps/lane is specified at DP spec.
DP use 8b/10b coding rule (10 bits symbol contains 8 bits data).
At least it should get documentation that it returns Kylo-bytes per second.
But, getting back to link-frequencies. The documentation clearly says
that it should be allowed data bus _frequencies_. And frequencies are
measured in Hz, not in bits/sec or bytes/sec.
};
};
};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 754d2d6..39f0844 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -812,7 +812,11 @@ hp_i2c: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <16000 27000 54000>;
Same comment here.
};
_adc {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 93e39fc..b7c343d 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -440,7 +440,11 @@ ap_i2c_tpm: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <16000 27000 54000
81000>;
And here.
};
_mdp {
--
With best wishes
Dmitry
[PATCH 2/2] drm/etnaviv: convert user fence tracking to XArray
This simplifies the driver code a bit, as XArray already provides
internal locking. IDRs are implemented using XArrays anyways, so
this drops one level of unneeded abstraction.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h| 1 +
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 9 +
drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 7 +++
drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 13 +
5 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index f32f4771dada..778394e85c3d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 2337b24b05b0..cc9d8b8f76f0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -393,10 +393,11 @@ static void submit_cleanup(struct kref *kref)
wake_up_all(>gpu->fence_event);
if (submit->out_fence) {
- /* first remove from IDR, so fence can not be found anymore */
- mutex_lock(>gpu->idr_lock);
- idr_remove(>gpu->fence_idr, submit->out_fence_id);
- mutex_unlock(>gpu->idr_lock);
+ /*
+* Remove from user fence array before dropping the reference,
+* so fence can not be found in lookup anymore.
+*/
+ xa_erase(>gpu->user_fences, submit->out_fence_id);
dma_fence_put(submit->out_fence);
}
kfree(submit->pmrs);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 30d7c1d8d6c0..f7375d9e1716 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1216,7 +1216,7 @@ int etnaviv_gpu_wait_fence_interruptible(struct
etnaviv_gpu *gpu,
* pretends we didn't find a fence in that case.
*/
rcu_read_lock();
- fence = idr_find(>fence_idr, id);
+ fence = xa_load(>user_fences, id);
if (fence)
fence = dma_fence_get_rcu(fence);
rcu_read_unlock();
@@ -1700,7 +1700,7 @@ static int etnaviv_gpu_bind(struct device *dev, struct
device *master,
gpu->drm = drm;
gpu->fence_context = dma_fence_context_alloc(1);
- idr_init(>fence_idr);
+ xa_init_flags(>user_fences, XA_FLAGS_ALLOC);
spin_lock_init(>fence_spinlock);
INIT_WORK(>sync_point_work, sync_point_worker);
@@ -1754,7 +1754,7 @@ static void etnaviv_gpu_unbind(struct device *dev, struct
device *master,
}
gpu->drm = NULL;
- idr_destroy(>fence_idr);
+ xa_destroy(>user_fences);
if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL))
thermal_cooling_device_unregister(gpu->cooling);
@@ -1787,7 +1787,6 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
gpu->dev = >dev;
mutex_init(>lock);
mutex_init(>sched_lock);
- mutex_init(>idr_lock);
/* Map registers: */
gpu->mmio = devm_platform_ioremap_resource(pdev, 0);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 267d8ec97f11..9b6773051773 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -117,8 +117,8 @@ struct etnaviv_gpu {
u32 idle_mask;
/* Fencing support */
- struct mutex idr_lock;
- struct idr fence_idr;
+ struct xarray user_fences;
+ u32 next_user_fence;
u32 next_fence;
u32 completed_fence;
wait_queue_head_t fence_event;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 27448431a45c..39ca04cf2dd5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -98,7 +98,7 @@ static const struct drm_sched_backend_ops etnaviv_sched_ops =
{
int etnaviv_sched_push_job(struct etnaviv_gem_submit *submit)
{
struct etnaviv_gpu *gpu = submit->gpu;
- int ret = 0;
+ int ret;
/*
* Hold the sched lock across the whole operation to avoid jobs being
@@ -110,14 +110,11 @@ int etnaviv_sched_push_job(struct etnaviv_gem_submit
*submit)
drm_sched_job_arm(>sched_job);
submit->out_fence = dma_fence_get(>sched_job.s_fence->finished);
- mutex_lock(>idr_lock);
- submit->out_fence_id = idr_alloc_cyclic(>fence_idr,
- submit->out_fence, 0,
- INT_MAX, GFP_KERNEL);
- mutex_unlock(>idr_lock);
- if (submit->out_fence_id < 0) {
+ ret =
[PATCH 1/2] drm/etnaviv: split fence lock
The fence lock currently protects two distinct things. It protects the fence
IDR from concurrent inserts and removes and also keeps drm_sched_job_arm and
drm_sched_entity_push_job in one atomic section to guarantee the fence seqno
monotonicity. Split the lock into those two functions.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 3 ++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 3 ++-
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 11 +++
4 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 1ac916b24891..2337b24b05b0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -394,9 +394,9 @@ static void submit_cleanup(struct kref *kref)
if (submit->out_fence) {
/* first remove from IDR, so fence can not be found anymore */
- mutex_lock(>gpu->fence_lock);
+ mutex_lock(>gpu->idr_lock);
idr_remove(>gpu->fence_idr, submit->out_fence_id);
- mutex_unlock(>gpu->fence_lock);
+ mutex_unlock(>gpu->idr_lock);
dma_fence_put(submit->out_fence);
}
kfree(submit->pmrs);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 37018bc55810..30d7c1d8d6c0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1786,7 +1786,8 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
gpu->dev = >dev;
mutex_init(>lock);
- mutex_init(>fence_lock);
+ mutex_init(>sched_lock);
+ mutex_init(>idr_lock);
/* Map registers: */
gpu->mmio = devm_platform_ioremap_resource(pdev, 0);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 85eddd492774..267d8ec97f11 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -99,6 +99,7 @@ struct etnaviv_gpu {
struct etnaviv_chip_identity identity;
enum etnaviv_sec_mode sec_mode;
struct workqueue_struct *wq;
+ struct mutex sched_lock;
struct drm_gpu_scheduler sched;
bool initialized;
bool fe_running;
@@ -116,7 +117,7 @@ struct etnaviv_gpu {
u32 idle_mask;
/* Fencing support */
- struct mutex fence_lock;
+ struct mutex idr_lock;
struct idr fence_idr;
u32 next_fence;
u32 completed_fence;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 72e2553fbc98..27448431a45c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -97,21 +97,24 @@ static const struct drm_sched_backend_ops etnaviv_sched_ops
= {
int etnaviv_sched_push_job(struct etnaviv_gem_submit *submit)
{
+ struct etnaviv_gpu *gpu = submit->gpu;
int ret = 0;
/*
-* Hold the fence lock across the whole operation to avoid jobs being
+* Hold the sched lock across the whole operation to avoid jobs being
* pushed out of order with regard to their sched fence seqnos as
* allocated in drm_sched_job_arm.
*/
- mutex_lock(>gpu->fence_lock);
+ mutex_lock(>sched_lock);
drm_sched_job_arm(>sched_job);
submit->out_fence = dma_fence_get(>sched_job.s_fence->finished);
- submit->out_fence_id = idr_alloc_cyclic(>gpu->fence_idr,
+ mutex_lock(>idr_lock);
+ submit->out_fence_id = idr_alloc_cyclic(>fence_idr,
submit->out_fence, 0,
INT_MAX, GFP_KERNEL);
+ mutex_unlock(>idr_lock);
if (submit->out_fence_id < 0) {
drm_sched_job_cleanup(>sched_job);
ret = -ENOMEM;
@@ -124,7 +127,7 @@ int etnaviv_sched_push_job(struct etnaviv_gem_submit
*submit)
drm_sched_entity_push_job(>sched_job);
out_unlock:
- mutex_unlock(>gpu->fence_lock);
+ mutex_unlock(>sched_lock);
return ret;
}
--
2.30.2
[PATCH v2 1/2] drm/etnaviv: update hardware headers from rnndb
Update the state HI header from the rnndb commit
5bf18f7d9a97 ("rnndb: expand MMU exception bitfields").
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/state_hi.xml.h | 86 +-
1 file changed, 70 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h
b/drivers/gpu/drm/etnaviv/state_hi.xml.h
index deaaa99fa654..138adb8eb68e 100644
--- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
+++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
@@ -8,17 +8,17 @@ This file was generated by the rules-ng-ng headergen tool in
this git repository
git clone git://0x04.net/rules-ng-ng
The rules-ng-ng source files this header was generated from are:
-- state.xml ( 2 bytes, from 2019-12-20 21:20:35)
-- common.xml( 35468 bytes, from 2018-02-10 13:09:26)
-- common_3d.xml ( 15058 bytes, from 2019-12-28 20:02:03)
-- state_hi.xml ( 30552 bytes, from 2019-12-28 20:02:48)
-- copyright.xml ( 1597 bytes, from 2018-02-10 13:09:26)
-- state_2d.xml ( 51552 bytes, from 2018-02-10 13:09:26)
-- state_3d.xml ( 83098 bytes, from 2019-12-28 20:02:03)
-- state_blt.xml ( 14252 bytes, from 2019-10-20 19:59:15)
-- state_vg.xml ( 5975 bytes, from 2018-02-10 13:09:26)
-
-Copyright (C) 2012-2019 by the following authors:
+- state.xml ( 27198 bytes, from 2022-04-22 10:35:24)
+- common.xml( 35468 bytes, from 2020-10-28 12:56:03)
+- common_3d.xml ( 15058 bytes, from 2020-10-28 12:56:03)
+- state_hi.xml ( 34804 bytes, from 2022-12-01 09:25:17)
+- copyright.xml ( 1597 bytes, from 2020-10-28 12:56:03)
+- state_2d.xml ( 51552 bytes, from 2020-10-28 12:56:03)
+- state_3d.xml ( 84445 bytes, from 2022-11-15 15:59:38)
+- state_blt.xml ( 14424 bytes, from 2022-11-07 11:18:41)
+- state_vg.xml ( 5975 bytes, from 2020-10-28 12:56:03)
+
+Copyright (C) 2012-2022 by the following authors:
- Wladimir J. van der Laan
- Christian Gmeiner
- Lucas Stach
@@ -321,16 +321,16 @@ DEALINGS IN THE SOFTWARE.
#define VIVS_MMUv2_CONFIGURATION_ADDRESS(x)(((x) <<
VIVS_MMUv2_CONFIGURATION_ADDRESS__SHIFT) &
VIVS_MMUv2_CONFIGURATION_ADDRESS__MASK)
#define VIVS_MMUv2_STATUS 0x0188
-#define VIVS_MMUv2_STATUS_EXCEPTION0__MASK 0x0003
+#define VIVS_MMUv2_STATUS_EXCEPTION0__MASK 0x000f
#define VIVS_MMUv2_STATUS_EXCEPTION0__SHIFT0
#define VIVS_MMUv2_STATUS_EXCEPTION0(x)(((x)
<< VIVS_MMUv2_STATUS_EXCEPTION0__SHIFT) & VIVS_MMUv2_STATUS_EXCEPTION0__MASK)
-#define VIVS_MMUv2_STATUS_EXCEPTION1__MASK 0x0030
+#define VIVS_MMUv2_STATUS_EXCEPTION1__MASK 0x00f0
#define VIVS_MMUv2_STATUS_EXCEPTION1__SHIFT4
#define VIVS_MMUv2_STATUS_EXCEPTION1(x)(((x)
<< VIVS_MMUv2_STATUS_EXCEPTION1__SHIFT) & VIVS_MMUv2_STATUS_EXCEPTION1__MASK)
-#define VIVS_MMUv2_STATUS_EXCEPTION2__MASK 0x0300
+#define VIVS_MMUv2_STATUS_EXCEPTION2__MASK 0x0f00
#define VIVS_MMUv2_STATUS_EXCEPTION2__SHIFT8
#define VIVS_MMUv2_STATUS_EXCEPTION2(x)(((x)
<< VIVS_MMUv2_STATUS_EXCEPTION2__SHIFT) & VIVS_MMUv2_STATUS_EXCEPTION2__MASK)
-#define VIVS_MMUv2_STATUS_EXCEPTION3__MASK 0x3000
+#define VIVS_MMUv2_STATUS_EXCEPTION3__MASK 0xf000
#define VIVS_MMUv2_STATUS_EXCEPTION3__SHIFT12
#define VIVS_MMUv2_STATUS_EXCEPTION3(x)(((x)
<< VIVS_MMUv2_STATUS_EXCEPTION3__SHIFT) & VIVS_MMUv2_STATUS_EXCEPTION3__MASK)
@@ -465,7 +465,13 @@ DEALINGS IN THE SOFTWARE.
#define VIVS_MC_PROFILE_CONFIG0
0x0470
#define VIVS_MC_PROFILE_CONFIG0_FE__MASK 0x00ff
#define VIVS_MC_PROFILE_CONFIG0_FE__SHIFT 0
+#define VIVS_MC_PROFILE_CONFIG0_FE_DRAW_COUNT 0x000a
+#define VIVS_MC_PROFILE_CONFIG0_FE_OUT_VERTEX_COUNT0x000b
+#define VIVS_MC_PROFILE_CONFIG0_FE_CACHE_MISS_COUNT0x000c
#define VIVS_MC_PROFILE_CONFIG0_FE_RESET 0x000f
+#define VIVS_MC_PROFILE_CONFIG0_FE_CACHE_LK_COUNT 0x0010
+#define VIVS_MC_PROFILE_CONFIG0_FE_STALL_COUNT 0x0011
+#define VIVS_MC_PROFILE_CONFIG0_FE_PROCESS_COUNT 0x0012
#define VIVS_MC_PROFILE_CONFIG0_DE__MASK 0xff00
#define VIVS_MC_PROFILE_CONFIG0_DE__SHIFT 8
#define VIVS_MC_PROFILE_CONFIG0_DE_RESET 0x0f00
@@ -499,11 +505,14 @@ DEALINGS IN THE SOFTWARE.
#define VIVS_MC_PROFILE_CONFIG1_PA_DEPTH_CLIPPED_COUNTER 0x0006
#define VIVS_MC_PROFILE_CONFIG1_PA_TRIVIAL_REJECTED_COUNTER0x0007
#define VIVS_MC_PROFILE_CONFIG1_PA_CULLED_COUNTER 0x0008
[PATCH v2 2/2] drm/etnaviv: print MMU exception cause
From: Christian Gmeiner
The MMU tells us the fault status. While the raw register value is
already printed, it's a bit more user friendly to translate the
fault reasons into human readable format.
Signed-off-by: Christian Gmeiner
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 37018bc55810..f79203b774d9 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1426,6 +1426,15 @@ static void sync_point_worker(struct work_struct *work)
static void dump_mmu_fault(struct etnaviv_gpu *gpu)
{
+ static const char *fault_reasons[] = {
+ "slave not present",
+ "page not present",
+ "write violation",
+ "out of bounds",
+ "read security violation",
+ "write security violation",
+ };
+
u32 status_reg, status;
int i;
@@ -1438,18 +1447,25 @@ static void dump_mmu_fault(struct etnaviv_gpu *gpu)
dev_err_ratelimited(gpu->dev, "MMU fault status 0x%08x\n", status);
for (i = 0; i < 4; i++) {
+ const char *reason = "unknown";
u32 address_reg;
+ u32 mmu_status;
- if (!(status & (VIVS_MMUv2_STATUS_EXCEPTION0__MASK << (i * 4
+ mmu_status = (status >> (i * 4)) &
VIVS_MMUv2_STATUS_EXCEPTION0__MASK;
+ if (!mmu_status)
continue;
+ if ((mmu_status - 1) < ARRAY_SIZE(fault_reasons))
+ reason = fault_reasons[mmu_status - 1];
+
if (gpu->sec_mode == ETNA_SEC_NONE)
address_reg = VIVS_MMUv2_EXCEPTION_ADDR(i);
else
address_reg = VIVS_MMUv2_SEC_EXCEPTION_ADDR;
- dev_err_ratelimited(gpu->dev, "MMU %d fault addr 0x%08x\n", i,
- gpu_read(gpu, address_reg));
+ dev_err_ratelimited(gpu->dev,
+ "MMU %d fault (%s) addr 0x%08x\n",
+ i, reason, gpu_read(gpu, address_reg));
}
}
--
2.30.2
Re: [PATCH v6 1/4] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint
On 01/12/2022 19:34, Kuogee Hsieh wrote: On 11/30/2022 4:07 PM, Dmitry Baryshkov wrote: On 01/12/2022 01:51, Kuogee Hsieh wrote: Move data-lanes property from mdss_dp node to dp_out endpoint. Also add link-frequencies property into dp_out endpoint as well. The last frequency specified at link-frequencies will be the max link rate supported by DP. Changes in v5: -- revert changes at sc7180.dtsi and sc7280.dtsi -- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi Changes in v6: -- add data-lanes and link-frequencies to yaml Signed-off-by: Kuogee Hsieh --- .../devicetree/bindings/display/msm/dp-controller.yaml | 17 + Separate patch. Also you didn't check the get_maintainers output, so required parties were not included into the distribution. Also as you'd check the get_maintainers output, please fix other email addresses too. arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +- arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +- 3 files changed, 27 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 94bc6e1..af70343 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -90,6 +90,20 @@ properties: $ref: /schemas/graph.yaml#/properties/port description: Output endpoint of the controller + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + + properties: + link-frequencies: true + data-lanes: true No. Use $ref for both of them. + + required: + - link-frequencies + - data-lanes No, they are not required. + + additionalProperties: false + deprecation of old data-lanes property? there is no old data-lanes property. There is one: $ grep -n data-lanes Documentation/devicetree/bindings/display/msm/dp-controller.yaml 82: data-lanes: -- With best wishes Dmitry
Re: [PATCH v6 1/4] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint
On 11/30/2022 4:07 PM, Dmitry Baryshkov wrote:
On 01/12/2022 01:51, Kuogee Hsieh wrote:
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi
Changes in v6:
-- add data-lanes and link-frequencies to yaml
Signed-off-by: Kuogee Hsieh
---
.../devicetree/bindings/display/msm/dp-controller.yaml | 17
+
Separate patch. Also you didn't check the get_maintainers output, so
required parties were not included into the distribution.
Also as you'd check the get_maintainers output, please fix other email
addresses too.
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +-
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 94bc6e1..af70343 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -90,6 +90,20 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+
+ properties:
+ link-frequencies: true
+ data-lanes: true
No. Use $ref for both of them.
+
+ required:
+ - link-frequencies
+ - data-lanes
No, they are not required.
+
+ additionalProperties: false
+
deprecation of old data-lanes property?
there is no old data-lanes property.
required:
- compatible
- reg
@@ -158,6 +172,9 @@ examples:
reg = <1>;
endpoint {
remote-endpoint = <>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <16000 27000
+ 54000 81000>;
I guess the number of zeroes is wrong here. This is 160 MHz ... 810
Mhz, rather than 1.6 GHz ... 8.1 GHz
};
};
};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 754d2d6..39f0844 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -812,7 +812,11 @@ hp_i2c: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <16000 27000 54000>;
Same comment here.
};
_adc {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 93e39fc..b7c343d 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -440,7 +440,11 @@ ap_i2c_tpm: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <16000 27000 54000
81000>;
And here.
};
_mdp {
Re: [PATCH v6 1/4] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint
On 11/30/2022 4:21 PM, Dmitry Baryshkov wrote:
On 01/12/2022 02:07, Dmitry Baryshkov wrote:
On 01/12/2022 01:51, Kuogee Hsieh wrote:
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi
Changes in v6:
-- add data-lanes and link-frequencies to yaml
Signed-off-by: Kuogee Hsieh
---
.../devicetree/bindings/display/msm/dp-controller.yaml | 17
+
Separate patch. Also you didn't check the get_maintainers output, so
required parties were not included into the distribution.
Also as you'd check the get_maintainers output, please fix other
email addresses too.
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +-
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 94bc6e1..af70343 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -90,6 +90,20 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+
+ properties:
+ link-frequencies: true
+ data-lanes: true
No. Use $ref for both of them.
+
+ required:
+ - link-frequencies
+ - data-lanes
No, they are not required.
+
+ additionalProperties: false
+
deprecation of old data-lanes property?
required:
- compatible
- reg
@@ -158,6 +172,9 @@ examples:
reg = <1>;
endpoint {
remote-endpoint = <>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <16000 27000
s/1600/1620
+ 54000 81000>;
I guess the number of zeroes is wrong here. This is 160 MHz ... 810
Mhz, rather than 1.6 GHz ... 8.1 GHz
Ok, I was wrong here. The old code definitely defaults to 570
mega-something. Now I'd really like to read your description for the
link-frequencies property, because the
phy_configure_opts_dp::link_rate is clearly specified in Mb/s and it
takes a fixed set of values from 1.62 Gb/s up to 8.1 Gb/s.
I think the drm_dp_bw_code_to_link_rate() function is incorrect by
itself, as it multiplies with 27000 (27 Mbps) rather than 27 (0.27
Gbps) as required by the standard. So first, we should fix the
function, then all the rates would become logical.
no, drm_dp_bw_code_to_link_rate() is correct and should not be changes
since it impact to other dp drivers too.
0.27Gbps/lane is specified at DP spec.
DP use 8b/10b coding rule (10 bits symbol contains 8 bits data).
};
};
};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 754d2d6..39f0844 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -812,7 +812,11 @@ hp_i2c: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <16000 27000 54000>;
Same comment here.
};
_adc {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 93e39fc..b7c343d 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -440,7 +440,11 @@ ap_i2c_tpm: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <16000 27000 54000
81000>;
And here.
};
_mdp {
Re: [PATCH] drm/amdgpu: use sysfs_emit() to instead of scnprintf()
Reviewed-by: Luben Tuikov Regards, Luben On 2022-11-30 21:24, ye.xingc...@zte.com.cn wrote: > From: ye xingchen > > Replace the open-code with sysfs_emit() to simplify the code. > > Signed-off-by: ye xingchen > --- > 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 077404a9c935..ad490c1e2f57 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c > @@ -1267,7 +1267,7 @@ static ssize_t amdgpu_ras_sysfs_features_read(struct > device *dev, > struct amdgpu_ras *con = > container_of(attr, struct amdgpu_ras, features_attr); > > - return scnprintf(buf, PAGE_SIZE, "feature mask: 0x%x\n", con->features); > + return sysfs_emit(buf, "feature mask: 0x%x\n", con->features); > } > > static void amdgpu_ras_sysfs_remove_bad_page_node(struct amdgpu_device *adev)
[PULL] drm-intel-next-fixes
Hi Dave and Daniel, Here goes our next-fixes targeting 6.2-rc1. Please notice that DG2 DMC had a minor bump version in order to fix the remaining issues related to PCI warns at DC state transition. I didn't request the team to provide the fallback to the previous version because we are moving this fix to the 6.2 along with the force_probe removal. But I warned them if any minor bump is needed after that that all the new rules need to be respected. Besides, I have also requested them to make changes to comply with the new rules. Or to remove the minor version from the fw like GuC did or remove the version entirely like HuC did, since the there's no direct ABI involved that needs version. I expect this work to be done for the next platforms. Still about the DG2, the other MEI patches to fix the potential huc loading failure where already picked up by Greg. So we shall have them into 6.2 as well. Meanwhile we are keeping them in our topic/core-for-CI. Other than that, small fixes and couple targeting stable below. drm-intel-next-fixes-2022-12-01: - Multi-cast register fix (Matt) - Fix workarounds on gen2-3 (Tvrtko) - Bigjoiner fix (Ville) - Make Guc default_list a const data (Jani) - Acquire forcewake before uncore read (Umesh) - Selftest fix (Umesh) - HuC related fixes (Daniele) - Fix some incorrect return values (Janusz) - Fix a memory leak in bios related code (Xia) - Fix VBT send packet port selection (Mikko) - DG2's DMC fix bump for Register noclaims and few restore (Gustavo) Thanks, Rodrigo. The following changes since commit 3d335a523b938a445a674be24d1dd5c7a4c86fb6: Merge tag 'drm-intel-next-2022-11-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-11-23 09:15:44 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2022-12-01 for you to fetch changes up to 7d579eff3e55a256fdd71624543747ed4d7fa38b: drm/i915/dmc: Update DG2 DMC version to v2.08 (2022-11-30 09:07:14 -0500) - Multi-cast register fix (Matt) - Fix workarounds on gen2-3 (Tvrtko) - Bigjoiner fix (Ville) - Make Guc default_list a const data (Jani) - Acquire forcewake before uncore read (Umesh) - Selftest fix (Umesh) - HuC related fixes (Daniele) - Fix some incorrect return values (Janusz) - Fix a memory leak in bios related code (Xia) - Fix VBT send packet port selection (Mikko) - DG2's DMC fix bump for Register noclaims and few restore (Gustavo) Daniele Ceraolo Spurio (2): drm/i915/huc: fix leak of debug object in huc load fence on driver unload drm/i915/huc: always init the delayed load fence Gustavo Sousa (1): drm/i915/dmc: Update DG2 DMC version to v2.08 Jani Nikula (1): drm/i915/guc: make default_lists const data Janusz Krzysztofik (2): drm/i915: Fix negative value passed as remaining time drm/i915: Never return 0 if not all requests retired Matt Roper (1): drm/i915/gt: Manage uncore->lock while waiting on MCR register Mikko Kovanen (1): drm/i915/dsi: fix VBT send packet port selection for dual link DSI Tvrtko Ursulin (1): drm/i915: Fix workarounds on Gen2-3 Umesh Nerlige Ramappa (2): i915/uncore: Acquire fw before loop in intel_uncore_read64_2x32 drm/i915/selftest: Bump up sample period for busy stats selftest Ville Syrjälä (1): drm/i915: Remove non-existent pipes from bigjoiner pipe mask Xia Fukun (1): drm/i915/bios: fix a memory leak in generate_lfp_data_ptrs drivers/gpu/drm/i915/display/intel_bios.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 10 +++-- drivers/gpu/drm/i915/display/intel_dmc.c | 4 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 4 +- drivers/gpu/drm/i915/gt/intel_gt.c | 15 --- drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 18 drivers/gpu/drm/i915/gt/intel_gt_mcr.h | 12 +++--- drivers/gpu/drm/i915/gt/intel_gt_requests.c| 2 +- drivers/gpu/drm/i915/gt/intel_workarounds.c| 5 +-- drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_huc.c | 57 ++ drivers/gpu/drm/i915/gt/uc/intel_uc.c | 1 + drivers/gpu/drm/i915/intel_uncore.h| 44 +--- 14 files changed, 113 insertions(+), 65 deletions(-)
Re: [PATCH 2/3] drm/modes: Use strscpy() to copy command-line mode name
On Mon, Nov 28, 2022 at 09:19:37AM +0100, Maxime Ripard wrote:
> The mode name in struct drm_cmdline_mode can hold 32 characters at most,
> which can easily get overrun. Switch to strscpy() to prevent such a
> thing.
>
> Reported-by: coverity-bot
> Addresses-Coverity-ID: 1527354 ("Security best practices violations")
> Fixes: a7ab155397dd ("drm/modes: Switch to named mode descriptors")
> Signed-off-by: Maxime Ripard
Reviewed-by: Kees Cook
--
Kees Cook
Re: [PATCH 0/3] amdgpu/drm: Documentation updates
Applied patches 1 and 3. Patch 2 is not exactly correct, I'll send out an improved version of patch 2. Thanks! Alex On Thu, Dec 1, 2022 at 10:38 AM Peter Maucher wrote: > > Explain difference between gttsize and gartsize > module parameters, and amend related documentation. > Also, amdgpu does support RDNA GPUs. > > > Peter Maucher (3): > drm/amdgpu: improve GART and GTT documentation > drm/amdgpu: add GART and GTT to glossary > drm/amdgpu: mention RDNA support in docu > > Documentation/gpu/amdgpu/amdgpu-glossary.rst | 6 ++ > Documentation/gpu/amdgpu/index.rst | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 ++- > 3 files changed, 13 insertions(+), 6 deletions(-) > > -- > 2.38.1 >
Re: [PATCH v2] drm/amd/display: add FB_DAMAGE_CLIPS support
On 11/18/22 16:51, Hamza Mahfooz wrote:
Currently, userspace doesn't have a way to communicate selective updates
to displays. So, enable support for FB_DAMAGE_CLIPS for DCN ASICs newer
than DCN301, convert DRM damage clips to dc dirty rectangles and fill
them into dirty_rects in fill_dc_dirty_rects().
Signed-off-by: Hamza Mahfooz
Thanks for the patch, it LGTM.
Reviewed-by: Leo Li
It would be good to add an IGT case to cover combinations of MPO &
damage clip commits. Perhaps something that covers the usecase of moving
a MPO video, while desktop UI updates. We'd expect the SU region to
cover both the MPO plane + UI damage clips, or fallback to FFU.
Thanks,
Leo
---
v2: fallback to FFU if we run into too many dirty rectangles, consider
dirty rectangles in non MPO case and always add a dirty rectangle
for the new plane if there are bb changes in the MPO case.
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 130 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 4 +
2 files changed, 88 insertions(+), 46 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 4eb8201a2608..7af94a2c6237 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4842,6 +4842,35 @@ static int fill_dc_plane_attributes(struct amdgpu_device
*adev,
return 0;
}
+static inline void fill_dc_dirty_rect(struct drm_plane *plane,
+ struct rect *dirty_rect, int32_t x,
+ int32_t y, int32_t width, int32_t height,
+ int *i, bool ffu)
+{
+ if (*i > DC_MAX_DIRTY_RECTS)
+ return;
+
+ if (*i == DC_MAX_DIRTY_RECTS)
+ goto out;
+
+ dirty_rect->x = x;
+ dirty_rect->y = y;
+ dirty_rect->width = width;
+ dirty_rect->height = height;
+
+ if (ffu)
+ drm_dbg(plane->dev,
+ "[PLANE:%d] PSR FFU dirty rect size (%d, %d)\n",
+ plane->base.id, width, height);
+ else
+ drm_dbg(plane->dev,
+ "[PLANE:%d] PSR SU dirty rect at (%d, %d) size (%d,
%d)",
+ plane->base.id, x, y, width, height);
+
+out:
+ (*i)++;
+}
+
/**
* fill_dc_dirty_rects() - Fill DC dirty regions for PSR selective updates
*
@@ -4862,10 +4891,6 @@ static int fill_dc_plane_attributes(struct amdgpu_device
*adev,
* addition, certain use cases - such as cursor and multi-plane overlay (MPO)
-
* implicitly provide damage clips without any client support via the plane
* bounds.
- *
- * Today, amdgpu_dm only supports the MPO and cursor usecase.
- *
- * TODO: Also enable for FB_DAMAGE_CLIPS
*/
static void fill_dc_dirty_rects(struct drm_plane *plane,
struct drm_plane_state *old_plane_state,
@@ -4876,12 +4901,11 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
struct dm_crtc_state *dm_crtc_state = to_dm_crtc_state(crtc_state);
struct rect *dirty_rects = flip_addrs->dirty_rects;
uint32_t num_clips;
+ struct drm_mode_rect *clips;
bool bb_changed;
bool fb_changed;
uint32_t i = 0;
- flip_addrs->dirty_rect_count = 0;
-
/*
* Cursor plane has it's own dirty rect update interface. See
* dcn10_dmub_update_cursor_data and dmub_cmd_update_cursor_info_data
@@ -4889,20 +4913,20 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
if (plane->type == DRM_PLANE_TYPE_CURSOR)
return;
- /*
-* Today, we only consider MPO use-case for PSR SU. If MPO not
-* requested, and there is a plane update, do FFU.
-*/
+ num_clips = drm_plane_get_damage_clips_count(new_plane_state);
+ clips = drm_plane_get_damage_clips(new_plane_state);
+
if (!dm_crtc_state->mpo_requested) {
- dirty_rects[0].x = 0;
- dirty_rects[0].y = 0;
- dirty_rects[0].width = dm_crtc_state->base.mode.crtc_hdisplay;
- dirty_rects[0].height = dm_crtc_state->base.mode.crtc_vdisplay;
- flip_addrs->dirty_rect_count = 1;
- DRM_DEBUG_DRIVER("[PLANE:%d] PSR FFU dirty rect size (%d,
%d)\n",
-new_plane_state->plane->base.id,
-dm_crtc_state->base.mode.crtc_hdisplay,
-dm_crtc_state->base.mode.crtc_vdisplay);
+ if (!num_clips || num_clips > DC_MAX_DIRTY_RECTS)
+ goto ffu;
+
+ for (; flip_addrs->dirty_rect_count < num_clips; clips++)
+ fill_dc_dirty_rect(new_plane_state->plane,
+ _rects[i], clips->x1,
+ clips->y1, clips->x2
[PATCH v2 3/3] dt-bindings: display: panel: mipi-dbi-spi: Add io-supply
Add documentation for the new io-supply property, which specifies the regulator for the I/O voltage supply on platforms where the panel panel power and I/O supplies are separate. Signed-off-by: Otto Pflüger --- .../bindings/display/panel/panel-mipi-dbi-spi.yaml| 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml index c2df8d28aaf5..9b701df5e9d2 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml @@ -22,8 +22,9 @@ description: | The standard defines the following interface signals for type C: - Power: - Vdd: Power supply for display module + Called power-supply in this binding. - Vddi: Logic level supply for interface signals -Combined into one in this binding called: power-supply + Called io-supply in this binding. - Interface: - CSx: Chip select - SCL: Serial clock @@ -80,6 +81,11 @@ properties: Controller data/command selection (D/CX) in 4-line SPI mode. If not set, the controller is in 3-line SPI mode. + io-supply: +description: | + Logic level supply for interface signals (Vddi). + No need to set if this is the same as power-supply. + required: - compatible - reg -- 2.30.2
[PATCH v2 2/3] drm/tiny: panel-mipi-dbi: Read I/O supply from DT
To support platforms with a separate I/O voltage supply, set the new io_regulator property along with the regulator property of the DBI device. Read the I/O supply from a new "io-supply" device tree property. Signed-off-by: Otto Pflüger --- drivers/gpu/drm/tiny/panel-mipi-dbi.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/tiny/panel-mipi-dbi.c b/drivers/gpu/drm/tiny/panel-mipi-dbi.c index 955a61d628e7..353356ee0397 100644 --- a/drivers/gpu/drm/tiny/panel-mipi-dbi.c +++ b/drivers/gpu/drm/tiny/panel-mipi-dbi.c @@ -297,6 +297,11 @@ static int panel_mipi_dbi_spi_probe(struct spi_device *spi) return dev_err_probe(dev, PTR_ERR(dbidev->regulator), "Failed to get regulator 'power'\n"); + dbidev->io_regulator = devm_regulator_get(dev, "io"); + if (IS_ERR(dbidev->io_regulator)) + return dev_err_probe(dev, PTR_ERR(dbidev->io_regulator), +"Failed to get regulator 'io'\n"); + dbidev->backlight = devm_of_find_backlight(dev); if (IS_ERR(dbidev->backlight)) return dev_err_probe(dev, PTR_ERR(dbidev->backlight), "Failed to get backlight\n"); -- 2.30.2
[PATCH v2 1/3] drm/mipi-dbi: Support separate I/O regulator
The MIPI DBI specification defines separate vdd (panel power) and
vddi (I/O voltage) supplies. Displays that require different voltages
for the different supplies do exist, so the supplies cannot be
combined into one as they are now. Add a new io_regulator property to
the mipi_dbi_dev struct which can be set by the panel driver along
with the regulator property.
Signed-off-by: Otto Pflüger
---
drivers/gpu/drm/drm_mipi_dbi.c | 14 ++
include/drm/drm_mipi_dbi.h | 7 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index a6ac56580876..047cab93a041 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -427,6 +427,8 @@ void mipi_dbi_pipe_disable(struct drm_simple_display_pipe
*pipe)
if (dbidev->regulator)
regulator_disable(dbidev->regulator);
+ if (dbidev->io_regulator)
+ regulator_disable(dbidev->io_regulator);
}
EXPORT_SYMBOL(mipi_dbi_pipe_disable);
@@ -652,6 +654,16 @@ static int mipi_dbi_poweron_reset_conditional(struct
mipi_dbi_dev *dbidev, bool
}
}
+ if (dbidev->io_regulator) {
+ ret = regulator_enable(dbidev->io_regulator);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "Failed to enable I/O regulator
(%d)\n", ret);
+ if (dbidev->regulator)
+ regulator_disable(dbidev->regulator);
+ return ret;
+ }
+ }
+
if (cond && mipi_dbi_display_is_on(dbi))
return 1;
@@ -661,6 +673,8 @@ static int mipi_dbi_poweron_reset_conditional(struct
mipi_dbi_dev *dbidev, bool
DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
if (dbidev->regulator)
regulator_disable(dbidev->regulator);
+ if (dbidev->io_regulator)
+ regulator_disable(dbidev->io_regulator);
return ret;
}
diff --git a/include/drm/drm_mipi_dbi.h b/include/drm/drm_mipi_dbi.h
index 14eaecb1825c..e4efbd8ffc9d 100644
--- a/include/drm/drm_mipi_dbi.h
+++ b/include/drm/drm_mipi_dbi.h
@@ -122,10 +122,15 @@ struct mipi_dbi_dev {
struct backlight_device *backlight;
/**
-* @regulator: power regulator (optional)
+* @regulator: power regulator (Vdd) (optional)
*/
struct regulator *regulator;
+ /**
+* @io_regulator: I/O power regulator (Vddi) (optional)
+*/
+ struct regulator *io_regulator;
+
/**
* @dbi: MIPI DBI interface
*/
--
2.30.2
[PATCH v2 0/3] drm/tiny: panel-mipi-dbi: Support separate I/O voltage supply
As stated in Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yml, the MIPI DBI specification defines two power supplies, one for powering the panel and one for the I/O voltage. The panel-mipi-dbi driver currently only supports specifying a single "power-supply" in the device tree. Add support for a second power supply defined in a new "io-supply" device tree property to make the driver properly configure the voltage regulators on platforms where separate supplies are used. Changes in v2: - Don't list power-supply in the properties section of panel-mipi-dbi-spi.yaml because it is already in panel-common.yaml Otto Pflüger (3): drm/mipi-dbi: Support separate I/O regulator drm/tiny: panel-mipi-dbi: Read I/O supply from DT dt-bindings: display: panel: mipi-dbi-spi: Add io-supply .../bindings/display/panel/panel-mipi-dbi-spi.yaml | 8 +++- drivers/gpu/drm/drm_mipi_dbi.c | 14 ++ drivers/gpu/drm/tiny/panel-mipi-dbi.c | 5 + include/drm/drm_mipi_dbi.h | 7 ++- 4 files changed, 32 insertions(+), 2 deletions(-) -- 2.30.2
Re: [PATCH v2 01/11] pwm: Make .get_state() callback return an error code
Hi,
On Wed, Nov 30, 2022 at 7:22 AM Uwe Kleine-König
wrote:
>
> .get_state() might fail in some cases. To make it possible that a driver
> signals such a failure change the prototype of .get_state() to return an
> error code.
>
> This patch was created using coccinelle and the following semantic patch:
>
> @p1@
> identifier getstatefunc;
> identifier driver;
> @@
> struct pwm_ops driver = {
> ...,
> .get_state = getstatefunc
> ,...
> };
>
> @p2@
> identifier p1.getstatefunc;
> identifier chip, pwm, state;
> @@
> -void
> +int
> getstatefunc(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state
> *state)
> {
>...
> - return;
> + return 0;
>...
> }
>
> plus the actual change of the prototype in include/linux/pwm.h (plus some
> manual fixing of indentions and empty lines).
>
> So for now all drivers return success unconditionally. They are adapted
> in the following patches to make the changes easier reviewable.
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/gpio/gpio-mvebu.c | 9 ++---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 14 --
> drivers/leds/rgb/leds-qcom-lpg.c | 14 --
> drivers/pwm/pwm-atmel.c | 6 --
> drivers/pwm/pwm-bcm-iproc.c | 8 +---
> drivers/pwm/pwm-crc.c | 10 ++
> drivers/pwm/pwm-cros-ec.c | 8 +---
> drivers/pwm/pwm-dwc.c | 6 --
> drivers/pwm/pwm-hibvt.c | 6 --
> drivers/pwm/pwm-imx-tpm.c | 8 +---
> drivers/pwm/pwm-imx27.c | 8 +---
> drivers/pwm/pwm-intel-lgm.c | 6 --
> drivers/pwm/pwm-iqs620a.c | 6 --
> drivers/pwm/pwm-keembay.c | 6 --
> drivers/pwm/pwm-lpss.c| 6 --
> drivers/pwm/pwm-meson.c | 8 +---
> drivers/pwm/pwm-mtk-disp.c| 12 +++-
> drivers/pwm/pwm-pca9685.c | 8 +---
> drivers/pwm/pwm-raspberrypi-poe.c | 8 +---
> drivers/pwm/pwm-rockchip.c| 12 +++-
> drivers/pwm/pwm-sifive.c | 6 --
> drivers/pwm/pwm-sl28cpld.c| 8 +---
> drivers/pwm/pwm-sprd.c| 8 +---
> drivers/pwm/pwm-stm32-lp.c| 8 +---
> drivers/pwm/pwm-sun4i.c | 12 +++-
> drivers/pwm/pwm-sunplus.c | 6 --
> drivers/pwm/pwm-visconti.c| 6 --
> drivers/pwm/pwm-xilinx.c | 8 +---
> include/linux/pwm.h | 4 ++--
> 29 files changed, 146 insertions(+), 89 deletions(-)
For ti-sn65dsi86.c:
Acked-by: Douglas Anderson
[PATCH 3/3] drm/amdgpu: mention RDNA support in docu
The amdgpu kernel module has supported RDNA for a while, mention that in the module description. Signed-off-by: Peter Maucher --- Documentation/gpu/amdgpu/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gpu/amdgpu/index.rst b/Documentation/gpu/amdgpu/index.rst index a24e1cfa7407..bcc0f5c15f93 100644 --- a/Documentation/gpu/amdgpu/index.rst +++ b/Documentation/gpu/amdgpu/index.rst @@ -3,7 +3,7 @@ == The drm/amdgpu driver supports all AMD Radeon GPUs based on the Graphics Core -Next (GCN) architecture. +Next (GCN) and Radeon DNA (RDNA) architectures. .. toctree:: -- 2.38.1
[PATCH 2/3] drm/amdgpu: add GART and GTT to glossary
GART and GTT are two abbreviations that should be mentioned in the glossary. Signed-off-by: Peter Maucher --- Documentation/gpu/amdgpu/amdgpu-glossary.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst index 326896e9800d..d86bea7926dc 100644 --- a/Documentation/gpu/amdgpu/amdgpu-glossary.rst +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst @@ -30,6 +30,12 @@ we have a dedicated glossary for Display Core at EOP End Of Pipe/Pipeline +GART + Graphics Aperture Table + +GTT + Graphics Translation Table, mostly synonymous to GART + GC Graphics and Compute -- 2.38.1
[PATCH 1/3] drm/amdgpu: improve GART and GTT documentation
Document difference between amdgpu.gartsize and amdgpu.gttsize module parameters, as initially explained by Alex Deucher here: https://lists.freedesktop.org/archives/dri-devel/2022-October/375358.html Signed-off-by: Peter Maucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index bf2d50c8c92a..d647836ba7b8 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -230,17 +230,18 @@ module_param_named(vis_vramlimit, amdgpu_vis_vram_limit, int, 0444); /** * DOC: gartsize (uint) - * Restrict the size of GART in Mib (32, 64, etc.) for testing. The default is -1 (The size depends on asic). + * Restrict the size of GART (for kernel use) in Mib (32, 64, etc.) for testing. + * The default is -1 (The size depends on asic). */ -MODULE_PARM_DESC(gartsize, "Size of GART to setup in megabytes (32, 64, etc., -1=auto)"); +MODULE_PARM_DESC(gartsize, "Size of kernel GART to setup in megabytes (32, 64, etc., -1=auto)"); module_param_named(gartsize, amdgpu_gart_size, uint, 0600); /** * DOC: gttsize (int) - * Restrict the size of GTT domain in MiB for testing. The default is -1 (It's VRAM size if 3GB < VRAM < 3/4 RAM, - * otherwise 3/4 RAM size). + * Restrict the size of GTT domain (for userspace usage) in MiB for testing. + * The default is -1 (It's VRAM size if 3GB < VRAM < 3/4 RAM, otherwise 3/4 RAM size). */ -MODULE_PARM_DESC(gttsize, "Size of the GTT domain in megabytes (-1 = auto)"); +MODULE_PARM_DESC(gttsize, "Size of the GTT userspace domain in megabytes (-1 = auto)"); module_param_named(gttsize, amdgpu_gtt_size, int, 0600); /** -- 2.38.1
[PATCH 0/3] amdgpu/drm: Documentation updates
Explain difference between gttsize and gartsize module parameters, and amend related documentation. Also, amdgpu does support RDNA GPUs. Peter Maucher (3): drm/amdgpu: improve GART and GTT documentation drm/amdgpu: add GART and GTT to glossary drm/amdgpu: mention RDNA support in docu Documentation/gpu/amdgpu/amdgpu-glossary.rst | 6 ++ Documentation/gpu/amdgpu/index.rst | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 ++- 3 files changed, 13 insertions(+), 6 deletions(-) -- 2.38.1
Re: [PATCH v2 03/11] drm/bridge: ti-sn65dsi86: Propagate errors in .get_state() to the caller
Hi, On Wed, Nov 30, 2022 at 7:22 AM Uwe Kleine-König wrote: > > .get_state() can return an error indication. Make use of it to propagate > failing hardware accesses. > > Signed-off-by: Uwe Kleine-König > --- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Acked-by: Douglas Anderson
Re: [PATCH v8 22/22] drm/i915/vm_bind: Support capture of persistent mappings
On Thu, Dec 01, 2022 at 10:49:15AM +, Matthew Auld wrote:
On 29/11/2022 07:26, Niranjana Vishwanathapura wrote:
Support dump capture of persistent mappings upon user request.
Signed-off-by: Brian Welty
Signed-off-by: Niranjana Vishwanathapura
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 11 +++
drivers/gpu/drm/i915/gt/intel_gtt.c | 3 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 5 +
drivers/gpu/drm/i915/i915_gpu_error.c | 19 +++
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 ++
include/uapi/drm/i915_drm.h | 3 ++-
7 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 78e7c0642c5f..50969613daf6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -88,6 +88,11 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma,
bool release_obj)
{
lockdep_assert_held(>vm->vm_bind_lock);
+ spin_lock(>vm->vm_capture_lock);
+ if (!list_empty(>vm_capture_link))
+ list_del_init(>vm_capture_link);
+ spin_unlock(>vm->vm_capture_lock);
+
spin_lock(>vm->vm_rebind_lock);
if (!list_empty(>vm_rebind_link))
list_del_init(>vm_rebind_link);
@@ -357,6 +362,12 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
continue;
}
+ if (va->flags & I915_GEM_VM_BIND_CAPTURE) {
+ spin_lock(>vm_capture_lock);
+ list_add_tail(>vm_capture_link,
>vm_capture_list);
+ spin_unlock(>vm_capture_lock);
+ }
+
list_add_tail(>vm_bind_link, >vm_bound_list);
i915_vm_bind_it_insert(vma, >va);
if (!obj->priv_root)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index ebf6830574a0..bdabe13fc30e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -297,6 +297,9 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
spin_lock_init(>vm_rebind_lock);
spin_lock_init(>userptr_invalidated_lock);
INIT_LIST_HEAD(>userptr_invalidated_list);
+
+ INIT_LIST_HEAD(>vm_capture_list);
+ spin_lock_init(>vm_capture_lock);
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 87e5b6568a00..8e4ddd073348 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -281,6 +281,11 @@ struct i915_address_space {
/** @root_obj: root object for dma-resv sharing by private objects */
struct drm_i915_gem_object *root_obj;
+ /* @vm_capture_list: list of vm captures */
+ struct list_head vm_capture_list;
+ /* @vm_capture_lock: protects vm_capture_list */
+ spinlock_t vm_capture_lock;
+
/* Global GTT */
bool is_ggtt:1;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64..3b2b12a739f7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1460,6 +1460,22 @@ capture_vma(struct intel_engine_capture_vma *next,
return next;
}
+static struct intel_engine_capture_vma *
+capture_user_vm(struct intel_engine_capture_vma *capture,
+ struct i915_address_space *vm, gfp_t gfp)
+{
+ struct i915_vma *vma;
+
+ spin_lock(>vm_capture_lock);
Does it make sense to move this into the eb3 submission stage, like we
do for eb2? IIRC the gfp flags here are quite limiting due to
potentially being in a fence critical section. If we can use
rq->capture_list for eb3, we shouldn't need to change much here?
But that will add latency on submission path as we will have to iterate
over capture_list in each submission. Besides, unlike eb2 case, we can't
just transfer the list to rq->capture_list as we will have to do this
for each submission. It was discussed long time back and decided not to
bother the fast path (submision) scenario with this error capture which
is only required upon gpu hang (slow path).
Also there is the existing CONFIG_DRM_I915_CAPTURE_ERROR. Should we
take that into account?
Ok, will fix.
+ /* vma->resource must be valid here as persistent vmas are bound */
+ list_for_each_entry(vma, >vm_capture_list, vm_capture_link)
+ capture = capture_vma_snapshot(capture, vma->resource,
+ gfp, "user");
+ spin_unlock(>vm_capture_lock);
+
+ return capture;
+}
+
static struct intel_engine_capture_vma *
capture_user(struct intel_engine_capture_vma *capture,
Re: [PATCH v2 1/3] ASoC: hdmi-codec: Add event handler for hdmi TX
On Thu, Dec 01, 2022 at 03:06:04PM +, Jiaxin Yu (俞家鑫) wrote:
> On Tue, 2022-11-29 at 17:22 +, Mark Brown wrote:
> > static const struct snd_kcontrol_new
> > mt8186_mt6366_rt1019_rt5682s_controls[] = {
> > SOC_DAPM_PIN_SWITCH("Speakers"),
> > SOC_DAPM_PIN_SWITCH("Headphone"),
> > SOC_DAPM_PIN_SWITCH("Headset Mic"),
> > SOC_DAPM_PIN_SWITCH("HDMI1"),
> > };
> Which operation should I use to inform bridge driver to control audio
> on or off? I'm curious why I don't see .trigger in the structure
> hdmi_codec_ops compared to the structure snd_soc_dai_ops?
You'd need to add a callback that the user of hdmi-codec passes in which
would be triggered by an event on a DAPM widget added in the audio path
rather than trying to shoehorn this into a PCM operation - a big part of
the problem here is that you're trying to add something that doesn't fit
into a PCM operation.
signature.asc
Description: PGP signature
[PATCH v3 15/20] drm/vc4: crtc: Make encoder lookup helper public
We'll need a function that looks up an encoder by its vc4_encoder_type.
Such a function is already present in the CRTC code, so let's make it
public so that we can reuse it in the unit tests.
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 17 +
drivers/gpu/drm/vc4/vc4_drv.h | 16
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 5f7f50add46e..195d2b61839d 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -486,21 +486,6 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
return 0;
}
-static struct drm_encoder *vc4_crtc_get_encoder_by_type(struct drm_crtc *crtc,
- enum vc4_encoder_type
type)
-{
- struct drm_encoder *encoder;
-
- drm_for_each_encoder(encoder, crtc->dev) {
- struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
-
- if (vc4_encoder->type == type)
- return encoder;
- }
-
- return NULL;
-}
-
int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
{
struct drm_device *drm = crtc->dev;
@@ -536,7 +521,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
pv_data = vc4_crtc_to_vc4_pv_data(vc4_crtc);
encoder_type = pv_data->encoder_types[encoder_sel];
- encoder = vc4_crtc_get_encoder_by_type(crtc, encoder_type);
+ encoder = vc4_find_encoder_by_type(drm, encoder_type);
if (WARN_ON(!encoder))
return 0;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index cd2002fff115..54352db48476 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -495,6 +495,22 @@ to_vc4_encoder(const struct drm_encoder *encoder)
return container_of(encoder, struct vc4_encoder, base);
}
+static inline
+struct drm_encoder *vc4_find_encoder_by_type(struct drm_device *drm,
+enum vc4_encoder_type type)
+{
+ struct drm_encoder *encoder;
+
+ drm_for_each_encoder(encoder, drm) {
+ struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
+
+ if (vc4_encoder->type == type)
+ return encoder;
+ }
+
+ return NULL;
+}
+
struct vc4_crtc_data {
const char *name;
--
b4 0.10.1
[PATCH v3 20/20] Documentation: gpu: vc4: Add KUnit Tests Section
Now that we have VC4-specific tests in place, let's document them properly. Signed-off-by: Maxime Ripard --- Documentation/gpu/vc4.rst | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/gpu/vc4.rst b/Documentation/gpu/vc4.rst index 5df1d98b9544..a2375f1584e6 100644 --- a/Documentation/gpu/vc4.rst +++ b/Documentation/gpu/vc4.rst @@ -54,6 +54,22 @@ VEC (Composite TV out) encoder .. kernel-doc:: drivers/gpu/drm/vc4/vc4_vec.c :doc: VC4 SDTV module +KUnit Tests +=== + +The VC4 Driver uses KUnit to perform driver-specific unit and +integration tests. + +These tests are using a mock driver and can be ran using the +command:: + ./tools/testing/kunit/kunit.py run \ + --kunitconfig=drivers/gpu/drm/vc4/tests/.kunitconfig \ + --cross_compile aarch64-linux-gnu- --arch arm64 + +Parts of the driver that are currently covered by tests are: + * The HVS to PixelValve dynamic FIFO assignment, for the BCM2835-7 + and BCM2711. + Memory Management and 3D Command Submission === -- b4 0.10.1
[PATCH v3 10/20] drm/tests: helpers: Allow for a custom device struct to be allocated
The current helper to allocate a DRM device doesn't allow for any
subclassing by drivers, which is going to be troublesome as we work on
getting some kunit testing on atomic modesetting code.
Let's use a similar pattern to the other allocation helpers by providing
the structure size and offset as arguments.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_client_modeset_test.c | 4 ++-
drivers/gpu/drm/tests/drm_kunit_helpers.c | 40 ++---
drivers/gpu/drm/tests/drm_modes_test.c | 5 ++--
drivers/gpu/drm/tests/drm_probe_helper_test.c | 5 ++--
include/drm/drm_kunit_helpers.h | 32 ++--
5 files changed, 48 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index 053dbc0106d9..416a279b6dae 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -63,7 +63,9 @@ static int drm_client_modeset_test_init(struct kunit *test)
priv->dev = drm_kunit_helper_alloc_device(test);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->dev);
- priv->drm = drm_kunit_helper_alloc_drm_device(test, priv->dev,
DRIVER_MODESET);
+ priv->drm = __drm_kunit_helper_alloc_drm_device(test, priv->dev,
+ sizeof(*priv->drm), 0,
+ DRIVER_MODESET);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
ret = drmm_connector_init(priv->drm, >connector,
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index 9bfd3cb9cde1..b5485ab8fbf9 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -11,10 +11,6 @@
#define KUNIT_DEVICE_NAME "drm-kunit-mock-device"
-struct kunit_dev {
- struct drm_device base;
-};
-
static const struct drm_mode_config_funcs drm_mode_config_funcs = {
};
@@ -85,32 +81,14 @@ void drm_kunit_helper_free_device(struct kunit *test,
struct device *dev)
}
EXPORT_SYMBOL_GPL(drm_kunit_helper_free_device);
-/**
- * drm_kunit_helper_alloc_drm_device - Allocates a mock DRM device for KUnit
tests
- * @test: The test context object
- * @dev: The parent device object
- * @features: Mocked DRM device driver features
- *
- * This function creates a struct _driver and will create a struct
- * _device from @dev and that driver.
- *
- * @dev should be allocated using drm_kunit_helper_alloc_device().
- *
- * The driver is tied to the @test context and will get cleaned at the
- * end of the test. The drm_device is allocated through
- * devm_drm_dev_alloc() and will thus be freed through a device-managed
- * resource.
- *
- * Returns:
- * A pointer to the new drm_device, or an ERR_PTR() otherwise.
- */
struct drm_device *
-drm_kunit_helper_alloc_drm_device(struct kunit *test, struct device *dev,
- u32 features)
+__drm_kunit_helper_alloc_drm_device(struct kunit *test, struct device *dev,
+ size_t size, size_t offset,
+ u32 features)
{
- struct kunit_dev *kdev;
struct drm_device *drm;
struct drm_driver *driver;
+ void *container;
int ret;
driver = kunit_kzalloc(test, sizeof(*driver), GFP_KERNEL);
@@ -118,11 +96,11 @@ drm_kunit_helper_alloc_drm_device(struct kunit *test,
struct device *dev,
return ERR_PTR(-ENOMEM);
driver->driver_features = features;
- kdev = devm_drm_dev_alloc(dev, driver, struct kunit_dev, base);
- if (IS_ERR(kdev))
- return ERR_CAST(kdev);
+ container = __devm_drm_dev_alloc(dev, driver, size, offset);
+ if (IS_ERR(container))
+ return ERR_CAST(container);
- drm = >base;
+ drm = container + offset;
drm->mode_config.funcs = _mode_config_funcs;
ret = drmm_mode_config_init(drm);
@@ -131,7 +109,7 @@ drm_kunit_helper_alloc_drm_device(struct kunit *test,
struct device *dev,
return drm;
}
-EXPORT_SYMBOL_GPL(drm_kunit_helper_alloc_drm_device);
+EXPORT_SYMBOL_GPL(__drm_kunit_helper_alloc_drm_device);
MODULE_AUTHOR("Maxime Ripard ");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/tests/drm_modes_test.c
b/drivers/gpu/drm/tests/drm_modes_test.c
index d1e9f3c0433a..bc4aa2ce78be 100644
--- a/drivers/gpu/drm/tests/drm_modes_test.c
+++ b/drivers/gpu/drm/tests/drm_modes_test.c
@@ -26,8 +26,9 @@ static int drm_test_modes_init(struct kunit *test)
priv->dev = drm_kunit_helper_alloc_device(test);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->dev);
- priv->drm = drm_kunit_helper_alloc_drm_device(test, priv->dev,
- DRIVER_MODESET);
+ priv->drm =
[PATCH v3 19/20] drm/vc4: tests: Add unit test suite for the PV muxing
The HVS to PixelValve muxing code is fairly error prone and has a bunch
of arbitrary constraints due to the hardware setup.
Let's create a test suite that makes sure that the possible combinations
work and the invalid ones don't.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Makefile |3 +-
drivers/gpu/drm/vc4/tests/vc4_mock.h |9 +-
drivers/gpu/drm/vc4/tests/vc4_mock_output.c| 49 +-
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 1039
4 files changed, 1091 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index f974a8c80e2f..c41f89a15a55 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -29,7 +29,8 @@ vc4-$(CONFIG_DRM_VC4_KUNIT_TEST) += \
tests/vc4_mock.o \
tests/vc4_mock_crtc.o \
tests/vc4_mock_output.o \
- tests/vc4_mock_plane.o
+ tests/vc4_mock_plane.o \
+ tests/vc4_test_pv_muxing.o
vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
diff --git a/drivers/gpu/drm/vc4/tests/vc4_mock.h
b/drivers/gpu/drm/vc4/tests/vc4_mock.h
index ace5b2e00f4a..db8e9a141ef8 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_mock.h
+++ b/drivers/gpu/drm/vc4/tests/vc4_mock.h
@@ -53,8 +53,11 @@ struct vc4_dummy_output *vc4_dummy_output(struct kunit *test,
struct vc4_dev *vc4_mock_device(struct kunit *test);
struct vc4_dev *vc5_mock_device(struct kunit *test);
-int vc4_mock_atomic_add_output(struct kunit *test, struct drm_device *drm,
- enum vc4_encoder_type type,
- struct drm_atomic_state *state);
+int vc4_mock_atomic_add_output(struct kunit *test,
+ struct drm_atomic_state *state,
+ enum vc4_encoder_type type);
+int vc4_mock_atomic_del_output(struct kunit *test,
+ struct drm_atomic_state *state,
+ enum vc4_encoder_type type);
#endif // VC4_MOCK_H_
diff --git a/drivers/gpu/drm/vc4/tests/vc4_mock_output.c
b/drivers/gpu/drm/vc4/tests/vc4_mock_output.c
index cb16ab4451f7..8d33be828d9a 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_mock_output.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_mock_output.c
@@ -61,16 +61,17 @@ static const struct drm_display_mode default_mode = {
DRM_SIMPLE_MODE(640, 480, 64, 48)
};
-int vc4_mock_atomic_add_output(struct kunit *test, struct drm_device *drm,
- enum vc4_encoder_type type,
- struct drm_atomic_state *state)
+int vc4_mock_atomic_add_output(struct kunit *test,
+ struct drm_atomic_state *state,
+ enum vc4_encoder_type type)
{
+ struct drm_device *drm = state->dev;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc_state *crtc_state;
struct vc4_dummy_output *output;
struct drm_connector *conn;
- struct drm_connector_state *conn_state;
struct drm_encoder *encoder;
struct drm_crtc *crtc;
- struct drm_crtc_state *crtc_state;
int ret;
encoder = vc4_find_encoder_by_type(drm, type);
@@ -97,3 +98,41 @@ int vc4_mock_atomic_add_output(struct kunit *test, struct
drm_device *drm,
return 0;
}
+
+int vc4_mock_atomic_del_output(struct kunit *test,
+ struct drm_atomic_state *state,
+ enum vc4_encoder_type type)
+{
+ struct drm_device *drm = state->dev;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc_state *crtc_state;
+ struct vc4_dummy_output *output;
+ struct drm_connector *conn;
+ struct drm_encoder *encoder;
+ struct drm_crtc *crtc;
+ int ret;
+
+ encoder = vc4_find_encoder_by_type(drm, type);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, encoder);
+
+ crtc = vc4_find_crtc_for_encoder(test, drm, encoder);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc);
+
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
+
+ crtc_state->active = false;
+
+ ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ output = container_of(encoder, struct vc4_dummy_output, encoder.base);
+ conn = >connector;
+ conn_state = drm_atomic_get_connector_state(state, conn);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+ ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
new file mode 100644
index ..ae0bd0f81698
--- /dev/null
+++ b/drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
@@ -0,0 +1,1039 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
[PATCH v3 18/20] drm/vc4: tests: Fail the current test if we access a register
Accessing a register when running under kunit is a bad idea since our
device is completely mocked.
Fail the current test if we ever access any of our hardware registers.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 13 +++--
drivers/gpu/drm/vc4/vc4_dpi.c | 13 +++--
drivers/gpu/drm/vc4/vc4_drv.h | 29 +
drivers/gpu/drm/vc4/vc4_dsi.c | 9 -
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 4
drivers/gpu/drm/vc4/vc4_txp.c | 13 +++--
drivers/gpu/drm/vc4/vc4_vec.c | 13 +++--
7 files changed, 81 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 7d1a696477ce..a1a3465948c4 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -50,8 +50,17 @@
#define HVS_FIFO_LATENCY_PIX 6
-#define CRTC_WRITE(offset, val) writel(val, vc4_crtc->regs + (offset))
-#define CRTC_READ(offset) readl(vc4_crtc->regs + (offset))
+#define CRTC_WRITE(offset, val)
\
+ do {
\
+ kunit_fail_current_test("Accessing a register in a unit
test!\n"); \
+ writel(val, vc4_crtc->regs + (offset));
\
+ } while (0)
+
+#define CRTC_READ(offset)
\
+ ({
\
+ kunit_fail_current_test("Accessing a register in a unit
test!\n"); \
+ readl(vc4_crtc->regs + (offset));
\
+ })
static const struct debugfs_reg32 crtc_regs[] = {
VC4_REG32(PV_CONTROL),
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index 1f8f44b7b5a5..0edf3c4c98c8 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -103,8 +103,17 @@ to_vc4_dpi(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_dpi, encoder.base);
}
-#define DPI_READ(offset) readl(dpi->regs + (offset))
-#define DPI_WRITE(offset, val) writel(val, dpi->regs + (offset))
+#define DPI_READ(offset)
\
+ ({
\
+ kunit_fail_current_test("Accessing a register in a unit
test!\n"); \
+ readl(dpi->regs + (offset));
\
+ })
+
+#define DPI_WRITE(offset, val)
\
+ do {
\
+ kunit_fail_current_test("Accessing a register in a unit
test!\n"); \
+ writel(val, dpi->regs + (offset));
\
+ } while (0)
static const struct debugfs_reg32 dpi_regs[] = {
VC4_REG32(DPI_C),
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 418f4f308e36..78fda5332cb3 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -19,6 +19,8 @@
#include
#include
+#include
+
#include "uapi/drm/vc4_drm.h"
struct drm_device;
@@ -645,10 +647,29 @@ to_vc4_crtc_state(const struct drm_crtc_state *crtc_state)
return container_of(crtc_state, struct vc4_crtc_state, base);
}
-#define V3D_READ(offset) readl(vc4->v3d->regs + offset)
-#define V3D_WRITE(offset, val) writel(val, vc4->v3d->regs + offset)
-#define HVS_READ(offset) readl(hvs->regs + offset)
-#define HVS_WRITE(offset, val) writel(val, hvs->regs + offset)
+#define V3D_READ(offset)
\
+ ({
\
+ kunit_fail_current_test("Accessing a register in a unit
test!\n"); \
+ readl(vc4->v3d->regs + (offset));
\
+ })
+
+#define V3D_WRITE(offset, val)
\
+ do {
\
+ kunit_fail_current_test("Accessing a register in a unit
test!\n"); \
+ writel(val, vc4->v3d->regs + (offset));
\
+ } while (0)
+
+#define HVS_READ(offset)
\
+ ({
\
+ kunit_fail_current_test("Accessing a register in a unit
test!\n"); \
+ readl(hvs->regs + (offset));
[PATCH v3 11/20] drm/tests: helpers: Allow to pass a custom drm_driver
Some tests will need to provide their own drm_driver instead of relying
on the dumb one in the helpers, so let's create a helper that allows to
do so.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 15 +++--
include/drm/drm_kunit_helpers.h | 51 +--
2 files changed, 54 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index b5485ab8fbf9..e98b4150f556 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -82,20 +82,15 @@ void drm_kunit_helper_free_device(struct kunit *test,
struct device *dev)
EXPORT_SYMBOL_GPL(drm_kunit_helper_free_device);
struct drm_device *
-__drm_kunit_helper_alloc_drm_device(struct kunit *test, struct device *dev,
- size_t size, size_t offset,
- u32 features)
+__drm_kunit_helper_alloc_drm_device_with_driver(struct kunit *test,
+ struct device *dev,
+ size_t size, size_t offset,
+ const struct drm_driver *driver)
{
struct drm_device *drm;
- struct drm_driver *driver;
void *container;
int ret;
- driver = kunit_kzalloc(test, sizeof(*driver), GFP_KERNEL);
- if (!driver)
- return ERR_PTR(-ENOMEM);
-
- driver->driver_features = features;
container = __devm_drm_dev_alloc(dev, driver, size, offset);
if (IS_ERR(container))
return ERR_CAST(container);
@@ -109,7 +104,7 @@ __drm_kunit_helper_alloc_drm_device(struct kunit *test,
struct device *dev,
return drm;
}
-EXPORT_SYMBOL_GPL(__drm_kunit_helper_alloc_drm_device);
+EXPORT_SYMBOL_GPL(__drm_kunit_helper_alloc_drm_device_with_driver);
MODULE_AUTHOR("Maxime Ripard ");
MODULE_LICENSE("GPL");
diff --git a/include/drm/drm_kunit_helpers.h b/include/drm/drm_kunit_helpers.h
index df99fda95e89..ed013fdcc1ff 100644
--- a/include/drm/drm_kunit_helpers.h
+++ b/include/drm/drm_kunit_helpers.h
@@ -3,6 +3,8 @@
#ifndef DRM_KUNIT_HELPERS_H_
#define DRM_KUNIT_HELPERS_H_
+#include
+
struct drm_device;
struct kunit;
@@ -10,9 +12,54 @@ struct device *drm_kunit_helper_alloc_device(struct kunit
*test);
void drm_kunit_helper_free_device(struct kunit *test, struct device *dev);
struct drm_device *
-__drm_kunit_helper_alloc_drm_device(struct kunit *test, struct device *dev,
+__drm_kunit_helper_alloc_drm_device_with_driver(struct kunit *test,
+ struct device *dev,
+ size_t size, size_t offset,
+ const struct drm_driver
*driver);
+
+/**
+ * drm_kunit_helper_alloc_drm_device_with_driver - Allocates a mock DRM device
for KUnit tests
+ * @_test: The test context object
+ * @_dev: The parent device object
+ * @_type: the type of the struct which contains struct _device
+ * @_member: the name of the _device within @_type.
+ * @_drv: Mocked DRM device driver features
+ *
+ * This function creates a struct _device from @_dev and @_drv.
+ *
+ * @_dev should be allocated using drm_kunit_helper_alloc_device().
+ *
+ * The driver is tied to the @_test context and will get cleaned at the
+ * end of the test. The drm_device is allocated through
+ * devm_drm_dev_alloc() and will thus be freed through a device-managed
+ * resource.
+ *
+ * Returns:
+ * A pointer to the new drm_device, or an ERR_PTR() otherwise.
+ */
+#define drm_kunit_helper_alloc_drm_device_with_driver(_test, _dev, _type,
_member, _drv) \
+ ((_type *)__drm_kunit_helper_alloc_drm_device_with_driver(_test, _dev,
\
+ sizeof(_type),
\
+ offsetof(_type,
_member),\
+ _drv))
+
+static inline struct drm_device *
+__drm_kunit_helper_alloc_drm_device(struct kunit *test,
+ struct device *dev,
size_t size, size_t offset,
- u32 features);
+ u32 features)
+{
+ struct drm_driver *driver;
+
+ driver = kunit_kzalloc(test, sizeof(*driver), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_NULL(test, driver);
+
+ driver->driver_features = features;
+
+ return __drm_kunit_helper_alloc_drm_device_with_driver(test, dev,
+ size, offset,
+ driver);
+}
/**
* drm_kunit_helper_alloc_drm_device - Allocates a mock DRM device for KUnit
[PATCH v3 16/20] drm/vc4: hvs: Provide a function to initialize the HVS structure
We'll need to initialize the HVS structure without a backing device to
create a mock we'll use for testing.
Split the structure initialization part into a separate function.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
drivers/gpu/drm/vc4/vc4_hvs.c | 81 +--
2 files changed, 48 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 54352db48476..e0be7a81a24a 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -1009,6 +1009,7 @@ void vc4_irq_reset(struct drm_device *dev);
/* vc4_hvs.c */
extern struct platform_driver vc4_hvs_driver;
+struct vc4_hvs *__vc4_hvs_alloc(struct vc4_dev *vc4, struct platform_device
*pdev);
void vc4_hvs_stop_channel(struct vc4_hvs *hvs, unsigned int output);
int vc4_hvs_get_fifo_from_output(struct vc4_hvs *hvs, unsigned int output);
u8 vc4_hvs_get_fifo_frame_count(struct vc4_hvs *hvs, unsigned int fifo);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index c4453a5ae163..94c29f8547bb 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -768,22 +768,60 @@ int vc4_hvs_debugfs_init(struct drm_minor *minor)
return 0;
}
-static int vc4_hvs_bind(struct device *dev, struct device *master, void *data)
+struct vc4_hvs *__vc4_hvs_alloc(struct vc4_dev *vc4, struct platform_device
*pdev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct drm_device *drm = dev_get_drvdata(master);
- struct vc4_dev *vc4 = to_vc4_dev(drm);
- struct vc4_hvs *hvs = NULL;
- int ret;
- u32 dispctrl;
- u32 reg;
+ struct drm_device *drm = >base;
+ struct vc4_hvs *hvs;
hvs = drmm_kzalloc(drm, sizeof(*hvs), GFP_KERNEL);
if (!hvs)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
+
hvs->vc4 = vc4;
hvs->pdev = pdev;
+ spin_lock_init(>mm_lock);
+
+ /* Set up the HVS display list memory manager. We never
+* overwrite the setup from the bootloader (just 128b out of
+* our 16K), since we don't want to scramble the screen when
+* transitioning from the firmware's boot setup to runtime.
+*/
+ drm_mm_init(>dlist_mm,
+ HVS_BOOTLOADER_DLIST_END,
+ (SCALER_DLIST_SIZE >> 2) - HVS_BOOTLOADER_DLIST_END);
+
+ /* Set up the HVS LBM memory manager. We could have some more
+* complicated data structure that allowed reuse of LBM areas
+* between planes when they don't overlap on the screen, but
+* for now we just allocate globally.
+*/
+ if (!vc4->is_vc5)
+ /* 48k words of 2x12-bit pixels */
+ drm_mm_init(>lbm_mm, 0, 48 * 1024);
+ else
+ /* 60k words of 4x12-bit pixels */
+ drm_mm_init(>lbm_mm, 0, 60 * 1024);
+
+ vc4->hvs = hvs;
+
+ return hvs;
+}
+
+static int vc4_hvs_bind(struct device *dev, struct device *master, void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct drm_device *drm = dev_get_drvdata(master);
+ struct vc4_dev *vc4 = to_vc4_dev(drm);
+ struct vc4_hvs *hvs = NULL;
+ int ret;
+ u32 dispctrl;
+ u32 reg;
+
+ hvs = __vc4_hvs_alloc(vc4, NULL);
+ if (IS_ERR(hvs))
+ return PTR_ERR(hvs);
+
hvs->regs = vc4_ioremap_regs(pdev, 0);
if (IS_ERR(hvs->regs))
return PTR_ERR(hvs->regs);
@@ -835,29 +873,6 @@ static int vc4_hvs_bind(struct device *dev, struct device
*master, void *data)
else
hvs->dlist = hvs->regs + SCALER5_DLIST_START;
- spin_lock_init(>mm_lock);
-
- /* Set up the HVS display list memory manager. We never
-* overwrite the setup from the bootloader (just 128b out of
-* our 16K), since we don't want to scramble the screen when
-* transitioning from the firmware's boot setup to runtime.
-*/
- drm_mm_init(>dlist_mm,
- HVS_BOOTLOADER_DLIST_END,
- (SCALER_DLIST_SIZE >> 2) - HVS_BOOTLOADER_DLIST_END);
-
- /* Set up the HVS LBM memory manager. We could have some more
-* complicated data structure that allowed reuse of LBM areas
-* between planes when they don't overlap on the screen, but
-* for now we just allocate globally.
-*/
- if (!vc4->is_vc5)
- /* 48k words of 2x12-bit pixels */
- drm_mm_init(>lbm_mm, 0, 48 * 1024);
- else
- /* 60k words of 4x12-bit pixels */
- drm_mm_init(>lbm_mm, 0, 60 * 1024);
-
/* Upload filter kernels. We only have the one for now, so we
* keep it around for the lifetime of the driver.
*/
@@ -867,8 +882,6 @@ static int
[PATCH v3 17/20] drm/vc4: tests: Introduce a mocking infrastructure
In order to test the current atomic_check hooks we need to have a DRM
device that has roughly the same capabilities and layout that the actual
hardware. We'll also need a bunch of functions to create arbitrary
atomic states.
Let's create some helpers to create a device that behaves like the real
one, and some helpers to maintain the atomic state we want to check.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Kconfig | 16 +++
drivers/gpu/drm/vc4/Makefile| 6 +
drivers/gpu/drm/vc4/tests/.kunitconfig | 13 ++
drivers/gpu/drm/vc4/tests/vc4_mock.c| 200
drivers/gpu/drm/vc4/tests/vc4_mock.h| 60 +
drivers/gpu/drm/vc4/tests/vc4_mock_crtc.c | 41 ++
drivers/gpu/drm/vc4/tests/vc4_mock_output.c | 99 ++
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 47 +++
drivers/gpu/drm/vc4/vc4_crtc.c | 20 +--
drivers/gpu/drm/vc4/vc4_drv.c | 4 +-
drivers/gpu/drm/vc4/vc4_drv.h | 16 +++
drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
12 files changed, 511 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index 246305d17a52..f423941c028d 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -34,3 +34,19 @@ config DRM_VC4_HDMI_CEC
help
Choose this option if you have a Broadcom VC4 GPU
and want to use CEC.
+
+config DRM_VC4_KUNIT_TEST
+ bool "KUnit tests for VC4" if !KUNIT_ALL_TESTS
+ depends on DRM_VC4 && KUNIT
+ select DRM_KUNIT_TEST_HELPERS
+ default KUNIT_ALL_TESTS
+ help
+ This builds unit tests for the VC4 DRM/KMS driver. This option is
+ not useful for distributions or general kernels, but only for kernel
+ developers working on the VC4 driver.
+
+ For more information on KUnit and unit tests in general,
+ please refer to the KUnit documentation in
+ Documentation/dev-tools/kunit/.
+
+ If in doubt, say "N".
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index d0163e18e9ca..f974a8c80e2f 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -25,6 +25,12 @@ vc4-y := \
vc4_validate.o \
vc4_validate_shaders.o
+vc4-$(CONFIG_DRM_VC4_KUNIT_TEST) += \
+ tests/vc4_mock.o \
+ tests/vc4_mock_crtc.o \
+ tests/vc4_mock_output.o \
+ tests/vc4_mock_plane.o
+
vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
obj-$(CONFIG_DRM_VC4) += vc4.o
diff --git a/drivers/gpu/drm/vc4/tests/.kunitconfig
b/drivers/gpu/drm/vc4/tests/.kunitconfig
new file mode 100644
index ..b503e9036c7f
--- /dev/null
+++ b/drivers/gpu/drm/vc4/tests/.kunitconfig
@@ -0,0 +1,13 @@
+CONFIG_ARCH_BCM=y
+CONFIG_ARCH_BCM2835=y
+CONFIG_BCM2835_MBOX=y
+CONFIG_KUNIT=y
+CONFIG_DRM=y
+CONFIG_DRM_VC4=y
+CONFIG_DRM_VC4_KUNIT_TEST=y
+CONFIG_MAILBOX=y
+CONFIG_RASPBERRYPI_FIRMWARE=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SOUND=y
+CONFIG_COMMON_CLK=y
diff --git a/drivers/gpu/drm/vc4/tests/vc4_mock.c
b/drivers/gpu/drm/vc4/tests/vc4_mock.c
new file mode 100644
index ..a4bed26af32f
--- /dev/null
+++ b/drivers/gpu/drm/vc4/tests/vc4_mock.c
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+
+#include
+
+#include "vc4_mock.h"
+
+struct vc4_mock_output_desc {
+ enum vc4_encoder_type vc4_encoder_type;
+ unsigned intencoder_type;
+ unsigned intconnector_type;
+};
+
+#define VC4_MOCK_OUTPUT_DESC(_vc4_type, _etype, _ctype)
\
+ {
\
+ .vc4_encoder_type = _vc4_type,
\
+ .encoder_type = _etype,
\
+ .connector_type = _ctype,
\
+ }
+
+struct vc4_mock_pipe_desc {
+ const struct vc4_crtc_data *data;
+ const struct vc4_mock_output_desc *outputs;
+ unsigned int noutputs;
+};
+
+#define VC4_MOCK_CRTC_DESC(_data, ...)
\
+ {
\
+ .data = _data,
\
+ .outputs = (struct vc4_mock_output_desc[]) { __VA_ARGS__ },
\
+ .noutputs = sizeof((struct vc4_mock_output_desc[]) {
__VA_ARGS__ }) / \
+sizeof(struct vc4_mock_output_desc),
\
+ }
+
+#define VC4_MOCK_PIXELVALVE_DESC(_data, ...)
\
+ VC4_MOCK_CRTC_DESC(&(_data)->base, __VA_ARGS__)
+
+struct vc4_mock_desc {
+
[PATCH v3 14/20] drm/vc4: crtc: Introduce a lower-level crtc init helper
The current vc4_crtc_init() helper assumes that we will be using
hardware planes and calls vc4_plane_init().
While it's a reasonable assumption, we'll want to mock the plane and
thus provide our own. Let's create a helper that will take the plane as
an argument.
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 70 ++
drivers/gpu/drm/vc4/vc4_drv.h | 6
2 files changed, 57 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 333529ed3a0d..5f7f50add46e 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -1286,31 +1286,38 @@ static void vc4_set_crtc_possible_masks(struct
drm_device *drm,
}
}
-int vc4_crtc_init(struct drm_device *drm, struct platform_device *pdev,
- struct vc4_crtc *vc4_crtc,
- const struct vc4_crtc_data *data,
- const struct drm_crtc_funcs *crtc_funcs,
- const struct drm_crtc_helper_funcs *crtc_helper_funcs,
- bool feeds_txp)
+/**
+ * __vc4_crtc_init - Initializes a CRTC
+ * @drm: DRM Device
+ * @pdev: CRTC Platform Device
+ * @vc4_crtc: CRTC Object to Initialize
+ * @data: Configuration data associated with this CRTC
+ * @primary_plane: Primary plane for CRTC
+ * @crtc_funcs: Callbacks for the new CRTC
+ * @crtc_helper_funcs: Helper Callbacks for the new CRTC
+ * @feeds_txp: Is this CRTC connected to the TXP?
+ *
+ * Initializes our private CRTC structure. This function is mostly
+ * relevant for KUnit testing, all other users should use
+ * vc4_crtc_init() instead.
+ *
+ * Returns:
+ * 0 on success, a negative error code on failure.
+ */
+int __vc4_crtc_init(struct drm_device *drm,
+ struct platform_device *pdev,
+ struct vc4_crtc *vc4_crtc,
+ const struct vc4_crtc_data *data,
+ struct drm_plane *primary_plane,
+ const struct drm_crtc_funcs *crtc_funcs,
+ const struct drm_crtc_helper_funcs *crtc_helper_funcs,
+ bool feeds_txp)
{
struct vc4_dev *vc4 = to_vc4_dev(drm);
struct drm_crtc *crtc = _crtc->base;
- struct drm_plane *primary_plane;
unsigned int i;
int ret;
- /* For now, we create just the primary and the legacy cursor
-* planes. We should be able to stack more planes on easily,
-* but to do that we would need to compute the bandwidth
-* requirement of the plane configuration, and reject ones
-* that will take too much.
-*/
- primary_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_PRIMARY, 0);
- if (IS_ERR(primary_plane)) {
- dev_err(drm->dev, "failed to construct primary plane\n");
- return PTR_ERR(primary_plane);
- }
-
vc4_crtc->data = data;
vc4_crtc->pdev = pdev;
vc4_crtc->feeds_txp = feeds_txp;
@@ -1342,6 +1349,31 @@ int vc4_crtc_init(struct drm_device *drm, struct
platform_device *pdev,
return 0;
}
+int vc4_crtc_init(struct drm_device *drm, struct platform_device *pdev,
+ struct vc4_crtc *vc4_crtc,
+ const struct vc4_crtc_data *data,
+ const struct drm_crtc_funcs *crtc_funcs,
+ const struct drm_crtc_helper_funcs *crtc_helper_funcs,
+ bool feeds_txp)
+{
+ struct drm_plane *primary_plane;
+
+ /* For now, we create just the primary and the legacy cursor
+* planes. We should be able to stack more planes on easily,
+* but to do that we would need to compute the bandwidth
+* requirement of the plane configuration, and reject ones
+* that will take too much.
+*/
+ primary_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_PRIMARY, 0);
+ if (IS_ERR(primary_plane)) {
+ dev_err(drm->dev, "failed to construct primary plane\n");
+ return PTR_ERR(primary_plane);
+ }
+
+ return __vc4_crtc_init(drm, pdev, vc4_crtc, data, primary_plane,
+ crtc_funcs, crtc_helper_funcs, feeds_txp);
+}
+
static int vc4_crtc_bind(struct device *dev, struct device *master, void *data)
{
struct platform_device *pdev = to_platform_device(dev);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 051c2e3b6d43..cd2002fff115 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -888,6 +888,12 @@ int vc4_bo_debugfs_init(struct drm_minor *minor);
/* vc4_crtc.c */
extern struct platform_driver vc4_crtc_driver;
int vc4_crtc_disable_at_boot(struct drm_crtc *crtc);
+int __vc4_crtc_init(struct drm_device *drm, struct platform_device *pdev,
+ struct vc4_crtc *vc4_crtc, const struct vc4_crtc_data *data,
+ struct drm_plane
[PATCH v3 12/20] drm/tests: Add a test for DRM managed actions
DRM-managed actions are supposed to be ran whenever the device is
released. Let's introduce a basic unit test to make sure it happens.
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/Makefile | 1 +
drivers/gpu/drm/tests/drm_managed_test.c | 71
2 files changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index ef14bd481139..aaf357e29c65 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_format_helper_test.o \
drm_format_test.o \
drm_framebuffer_test.o \
+ drm_managed_test.o \
drm_mm_test.o \
drm_modes_test.o \
drm_plane_helper_test.o \
diff --git a/drivers/gpu/drm/tests/drm_managed_test.c
b/drivers/gpu/drm/tests/drm_managed_test.c
new file mode 100644
index ..1652dca11d30
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_managed_test.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+
+#include
+
+#include
+
+/* Ought to be enough for anybody */
+#define TEST_TIMEOUT_MS100
+
+struct managed_test_priv {
+ bool action_done;
+ wait_queue_head_t action_wq;
+};
+
+static void drm_action(struct drm_device *drm, void *ptr)
+{
+ struct managed_test_priv *priv = ptr;
+
+ priv->action_done = true;
+ wake_up_interruptible(>action_wq);
+}
+
+static void drm_test_managed_run_action(struct kunit *test)
+{
+ struct managed_test_priv *priv;
+ struct drm_device *drm;
+ struct device *dev;
+ int ret;
+
+ priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
+ init_waitqueue_head(>action_wq);
+
+ dev = drm_kunit_helper_alloc_device(test);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dev);
+
+ drm = __drm_kunit_helper_alloc_drm_device(test, dev, sizeof(*drm), 0,
DRIVER_MODESET);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, drm);
+
+ ret = drmm_add_action_or_reset(drm, drm_action, priv);
+ KUNIT_EXPECT_EQ(test, ret, 0);
+
+ ret = drm_dev_register(drm, 0);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ drm_dev_unregister(drm);
+ drm_kunit_helper_free_device(test, dev);
+
+ ret = wait_event_interruptible_timeout(priv->action_wq,
priv->action_done,
+
msecs_to_jiffies(TEST_TIMEOUT_MS));
+ KUNIT_EXPECT_GT(test, ret, 0);
+}
+
+static struct kunit_case drm_managed_tests[] = {
+ KUNIT_CASE(drm_test_managed_run_action),
+ {}
+};
+
+static struct kunit_suite drm_managed_test_suite = {
+ .name = "drm-test-managed",
+ .test_cases = drm_managed_tests
+};
+
+kunit_test_suite(drm_managed_test_suite);
+
+MODULE_AUTHOR("Maxime Ripard ");
+MODULE_LICENSE("GPL");
--
b4 0.10.1
[PATCH v3 13/20] drm/vc4: Move HVS state to main header
In order to introduce unit tests for the HVS state computation, we'll
need access to the vc4_hvs_state struct definition and its associated
helpers.
Let's move them in our driver header.
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 23 +++
drivers/gpu/drm/vc4/vc4_kms.c | 25 +++--
2 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 6af615c2eb65..051c2e3b6d43 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -355,6 +355,29 @@ struct vc4_hvs {
bool vc5_hdmi_enable_4096by2160;
};
+#define HVS_NUM_CHANNELS 3
+
+struct vc4_hvs_state {
+ struct drm_private_state base;
+ unsigned long core_clock_rate;
+
+ struct {
+ unsigned in_use: 1;
+ unsigned long fifo_load;
+ struct drm_crtc_commit *pending_commit;
+ } fifo_state[HVS_NUM_CHANNELS];
+};
+
+static inline struct vc4_hvs_state *
+to_vc4_hvs_state(const struct drm_private_state *priv)
+{
+ return container_of(priv, struct vc4_hvs_state, base);
+}
+
+struct vc4_hvs_state *vc4_hvs_get_global_state(struct drm_atomic_state *state);
+struct vc4_hvs_state *vc4_hvs_get_old_global_state(const struct
drm_atomic_state *state);
+struct vc4_hvs_state *vc4_hvs_get_new_global_state(const struct
drm_atomic_state *state);
+
struct vc4_plane {
struct drm_plane base;
};
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 7282545c54a1..53d9f30460cf 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -25,8 +25,6 @@
#include "vc4_drv.h"
#include "vc4_regs.h"
-#define HVS_NUM_CHANNELS 3
-
struct vc4_ctm_state {
struct drm_private_state base;
struct drm_color_ctm *ctm;
@@ -39,23 +37,6 @@ to_vc4_ctm_state(const struct drm_private_state *priv)
return container_of(priv, struct vc4_ctm_state, base);
}
-struct vc4_hvs_state {
- struct drm_private_state base;
- unsigned long core_clock_rate;
-
- struct {
- unsigned in_use: 1;
- unsigned long fifo_load;
- struct drm_crtc_commit *pending_commit;
- } fifo_state[HVS_NUM_CHANNELS];
-};
-
-static struct vc4_hvs_state *
-to_vc4_hvs_state(const struct drm_private_state *priv)
-{
- return container_of(priv, struct vc4_hvs_state, base);
-}
-
struct vc4_load_tracker_state {
struct drm_private_state base;
u64 hvs_load;
@@ -191,7 +172,7 @@ vc4_ctm_commit(struct vc4_dev *vc4, struct drm_atomic_state
*state)
VC4_SET_FIELD(ctm_state->fifo, SCALER_OLEDOFFS_DISPFIFO));
}
-static struct vc4_hvs_state *
+struct vc4_hvs_state *
vc4_hvs_get_new_global_state(const struct drm_atomic_state *state)
{
struct vc4_dev *vc4 = to_vc4_dev(state->dev);
@@ -204,7 +185,7 @@ vc4_hvs_get_new_global_state(const struct drm_atomic_state
*state)
return to_vc4_hvs_state(priv_state);
}
-static struct vc4_hvs_state *
+struct vc4_hvs_state *
vc4_hvs_get_old_global_state(const struct drm_atomic_state *state)
{
struct vc4_dev *vc4 = to_vc4_dev(state->dev);
@@ -217,7 +198,7 @@ vc4_hvs_get_old_global_state(const struct drm_atomic_state
*state)
return to_vc4_hvs_state(priv_state);
}
-static struct vc4_hvs_state *
+struct vc4_hvs_state *
vc4_hvs_get_global_state(struct drm_atomic_state *state)
{
struct vc4_dev *vc4 = to_vc4_dev(state->dev);
--
b4 0.10.1
[PATCH v3 08/20] drm/tests: helpers: Switch to a platform_device
The device managed resources are ran if the device has bus, which is not
the case of a root_device.
Let's use a platform_device instead.
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index 4bf98bd0a8c6..b66ce779511b 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#define KUNIT_DEVICE_NAME "drm-kunit-mock-device"
@@ -32,7 +33,16 @@ static const struct drm_mode_config_funcs
drm_mode_config_funcs = {
*/
struct device *drm_kunit_helper_alloc_device(struct kunit *test)
{
- return root_device_register(KUNIT_DEVICE_NAME);
+ struct platform_device *pdev;
+ int ret;
+
+ pdev = platform_device_alloc(KUNIT_DEVICE_NAME, PLATFORM_DEVID_NONE);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, pdev);
+
+ ret = platform_device_add(pdev);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ return >dev;
}
EXPORT_SYMBOL_GPL(drm_kunit_helper_alloc_device);
@@ -45,7 +55,9 @@ EXPORT_SYMBOL_GPL(drm_kunit_helper_alloc_device);
*/
void drm_kunit_helper_free_device(struct kunit *test, struct device *dev)
{
- root_device_unregister(dev);
+ struct platform_device *pdev = to_platform_device(dev);
+
+ platform_device_unregister(pdev);
}
EXPORT_SYMBOL_GPL(drm_kunit_helper_free_device);
--
b4 0.10.1
[PATCH v3 06/20] drm/tests: helpers: Remove the name parameter
The device name isn't really useful, we can just define it instead of
exposing it in the API.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_client_modeset_test.c | 3 +--
drivers/gpu/drm/tests/drm_kunit_helpers.c | 7 ---
drivers/gpu/drm/tests/drm_modes_test.c | 3 +--
drivers/gpu/drm/tests/drm_probe_helper_test.c | 3 +--
include/drm/drm_kunit_helpers.h | 3 +--
5 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index 6cdf08f582ce..4d475ae6dbb6 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -59,8 +59,7 @@ static int drm_client_modeset_test_init(struct kunit *test)
test->priv = priv;
- priv->drm = drm_kunit_helper_alloc_drm_device(test, DRIVER_MODESET,
-
"drm-client-modeset-test");
+ priv->drm = drm_kunit_helper_alloc_drm_device(test, DRIVER_MODESET);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
ret = drmm_connector_init(priv->drm, >connector,
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index e718073ba6e9..ec33fcbd092d 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -8,6 +8,8 @@
#include
+#define KUNIT_DEVICE_NAME "drm-kunit-mock-device"
+
struct kunit_dev {
struct drm_device base;
};
@@ -39,7 +41,6 @@ static void dev_free(struct kunit_resource *res)
* drm_kunit_helper_alloc_drm_device - Allocates a mock DRM device for KUnit
tests
* @test: The test context object
* @features: Mocked DRM device driver features
- * @name: Name of the struct to allocate
*
* This function allocates a new struct , creates a struct
* _driver and will create a struct _device using both.
@@ -54,7 +55,7 @@ static void dev_free(struct kunit_resource *res)
*/
struct drm_device *
drm_kunit_helper_alloc_drm_device(struct kunit *test,
- u32 features, char *name)
+ u32 features)
{
struct kunit_dev *kdev;
struct drm_device *drm;
@@ -62,7 +63,7 @@ drm_kunit_helper_alloc_drm_device(struct kunit *test,
struct device *dev;
int ret;
- dev = kunit_alloc_resource(test, dev_init, dev_free, GFP_KERNEL, name);
+ dev = kunit_alloc_resource(test, dev_init, dev_free, GFP_KERNEL,
KUNIT_DEVICE_NAME);
if (!dev)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/tests/drm_modes_test.c
b/drivers/gpu/drm/tests/drm_modes_test.c
index 6723089dff9f..35965ad86188 100644
--- a/drivers/gpu/drm/tests/drm_modes_test.c
+++ b/drivers/gpu/drm/tests/drm_modes_test.c
@@ -22,8 +22,7 @@ static int drm_test_modes_init(struct kunit *test)
priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
KUNIT_ASSERT_NOT_NULL(test, priv);
- priv->drm = drm_kunit_helper_alloc_drm_device(test, DRIVER_MODESET,
- "drm-modes-test");
+ priv->drm = drm_kunit_helper_alloc_drm_device(test, DRIVER_MODESET);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
test->priv = priv;
diff --git a/drivers/gpu/drm/tests/drm_probe_helper_test.c
b/drivers/gpu/drm/tests/drm_probe_helper_test.c
index 85236ff4744f..be61a92b79d2 100644
--- a/drivers/gpu/drm/tests/drm_probe_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_probe_helper_test.c
@@ -40,8 +40,7 @@ static int drm_probe_helper_test_init(struct kunit *test)
test->priv = priv;
priv->drm = drm_kunit_helper_alloc_drm_device(test,
- DRIVER_MODESET |
DRIVER_ATOMIC,
- "drm-probe-helper-test");
+ DRIVER_MODESET |
DRIVER_ATOMIC);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
connector = >connector;
diff --git a/include/drm/drm_kunit_helpers.h b/include/drm/drm_kunit_helpers.h
index e9870c7911fe..6c12b1426ba0 100644
--- a/include/drm/drm_kunit_helpers.h
+++ b/include/drm/drm_kunit_helpers.h
@@ -8,7 +8,6 @@ struct kunit;
struct drm_device *
drm_kunit_helper_alloc_drm_device(struct kunit *test,
- u32 features,
- char *name);
+ u32 features);
#endif // DRM_KUNIT_HELPERS_H_
--
b4 0.10.1
[PATCH v3 07/20] drm/tests: helpers: Create the device in another function
We'll need in some tests to control when the device needs to be added
and removed, so let's split the device creation from the DRM device
creation function.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_client_modeset_test.c | 14 ++-
drivers/gpu/drm/tests/drm_kunit_helpers.c | 56 +++--
drivers/gpu/drm/tests/drm_modes_test.c | 15 ++-
drivers/gpu/drm/tests/drm_probe_helper_test.c | 14 ++-
include/drm/drm_kunit_helpers.h | 5 ++-
5 files changed, 77 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index 4d475ae6dbb6..053dbc0106d9 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -15,6 +15,7 @@
struct drm_client_modeset_test_priv {
struct drm_device *drm;
+ struct device *dev;
struct drm_connector connector;
};
@@ -59,7 +60,10 @@ static int drm_client_modeset_test_init(struct kunit *test)
test->priv = priv;
- priv->drm = drm_kunit_helper_alloc_drm_device(test, DRIVER_MODESET);
+ priv->dev = drm_kunit_helper_alloc_device(test);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->dev);
+
+ priv->drm = drm_kunit_helper_alloc_drm_device(test, priv->dev,
DRIVER_MODESET);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
ret = drmm_connector_init(priv->drm, >connector,
@@ -76,6 +80,13 @@ static int drm_client_modeset_test_init(struct kunit *test)
return 0;
}
+static void drm_client_modeset_test_exit(struct kunit *test)
+{
+ struct drm_client_modeset_test_priv *priv = test->priv;
+
+ drm_kunit_helper_free_device(test, priv->dev);
+}
+
static void drm_test_pick_cmdline_res_1920_1080_60(struct kunit *test)
{
struct drm_client_modeset_test_priv *priv = test->priv;
@@ -175,6 +186,7 @@ static struct kunit_case drm_test_pick_cmdline_tests[] = {
static struct kunit_suite drm_test_pick_cmdline_test_suite = {
.name = "drm_test_pick_cmdline",
.init = drm_client_modeset_test_init,
+ .exit = drm_client_modeset_test_exit,
.test_cases = drm_test_pick_cmdline_tests
};
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index ec33fcbd092d..4bf98bd0a8c6 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -17,36 +17,51 @@ struct kunit_dev {
static const struct drm_mode_config_funcs drm_mode_config_funcs = {
};
-static int dev_init(struct kunit_resource *res, void *ptr)
+/**
+ * drm_kunit_helper_alloc_device - Allocate a mock device for a KUnit test
+ * @test: The test context object
+ *
+ * This allocates a fake struct to create a mock for a KUnit
+ * test.
+ *
+ * Callers need to make sure drm_kunit_helper_free_device() on the
+ * device when done.
+ *
+ * Returns:
+ * A pointer to the new device, or an ERR_PTR() otherwise.
+ */
+struct device *drm_kunit_helper_alloc_device(struct kunit *test)
{
- char *name = ptr;
- struct device *dev;
-
- dev = root_device_register(name);
- if (IS_ERR(dev))
- return PTR_ERR(dev);
-
- res->data = dev;
- return 0;
+ return root_device_register(KUNIT_DEVICE_NAME);
}
+EXPORT_SYMBOL_GPL(drm_kunit_helper_alloc_device);
-static void dev_free(struct kunit_resource *res)
+/**
+ * drm_kunit_helper_free_device - Frees a mock device
+ * @test: The test context object
+ * @dev: The device to free
+ *
+ * Frees a device allocated with drm_kunit_helper_alloc_device().
+ */
+void drm_kunit_helper_free_device(struct kunit *test, struct device *dev)
{
- struct device *dev = res->data;
-
root_device_unregister(dev);
}
+EXPORT_SYMBOL_GPL(drm_kunit_helper_free_device);
/**
* drm_kunit_helper_alloc_drm_device - Allocates a mock DRM device for KUnit
tests
* @test: The test context object
+ * @dev: The parent device object
* @features: Mocked DRM device driver features
*
- * This function allocates a new struct , creates a struct
- * _driver and will create a struct _device using both.
+ * This function creates a struct _driver and will create a struct
+ * _device from @dev and that driver.
*
- * The device and driver are tied to the @test context and will get
- * cleaned at the end of the test. The drm_device is allocated through
+ * @dev should be allocated using drm_kunit_helper_alloc_device().
+ *
+ * The driver is tied to the @test context and will get cleaned at the
+ * end of the test. The drm_device is allocated through
* devm_drm_dev_alloc() and will thus be freed through a device-managed
* resource.
*
@@ -54,19 +69,14 @@ static void dev_free(struct kunit_resource *res)
* A pointer to the new drm_device, or an ERR_PTR() otherwise.
*/
struct drm_device *
-drm_kunit_helper_alloc_drm_device(struct kunit
[PATCH v3 09/20] drm/tests: helpers: Make sure the device is bound
The device managed resources are freed when the device is detached, so
it has to be bound in the first place.
Let's create a fake driver that we will bind to our fake device to
benefit from the device managed cleanups in our tests.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index b66ce779511b..9bfd3cb9cde1 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -18,12 +18,32 @@ struct kunit_dev {
static const struct drm_mode_config_funcs drm_mode_config_funcs = {
};
+static int fake_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int fake_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver fake_platform_driver = {
+ .probe = fake_probe,
+ .remove = fake_remove,
+ .driver = {
+ .name = KUNIT_DEVICE_NAME,
+ },
+};
+
/**
* drm_kunit_helper_alloc_device - Allocate a mock device for a KUnit test
* @test: The test context object
*
* This allocates a fake struct to create a mock for a KUnit
- * test.
+ * test. The device will also be bound to a fake driver. It will thus be
+ * able to leverage the usual infrastructure and most notably the
+ * device-managed resources just like a "real" device.
*
* Callers need to make sure drm_kunit_helper_free_device() on the
* device when done.
@@ -36,6 +56,9 @@ struct device *drm_kunit_helper_alloc_device(struct kunit
*test)
struct platform_device *pdev;
int ret;
+ ret = platform_driver_register(_platform_driver);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
pdev = platform_device_alloc(KUNIT_DEVICE_NAME, PLATFORM_DEVID_NONE);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, pdev);
@@ -58,6 +81,7 @@ void drm_kunit_helper_free_device(struct kunit *test, struct
device *dev)
struct platform_device *pdev = to_platform_device(dev);
platform_device_unregister(pdev);
+ platform_driver_unregister(_platform_driver);
}
EXPORT_SYMBOL_GPL(drm_kunit_helper_free_device);
--
b4 0.10.1
[PATCH v3 05/20] drm/tests: helpers: Rename the device init helper
The name doesn't really fit the conventions for the other helpers in
DRM/KMS, so let's rename it to make it obvious that we allocate a new
DRM device.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_client_modeset_test.c | 3 ++-
drivers/gpu/drm/tests/drm_kunit_helpers.c | 8 +---
drivers/gpu/drm/tests/drm_modes_test.c | 3 ++-
drivers/gpu/drm/tests/drm_probe_helper_test.c | 5 +++--
include/drm/drm_kunit_helpers.h | 5 -
5 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index ed2f62e92fea..6cdf08f582ce 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -59,7 +59,8 @@ static int drm_client_modeset_test_init(struct kunit *test)
test->priv = priv;
- priv->drm = drm_kunit_device_init(test, DRIVER_MODESET,
"drm-client-modeset-test");
+ priv->drm = drm_kunit_helper_alloc_drm_device(test, DRIVER_MODESET,
+
"drm-client-modeset-test");
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
ret = drmm_connector_init(priv->drm, >connector,
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index 4fe131141718..e718073ba6e9 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -36,7 +36,7 @@ static void dev_free(struct kunit_resource *res)
}
/**
- * drm_kunit_device_init - Allocates a mock DRM device for KUnit tests
+ * drm_kunit_helper_alloc_drm_device - Allocates a mock DRM device for KUnit
tests
* @test: The test context object
* @features: Mocked DRM device driver features
* @name: Name of the struct to allocate
@@ -52,7 +52,9 @@ static void dev_free(struct kunit_resource *res)
* Returns:
* A pointer to the new drm_device, or an ERR_PTR() otherwise.
*/
-struct drm_device *drm_kunit_device_init(struct kunit *test, u32 features,
char *name)
+struct drm_device *
+drm_kunit_helper_alloc_drm_device(struct kunit *test,
+ u32 features, char *name)
{
struct kunit_dev *kdev;
struct drm_device *drm;
@@ -82,7 +84,7 @@ struct drm_device *drm_kunit_device_init(struct kunit *test,
u32 features, char
return drm;
}
-EXPORT_SYMBOL_GPL(drm_kunit_device_init);
+EXPORT_SYMBOL_GPL(drm_kunit_helper_alloc_drm_device);
MODULE_AUTHOR("Maxime Ripard ");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/tests/drm_modes_test.c
b/drivers/gpu/drm/tests/drm_modes_test.c
index 3953e478c4d0..6723089dff9f 100644
--- a/drivers/gpu/drm/tests/drm_modes_test.c
+++ b/drivers/gpu/drm/tests/drm_modes_test.c
@@ -22,7 +22,8 @@ static int drm_test_modes_init(struct kunit *test)
priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
KUNIT_ASSERT_NOT_NULL(test, priv);
- priv->drm = drm_kunit_device_init(test, DRIVER_MODESET,
"drm-modes-test");
+ priv->drm = drm_kunit_helper_alloc_drm_device(test, DRIVER_MODESET,
+ "drm-modes-test");
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
test->priv = priv;
diff --git a/drivers/gpu/drm/tests/drm_probe_helper_test.c
b/drivers/gpu/drm/tests/drm_probe_helper_test.c
index 1f3941c150ae..85236ff4744f 100644
--- a/drivers/gpu/drm/tests/drm_probe_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_probe_helper_test.c
@@ -39,8 +39,9 @@ static int drm_probe_helper_test_init(struct kunit *test)
KUNIT_ASSERT_NOT_NULL(test, priv);
test->priv = priv;
- priv->drm = drm_kunit_device_init(test, DRIVER_MODESET | DRIVER_ATOMIC,
- "drm-probe-helper-test");
+ priv->drm = drm_kunit_helper_alloc_drm_device(test,
+ DRIVER_MODESET |
DRIVER_ATOMIC,
+ "drm-probe-helper-test");
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
connector = >connector;
diff --git a/include/drm/drm_kunit_helpers.h b/include/drm/drm_kunit_helpers.h
index 20ab6eec4c89..e9870c7911fe 100644
--- a/include/drm/drm_kunit_helpers.h
+++ b/include/drm/drm_kunit_helpers.h
@@ -6,6 +6,9 @@
struct drm_device;
struct kunit;
-struct drm_device *drm_kunit_device_init(struct kunit *test, u32 features,
char *name);
+struct drm_device *
+drm_kunit_helper_alloc_drm_device(struct kunit *test,
+ u32 features,
+ char *name);
#endif // DRM_KUNIT_HELPERS_H_
--
b4 0.10.1
[PATCH v3 04/20] drm/tests: helpers: Switch to EXPORT_SYMBOL_GPL
drm_kunit_device_init() among other things will allocate a device and
wrap around root_device_register. This function is exported with
EXPORT_SYMBOL_GPL, so we can't really change the license.
Fixes: 199557fab925 ("drm/tests: helpers: Add missing export")
Suggested-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index 9ed3cfc2ac03..4fe131141718 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -82,7 +82,7 @@ struct drm_device *drm_kunit_device_init(struct kunit *test,
u32 features, char
return drm;
}
-EXPORT_SYMBOL(drm_kunit_device_init);
+EXPORT_SYMBOL_GPL(drm_kunit_device_init);
MODULE_AUTHOR("Maxime Ripard ");
MODULE_LICENSE("GPL");
--
b4 0.10.1
[PATCH v3 02/20] drm/tests: Introduce a config option for the KUnit helpers
Driver-specific tests will need access to the helpers without pulling every DRM framework test. Let's create an intermediate Kconfig options for the helpers. Suggested-by: Maíra Canal Signed-off-by: Maxime Ripard --- drivers/gpu/drm/Kconfig| 7 +++ drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/tests/Makefile | 4 +++- 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 315cbdf61979..9f019cd053e1 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -63,6 +63,12 @@ config DRM_USE_DYNAMIC_DEBUG bytes per callsite, the .data costs can be substantial, and are therefore configurable. +config DRM_KUNIT_TEST_HELPERS + tristate + depends on DRM && KUNIT + help + KUnit Helpers for KMS drivers. + config DRM_KUNIT_TEST tristate "KUnit tests for DRM" if !KUNIT_ALL_TESTS depends on DRM && KUNIT @@ -73,6 +79,7 @@ config DRM_KUNIT_TEST select DRM_KMS_HELPER select DRM_BUDDY select DRM_EXPORT_FOR_TESTS if m + select DRM_KUNIT_TEST_HELPERS default KUNIT_ALL_TESTS help This builds unit tests for DRM. This option is not useful for diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index f92cd7892711..8d61fbdfdfac 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -125,7 +125,7 @@ obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o # Drivers and the rest # -obj-$(CONFIG_DRM_KUNIT_TEST) += tests/ +obj-y += tests/ obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile index 94fe546d937d..ef14bd481139 100644 --- a/drivers/gpu/drm/tests/Makefile +++ b/drivers/gpu/drm/tests/Makefile @@ -1,5 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_DRM_KUNIT_TEST_HELPERS) += \ + drm_kunit_helpers.o + obj-$(CONFIG_DRM_KUNIT_TEST) += \ drm_buddy_test.o \ drm_cmdline_parser_test.o \ @@ -9,7 +12,6 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \ drm_format_helper_test.o \ drm_format_test.o \ drm_framebuffer_test.o \ - drm_kunit_helpers.o \ drm_mm_test.o \ drm_modes_test.o \ drm_plane_helper_test.o \ -- b4 0.10.1
[PATCH v3 03/20] drm/tests: helpers: Document drm_kunit_device_init()
Commit 44a3928324e9 ("drm/tests: Add Kunit Helpers") introduced the
drm_kunit_device_init() function but didn't document it properly. Add
that documentation.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index 6600a4db3158..9ed3cfc2ac03 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -35,6 +35,23 @@ static void dev_free(struct kunit_resource *res)
root_device_unregister(dev);
}
+/**
+ * drm_kunit_device_init - Allocates a mock DRM device for KUnit tests
+ * @test: The test context object
+ * @features: Mocked DRM device driver features
+ * @name: Name of the struct to allocate
+ *
+ * This function allocates a new struct , creates a struct
+ * _driver and will create a struct _device using both.
+ *
+ * The device and driver are tied to the @test context and will get
+ * cleaned at the end of the test. The drm_device is allocated through
+ * devm_drm_dev_alloc() and will thus be freed through a device-managed
+ * resource.
+ *
+ * Returns:
+ * A pointer to the new drm_device, or an ERR_PTR() otherwise.
+ */
struct drm_device *drm_kunit_device_init(struct kunit *test, u32 features,
char *name)
{
struct kunit_dev *kdev;
--
b4 0.10.1
[PATCH v3 00/20] drm: Introduce Kunit Tests to VC4
Hi, This series introduce Kunit tests to the vc4 KMS driver, but unlike what we have been doing so far in KMS, it actually tests the atomic modesetting code. In order to do so, I've had to improve a fair bit on the Kunit helpers already found in the tree in order to register a full blown and somewhat functional KMS driver. It's of course relying on a mock so that we can test it anywhere. The mocking approach created a number of issues, the main one being that we need to create a decent mock in the first place, see patch 22. The basic idea is that I created some structures to provide a decent approximation of the actual hardware, and that would support both major architectures supported by vc4. This is of course meant to evolve over time and support more tests, but I've focused on testing the HVS FIFO assignment code which is fairly tricky (and the tests have actually revealed one more bug with our current implementation). I used to have a userspace implementation of those tests, where I would copy and paste the kernel code and run the tests on a regular basis. It's was obviously fairly suboptimal, so it seemed like the perfect testbed for that series. It can be run using: ./tools/testing/kunit/kunit.py run \ --kunitconfig=drivers/gpu/drm/vc4/tests/.kunitconfig \ --cross_compile aarch64-linux-gnu- --arch arm64 Let me know what you think, Maxime To: David Airlie To: Daniel Vetter To: Maarten Lankhorst To: Maxime Ripard To: Thomas Zimmermann Cc: Dave Stevenson Cc: Javier Martinez Canillas Cc: Greg Kroah-Hartman Cc: Maíra Canal Cc: Brendan Higgins Cc: David Gow Cc: linux-kselft...@vger.kernel.org Cc: kunit-...@googlegroups.com Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Maxime Ripard --- Changes in v3: - Add a Kconfig option for the KUnit helpers - Switch to EXPORT_SYMBOL_GPL for the helpers - Add some documentation on how to run the tests - Add some documentation for __vc4_crtc_init - Fix KUnit casing - Link to v2: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v2-0-efe5ed518...@cerno.tech Changes in v2: - Added some documentation for public functions - Removed the fake device probe/remove workqueue - Made sure the tests could be compiled as modules - Moved the vc4 tests in the vc4 module - Applied some of the preliminary patches - Rebased on top of current drm-misc-next branch - Fixed checkpatch issues - Introduced BCM2835 (Pi0-3) tests for muxing - Introduced tests to cover past bugs we had - Link to v1: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v1-0-051a0bb60...@cerno.tech --- Maxime Ripard (20): drm/tests: helpers: Move the helper header to include/drm drm/tests: Introduce a config option for the KUnit helpers drm/tests: helpers: Document drm_kunit_device_init() drm/tests: helpers: Switch to EXPORT_SYMBOL_GPL drm/tests: helpers: Rename the device init helper drm/tests: helpers: Remove the name parameter drm/tests: helpers: Create the device in another function drm/tests: helpers: Switch to a platform_device drm/tests: helpers: Make sure the device is bound drm/tests: helpers: Allow for a custom device struct to be allocated drm/tests: helpers: Allow to pass a custom drm_driver drm/tests: Add a test for DRM managed actions drm/vc4: Move HVS state to main header drm/vc4: crtc: Introduce a lower-level crtc init helper drm/vc4: crtc: Make encoder lookup helper public drm/vc4: hvs: Provide a function to initialize the HVS structure drm/vc4: tests: Introduce a mocking infrastructure drm/vc4: tests: Fail the current test if we access a register drm/vc4: tests: Add unit test suite for the PV muxing Documentation: gpu: vc4: Add KUnit Tests Section Documentation/gpu/vc4.rst | 16 + drivers/gpu/drm/Kconfig |7 + drivers/gpu/drm/Makefile|2 +- drivers/gpu/drm/tests/Makefile |5 +- drivers/gpu/drm/tests/drm_client_modeset_test.c | 19 +- drivers/gpu/drm/tests/drm_kunit_helpers.c | 106 ++- drivers/gpu/drm/tests/drm_kunit_helpers.h | 11 - drivers/gpu/drm/tests/drm_managed_test.c| 71 ++ drivers/gpu/drm/tests/drm_modes_test.c | 19 +- drivers/gpu/drm/tests/drm_probe_helper_test.c | 20 +- drivers/gpu/drm/vc4/Kconfig | 16 + drivers/gpu/drm/vc4/Makefile|7 + drivers/gpu/drm/vc4/tests/.kunitconfig | 13 + drivers/gpu/drm/vc4/tests/vc4_mock.c| 200 + drivers/gpu/drm/vc4/tests/vc4_mock.h| 63 ++ drivers/gpu/drm/vc4/tests/vc4_mock_crtc.c | 41 + drivers/gpu/drm/vc4/tests/vc4_mock_output.c | 138 +++ drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 47 + drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c |
[PATCH v3 01/20] drm/tests: helpers: Move the helper header to include/drm
We'll need to use those helpers from drivers too, so let's move it to a
more visible location.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_client_modeset_test.c| 3 +--
drivers/gpu/drm/tests/drm_kunit_helpers.c | 3 +--
drivers/gpu/drm/tests/drm_modes_test.c | 3 +--
drivers/gpu/drm/tests/drm_probe_helper_test.c | 3 +--
{drivers/gpu/drm/tests => include/drm}/drm_kunit_helpers.h | 0
5 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index 52929536a158..ed2f62e92fea 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -8,12 +8,11 @@
#include
#include
#include
+#include
#include
#include
#include
-#include "drm_kunit_helpers.h"
-
struct drm_client_modeset_test_priv {
struct drm_device *drm;
struct drm_connector connector;
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index 8c738384a992..6600a4db3158 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -1,14 +1,13 @@
// SPDX-License-Identifier: GPL-2.0
#include
+#include
#include
#include
#include
-#include "drm_kunit_helpers.h"
-
struct kunit_dev {
struct drm_device base;
};
diff --git a/drivers/gpu/drm/tests/drm_modes_test.c
b/drivers/gpu/drm/tests/drm_modes_test.c
index 9358a885c58b..3953e478c4d0 100644
--- a/drivers/gpu/drm/tests/drm_modes_test.c
+++ b/drivers/gpu/drm/tests/drm_modes_test.c
@@ -4,14 +4,13 @@
*/
#include
+#include
#include
#include
#include
-#include "drm_kunit_helpers.h"
-
struct drm_test_modes_priv {
struct drm_device *drm;
};
diff --git a/drivers/gpu/drm/tests/drm_probe_helper_test.c
b/drivers/gpu/drm/tests/drm_probe_helper_test.c
index 7e938258c742..1f3941c150ae 100644
--- a/drivers/gpu/drm/tests/drm_probe_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_probe_helper_test.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -14,8 +15,6 @@
#include
-#include "drm_kunit_helpers.h"
-
struct drm_probe_helper_test_priv {
struct drm_device *drm;
struct drm_connector connector;
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.h
b/include/drm/drm_kunit_helpers.h
similarity index 100%
rename from drivers/gpu/drm/tests/drm_kunit_helpers.h
rename to include/drm/drm_kunit_helpers.h
--
b4 0.10.1
Re: [PATCH v7 20/20] drm/i915/vm_bind: Async vm_unbind support
On Thu, Dec 01, 2022 at 10:10:14AM +, Matthew Auld wrote:
On 29/11/2022 23:26, Niranjana Vishwanathapura wrote:
On Wed, Nov 23, 2022 at 11:42:58AM +, Matthew Auld wrote:
On 16/11/2022 00:37, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 03:15:03PM -0800, Niranjana
Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 08:33:47AM -0800, Niranjana
Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 04:20:54PM +, Matthew Auld wrote:
On 15/11/2022 16:15, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 11:05:21AM +, Matthew Auld wrote:
On 13/11/2022 07:57, Niranjana Vishwanathapura wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
Signed-off-by: Niranjana Vishwanathapura
This only does it for non-partial vma, right? Or was
that changed somewhere?
No, it applies to any vma (partial or non-partial).
It was so from the beginning.
Doesn't __i915_vma_unbind_async() return an error when
mm.pages != vma->pages? IIRC this was discussed before.
Just trying to think about the consequences of this
change.
I am not seeing any such restriction. Let me probe and check if there
is any such restriction anywhere in the call chain.
I checked and I am not seeing any restriction anywher in the
call chain.
Note that just like binding case, unbinding is also synchronous unless
there is a pending activity, in which case, it will be asynchronous.
In __i915_vma_unbind_async() there is:
if (i915_vma_is_pinned(vma) ||
>obj->mm.rsgt->table != vma->resource->bi.pages)
return ERR_PTR(-EAGAIN);
AFAICT we then also don't get any pipelined moves with such an
object, if there is such a binding present.
I had to remove this check as otherwise for VM_BIND (persistent) mappings,
it will alwasy be true and we will always endup with -EAGAIN.
Persistent mappings, as they support partial binding, can't have an sg
table which is just a pointer to object's sg table.
Ok, maybe make that a seperate patch, since it seems to change the
behaviour for more than just persisent mappings, AFAICT.
Ok, will do.
Niranjana
Niranjana
Niranjana
Niranjana
Niranjana
Niranjana
Reviewed-by: Matthew Auld
---
.../drm/i915/gem/i915_gem_vm_bind_object.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 51
+--
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 6 deletions(-)
diff --git
a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index d87d1210365b..36651b447966 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int
i915_gem_vm_unbind_vma(struct i915_address_space
*vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c
b/drivers/gpu/drm/i915/i915_vma.c
index 7cf77c67d755..483d25f2425c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence
*__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const
struct i915_vma *vma)
{
/*
@@ -1713,7 +1715,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(>node))
return;
@@ -1727,7 +1729,21 @@ static void
force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, >flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(>node));
}
@@ -1787,7 +1803,7 @@ void
i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(>vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
list_del_init(>vm_link);
release_references(vma, vma->vm->gt, false);
}
@@ -1798,7 +1814,34 @@ void
Re: [PATCH v2 1/3] ASoC: hdmi-codec: Add event handler for hdmi TX
Re: [Intel-gfx] [PATCH v5 3/5] drm/i915: Introduce guard pages to i915_vma
On 01/12/2022 14:44, Andi Shyti wrote: From: Chris Wilson Introduce the concept of padding the i915_vma with guard pages before and after. The major consequence is that all ordinary uses of i915_vma must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size directly, as the drm_mm_node will include the guard pages that surround our object. The biggest connundrum is how exactly to mix requesting a fixed address with guard pages, particularly through the existing uABI. The user does not know about guard pages, so such must be transparent to the user, and so the execobj.offset must be that of the object itself excluding the guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages. The caveat is that some placements will be impossible with guard pages, as wrap arounds need to be avoided, and the vma itself will require a larger node. We must not report EINVAL but ENOSPC as these are unavailable locations within the GTT rather than conflicting user requirements. In the next patch, we start using guard pages for scanout objects. While these are limited to GGTT vma, on a few platforms these vma (or at least an alias of the vma) is shared with userspace, so we may leak the existence of such guards if we are not careful to ensure that the execobj.offset is transparent and excludes the guards. (On such platforms like ivb, without full-ppgtt, userspace has to use relocations so the presence of more untouchable regions within its GTT such be of no further issue.) Signed-off-by: Chris Wilson Signed-off-by: Tejas Upadhyay Signed-off-by: Tvrtko Ursulin Signed-off-by: Andi Shyti --- Hi, this the v5 changelog, the overall changelog is in the v4 cover letter: v4 -> v5: - remove again the GEM_BUG_ON() - fix an oversight where the rounding was called without assigning the value to the guard. Thanks Tvrtko for the reviews. I think that was the last open I had so LGTM now. Thanks for the respins! Reviewed-by: Tvrtko Ursulin Regards, Tvrtko Thanks, Andi drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 +--- drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- drivers/gpu/drm/i915/i915_vma.c | 41 drivers/gpu/drm/i915/i915_vma.h | 5 +-- drivers/gpu/drm/i915/i915_vma_resource.c | 4 +-- drivers/gpu/drm/i915/i915_vma_resource.h | 7 +++- drivers/gpu/drm/i915/i915_vma_types.h| 1 + 7 files changed, 58 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 7644738b9cdbe..784d4a8c43ba9 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -296,8 +296,11 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm, */ gte = (gen8_pte_t __iomem *)ggtt->gsm; - gte += vma_res->start / I915_GTT_PAGE_SIZE; - end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE; + gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE; + end = gte + vma_res->guard / I915_GTT_PAGE_SIZE; + while (gte < end) + gen8_set_pte(gte++, vm->scratch[0]->encode); + end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE; for_each_sgt_daddr(addr, iter, vma_res->bi.pages) gen8_set_pte(gte++, pte_encode | addr); @@ -347,9 +350,12 @@ static void gen6_ggtt_insert_entries(struct i915_address_space *vm, dma_addr_t addr; gte = (gen6_pte_t __iomem *)ggtt->gsm; - gte += vma_res->start / I915_GTT_PAGE_SIZE; - end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE; + gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE; + end = gte + vma_res->guard / I915_GTT_PAGE_SIZE; + while (gte < end) + iowrite32(vm->scratch[0]->encode, gte++); + end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE; for_each_sgt_daddr(addr, iter, vma_res->bi.pages) iowrite32(vm->pte_encode(addr, level, flags), gte++); GEM_BUG_ON(gte > end); diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index 8c2f57eb5ddaa..2434197830523 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -44,7 +44,8 @@ int i915_gem_gtt_insert(struct i915_address_space *vm, #define PIN_HIGH BIT_ULL(5) #define PIN_OFFSET_BIAS BIT_ULL(6) #define PIN_OFFSET_FIXED BIT_ULL(7) -#define PIN_VALIDATE BIT_ULL(8) /* validate placement only, no need to call unpin() */ +#define PIN_OFFSET_GUARD BIT_ULL(8) +#define PIN_VALIDATE BIT_ULL(9) /* validate placement only, no need to call unpin() */ #define PIN_GLOBAL BIT_ULL(10) /* I915_VMA_GLOBAL_BIND */ #define PIN_USER BIT_ULL(11) /* I915_VMA_LOCAL_BIND */ diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index fefee5fef38d3..cda90c7818af3 100644 ---
