linux-next: build warning after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
this warning:
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter
or member 'ww' not described in 'i915_gem_shrink'
Introduced by commit
cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.")
--
Cheers,
Stephen Rothwell
pgpvlIoVPI_Br.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build warnings after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
these warnings:
drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter
'trampoline' description in 'intel_engine_cmd_parser'
drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
member 'jump_whitelist' not described in 'intel_engine_cmd_parser'
drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
member 'shadow_map' not described in 'intel_engine_cmd_parser'
drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
member 'batch_map' not described in 'intel_engine_cmd_parser'
drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter
'trampoline' description in 'intel_engine_cmd_parser'
Introduced by commit
0edbb9ba1bfe ("drm/i915: Move cmd parser pinning to execbuffer")
--
Cheers,
Stephen Rothwell
pgpSVst99BhQQ.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/drm_internal.h: Remove repeated struct declaration
struct drm_gem_object is declared twice. One is declared at 40th line. The blew one is not needed. Remove the duplicate. Signed-off-by: Wan Jiabing --- drivers/gpu/drm/drm_internal.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index fad2249ee67b..1265de2b9d90 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -170,7 +170,6 @@ void drm_sysfs_connector_remove(struct drm_connector *connector); void drm_sysfs_lease_event(struct drm_device *dev); /* drm_gem.c */ -struct drm_gem_object; int drm_gem_init(struct drm_device *dev); int drm_gem_handle_create_tail(struct drm_file *file_priv, struct drm_gem_object *obj, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/5] phy: Add LVDS configuration options
Hi Kishon,
First of all, thanks for your review.
On Wed, 2021-03-31 at 19:02 +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On 25/03/21 2:30 pm, Liu Ying wrote:
> > This patch allows LVDS PHYs to be configured through
> > the generic functions and through a custom structure
> > added to the generic union.
> >
> > The parameters added here are based on common LVDS PHY
> > implementation practices. The set of parameters
> > should cover all potential users.
> >
> > Cc: Kishon Vijay Abraham I
> > Cc: Vinod Koul
> > Cc: NXP Linux Team
> > Signed-off-by: Liu Ying
> > ---
> > v4->v5:
> > * Align kernel-doc style to include/linux/phy/phy.h. (Vinod)
> > * Trivial tweaks.
> > * Drop Robert's R-b tag.
> >
> > v3->v4:
> > * Add Robert's R-b tag.
> >
> > v2->v3:
> > * No change.
> >
> > v1->v2:
> > * No change.
> >
> > include/linux/phy/phy-lvds.h | 32
> > include/linux/phy/phy.h | 4
> > 2 files changed, 36 insertions(+)
> > create mode 100644 include/linux/phy/phy-lvds.h
> >
> > diff --git a/include/linux/phy/phy-lvds.h b/include/linux/phy/phy-lvds.h
> > new file mode 100644
> > index ..7a2f474
> > --- /dev/null
> > +++ b/include/linux/phy/phy-lvds.h
> > @@ -0,0 +1,32 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright 2020 NXP
> > + */
> > +
> > +#ifndef __PHY_LVDS_H_
> > +#define __PHY_LVDS_H_
> > +
> > +/**
> > + * struct phy_configure_opts_lvds - LVDS configuration set
> > + * @bits_per_lane_and_dclk_cycle: Number of bits per data lane and
> > + * differential clock cycle.
>
> phy_set_bus_width() instead?
This member aims to configure the number of bits transmitted during a
period of time(a clock cycle). It doesn't sound like a concept of 'bus
width'?
> > + * @differential_clk_rate: Clock rate, in Hertz, of the LVDS
> > + * differential clock.
>
> Please use clk API's to get rate.
I like your idea. But, this rate is likely runtime-configurable, e.g.,
a LVDS to HDMI chip is connected. It seems that there is no appropriate
driver to set the rate by calling clk_set_rate() then?
> > + * @lanes: Number of active, consecutive,
> > + * data lanes, starting from lane 0,
> > + * used for the transmissions.
> > + * @is_slave: Boolean, true if the phy is a
> > slave
> > + * which works together with a master
> > + * phy to support dual link transmission,
> > + * otherwise a regular phy or a master phy.
>
> For parameters that are known at design time, it doesn't have to be
> passed from consumer driver. So all these parameters do they really have
> to be passed at runtime?
Yes for all, perhaps. Details below:
1) bits_per_lane_and_dclk_cycle
i.MX8qxp LVDS phy can only do 7, while i.MX8qm LVDS phy(a different IP)
can do either 7 or 10(configurable by setting a phy register).
2) differential_clk_rate
It's likely runtime-configurable, as I mentioned above.
3) lanes
The higher color depth is, the more lanes are used:
RGB666 - 3 lanes
RGB888 - 4 lanes
RGB101010 - 5 lanes
That means a phy with 5 lanes(like i.MX8qm LVDS phy) support up to the
3 types of RGB pixels.
Though the i.MX LVDS phys don't have any register to configure the
lanes to be used, it would be good to define it for phy_validate() or
other potential phys?
4) is_slave
Any i.MX8qxp LVDS phy instance can act as a regular phy or a master phy
or a slave phy. Changing mode at runtime is probably unneeded. But,
it's difficult for the phy driver to get the mode from device tree(see
drm_of_lvds_get_port_pixels_type()), I think. Export an i.MX8qxp LVDS
phy specific function to set this instead?
Regards,
Liu Ying
>
> Thanks
> Kishon
> > + *
> > + * This structure is used to represent the configuration state of a LVDS
> > phy.
> > + */
> > +struct phy_configure_opts_lvds {
> > + unsigned intbits_per_lane_and_dclk_cycle;
> > + unsigned long differential_clk_rate;
> > + unsigned intlanes;
> > + boolis_slave;
> > +};
> > +
> > +#endif /* __PHY_LVDS_H_ */
> > diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> > index e435bdb..d450b44 100644
> > --- a/include/linux/phy/phy.h
> > +++ b/include/linux/phy/phy.h
> > @@ -17,6 +17,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> >
> > struct phy;
> > @@ -51,10 +52,13 @@ enum phy_mode {
> > * the MIPI_DPHY phy mode.
> > * @dp:Configuration set applicable for phys supporting
> > * the DisplayPort protocol.
> > + * @lvds: Configuration set applicable for phys supporting
> > + * the LVDS phy mode.
> > */
> > union phy_configure_opts {
> > struct phy_configure_opts_mipi_dphy mipi_dphy;
> > struct phy_configure_opts_dp
Re: [RESEND PATCH v4 1/2] dt-bindings: drm/bridge: anx7625: Add power supplies
Hey Hsin-Yi,
Thanks for the reminder, just merged the series.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=2f240cdb23e9cde551d99c77f4e60062188d8d81
On Thu, 1 Apr 2021 at 07:32, Hsin-Yi Wang wrote:
>
> anx7625 requires 3 power supply regulators.
>
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Rob Herring
> Reviewed-by: Robert Foss
> ---
> v3->v4: rebase to drm-misc/for-linux-next
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> index c789784efe306..ab48ab2f4240d 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> @@ -34,6 +34,15 @@ properties:
> description: used for reset chip control, RESET_N pin B7.
> maxItems: 1
>
> + vdd10-supply:
> +description: Regulator that provides the supply 1.0V power.
> +
> + vdd18-supply:
> +description: Regulator that provides the supply 1.8V power.
> +
> + vdd33-supply:
> +description: Regulator that provides the supply 3.3V power.
> +
>ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> @@ -55,6 +64,9 @@ properties:
> required:
>- compatible
>- reg
> + - vdd10-supply
> + - vdd18-supply
> + - vdd33-supply
>- ports
>
> additionalProperties: false
> @@ -72,6 +84,9 @@ examples:
> reg = <0x58>;
> enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> +vdd10-supply = <&pp1000_mipibrdg>;
> +vdd18-supply = <&pp1800_mipibrdg>;
> +vdd33-supply = <&pp3300_mipibrdg>;
>
> ports {
> #address-cells = <1>;
> --
> 2.31.0.291.g576ba9dcdaf-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: remove unused code
Fix the following whitescan warning:
drivers/gpu/drm/nouveau/nouveau_bo.c:1287:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index f2720a0..b661d0d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1284,14 +1284,12 @@ vm_fault_t nouveau_ttm_fault_reserve_notify(struct
ttm_buffer_object *bo)
struct ttm_tt *ttm)
{
struct nouveau_drm *drm;
- struct device *dev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
if (slave)
return;
drm = nouveau_bdev(bdev);
- dev = drm->dev->dev;
return ttm_pool_free(&drm->ttm.bdev.pool, ttm);
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave & Daniel - The final drm-intel-next feature pull for v5.13. Or, truthfully, a pull request of refactoring both to clean up and prepare for future. Joonas will still send a drm-intel-gt-next pull request, probably next week due to easter holidays. We'll do backmerges to sync up after everything's in drm-next. BR, Jani. drm-intel-next-2021-04-01: Features: - Add support for FBs requiring a power-of-two stride padding (Imre) Refactoring: - Disassociate display version from gen (Matt) - Refactor legacy DP and HDMI code to separate files (Ville) - Refactor FB plane code to a separate file (Imre) - Refactor VBT child device info parsing and usage (Jani) - Refactor KBL/TGL/ADL-S display and gt stepping schemes (Jani) Fixes: - DP Link-Training Tunable PHY Repeaters (LTTPR) fixes (Imre) - HDCP fixes (Anshuman) - DP 2.0 HDMI 2.1 PCON Fixed Rate Link (FRL) fixes (Ankit) - Set HDA link parameters in driver (Kai) - Fix enabled_planes bitmask (Ville) - Fix transposed arguments to skl_plane_wm_level() (Ville) - Stop adding planes to the commit needlessly (Ville) BR, Jani. The following changes since commit 2b25fb31a38d4fe8e745754036052ef8b16fe712: Merge tag 'gvt-next-2021-03-16' of https://github.com/intel/gvt-linux into drm-intel-next (2021-03-16 13:42:33 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-04-01 for you to fetch changes up to 81f1f8f1e1489c0bf051d5241ec10da07869b911: drm/i915: Fix docbook header for __intel_runtime_pm_get_if_active() (2021-03-31 16:57:33 +0300) Features: - Add support for FBs requiring a power-of-two stride padding (Imre) Refactoring: - Disassociate display version from gen (Matt) - Refactor legacy DP and HDMI code to separate files (Ville) - Refactor FB plane code to a separate file (Imre) - Refactor VBT child device info parsing and usage (Jani) - Refactor KBL/TGL/ADL-S display and gt stepping schemes (Jani) Fixes: - DP Link-Training Tunable PHY Repeaters (LTTPR) fixes (Imre) - HDCP fixes (Anshuman) - DP 2.0 HDMI 2.1 PCON Fixed Rate Link (FRL) fixes (Ankit) - Set HDA link parameters in driver (Kai) - Fix enabled_planes bitmask (Ville) - Fix transposed arguments to skl_plane_wm_level() (Ville) - Stop adding planes to the commit needlessly (Ville) Ankit Nautiyal (3): drm/i915/display: Remove FRL related code from disable DP sequence for older platforms drm/dp_helper: Define options for FRL training for HDMI2.1 PCON drm/i915/display: Configure HDMI2.1 Pcon for FRL only if Src-Ctl mode is available Anshuman Gupta (6): drm/i915/hdcp: mst streams type1 capability check drm/i915/hdcp: HDCP2.2 MST Link failure recovery drm/i915/hdcp: link hdcp2 recovery on link enc stopped drm/i915/hdcp: return correct error code drm/i915/hdcp: Add DP HDCP2.2 timeout to read entire msg drm/hdcp: DP HDCP2.2 errata LC_Send_L_Prime=16 Bhaskar Chowdhury (1): drm/i915/display: Fix a typo Imre Deak (29): drm/i915/ilk-glk: Fix link training on links with LTTPRs drm/i915: Disable LTTPR support when the DPCD rev < 1.4 drm/i915: Disable LTTPR support when the LTTPR rev < 1.4 drm/i915: Fix the GT fence revocation runtime PM logic drm/i915: Fix rotation setup during plane HW readout drm/i915/selftest: Fix error handling in igt_vma_remapped_gtt() drm/i915/selftest: Fix debug message in igt_vma_remapped_gtt() drm/i915: Make sure i915_ggtt_view is inited when creating an FB drm/i915/selftest: Make sure to init i915_ggtt_view in igt_vma_rotate_remap() drm/i915/intel_fb: Pull FB plane functions from intel_display_types.h drm/i915/intel_fb: Pull FB plane functions from skl_universal_plane.c drm/i915/intel_fb: Pull is_surface_linear() from intel_display.c/skl_universal_plane.c drm/i915/intel_fb: Pull FB plane functions from intel_sprite.c drm/i915/intel_fb: Pull FB plane functions from intel_display.c drm/i915/intel_fb: Unexport intel_fb_check_stride() drm/i915/intel_fb: s/dev_priv/i915/ drm/i915/intel_fb: Factor out convert_plane_offset_to_xy() drm/i915/intel_fb: Factor out calc_plane_aligned_offset() drm/i915/intel_fb: Factor out calc_plane_normal_size() drm/i915: Unify the FB and plane state view information into one struct drm/i915: Store the normal view FB pitch in FB's intel_fb_view drm/i915: Simplify copying the FB view state to the plane state drm/i915/intel_fb: Factor out calc_plane_remap_info() drm/i915: Shrink the size of intel_remapped_plane_info struct drm/i915/selftest: Unify use of intel_remapped_plane_info in igt_vma_rotate_remap() drm/i915: s/stride/src_stride/ in the intel_remapped_plane_info struct drm/i915: Add support for FBs requiring a POT stride alignm
Re: [PATCH v7 07/14] dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module binding
On Wed, 2021-03-31 at 08:40 -0500, Rob Herring wrote: > On Wed, 31 Mar 2021 14:33:18 +0800, Liu Ying wrote: > > This patch adds bindings for i.MX8qm/qxp Control and Status Registers > > module. > > > > Reviewed-by: Rob Herring > > Signed-off-by: Liu Ying > > --- > > v6->v7: > > * Add Rob's R-b tag. > > > > v5->v6: > > * Drop 'select' schema. (Rob) > > > > v4->v5: > > * Newly introduced in v5. (Rob) > > > > .../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml | 192 > > + > > 1 file changed, 192 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml > > > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: > /example-0/syscon@56221000/pxl2dpi: failed to match any schema with > compatible: ['fsl,imx8qxp-pxl2dpi'] > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: > /example-0/syscon@56221000/ldb: failed to match any schema with compatible: > ['fsl,imx8qxp-ldb'] > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: > /example-0/phy@56228300: failed to match any schema with compatible: > ['fsl,imx8qxp-mipi-dphy'] > Sorry for the errors. But, my patch passes 'make dt_binding_check' locally upon v5.12-rc1-dontuse at least. My yamllint and dt-schema are up to date. Does your bot _additionally_ check all compatibles in example? I guess I missed something? Regards, Liu Ying > See https://patchwork.ozlabs.org/patch/1460356 > > This check can fail if there are any dependencies. The base for a patch > series is generally the most recent rc1. > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Check actual RC6 status
On Wed, Mar 31, 2021 at 11:18:50AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> RC6 support cannot be simply established by looking at the static device
> HAS_RC6() flag. There are cases which disable RC6 at driver load time so
> use the status of those check when deciding whether to enumerate the rc6
> counter.
>
> Signed-off-by: Tvrtko Ursulin
> Reported-by: Eero T Tamminen
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 41651ac255fa..a75cd1db320b 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -476,6 +476,8 @@ engine_event_status(struct intel_engine_cs *engine,
> static int
> config_status(struct drm_i915_private *i915, u64 config)
> {
> + struct intel_gt *gt = &i915->gt;
> +
> switch (config) {
> case I915_PMU_ACTUAL_FREQUENCY:
> if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> @@ -489,7 +491,7 @@ config_status(struct drm_i915_private *i915, u64 config)
> case I915_PMU_INTERRUPTS:
> break;
> case I915_PMU_RC6_RESIDENCY:
> - if (!HAS_RC6(i915))
> + if (!gt->rc6.supported)
Is this really going to remove any confusion?
Right now it is there but with residency 0, but after this change the event is
not there anymore so I wonder if we are not just changing to a different kind
of confusion on users.
> return -ENODEV;
would a different return help somehow?
> break;
> case I915_PMU_SOFTWARE_GT_AWAKE_TIME:
> --
> 2.27.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/imx: fixes for v5.12
Hi Dave, Daniel, this PR includes a regression fix for the imx-ldb driver, which fails to register channel 1 if channel 0 is disabled since v5.12-rc2. Also, there's an imx-ldb build warning fix for W=1 builds and a fix for a memory leak in the imx-drm-core bind error path. The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-fixes-2021-04-01 for you to fetch changes up to 33ce7f2f95cabb5834cf0906308a5cb6103976da: drm/imx: imx-ldb: fix out of bounds array access warning (2021-03-25 07:48:34 +0100) drm/imx: imx-drm-core and imx-ldb fixes Fix a memory leak in an error path during DRM device initialization, fix the LDB driver to register channel 1 even if channel 0 is unused, and fix an out of bounds array access warning in the LDB driver. Arnd Bergmann (1): drm/imx: imx-ldb: fix out of bounds array access warning Liu Ying (1): drm/imx: imx-ldb: Register LDB channel1 when it is the only channel to be used Pan Bian (1): drm/imx: fix memory leak when fails to init drivers/gpu/drm/imx/imx-drm-core.c | 2 +- drivers/gpu/drm/imx/imx-ldb.c | 12 +++- 2 files changed, 12 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Do not report 100% RC6 if not supported
On Tue, Mar 30, 2021 at 04:06:37PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> We use GT parked status to estimate RC6 while not in use, however if RC6
> is not supported to start with that does not work very well and produces a
> false 100% RC6 readout.
oh! I had missed this one...
>
> Fix by not advancing the estimated RC6 counter when feature is not
> supported.
either this or the other proposal, consider both as
Reviewed-by: Rodrigo Vivi
I prefer this, but I don't have strong opinions on which one.
you (or Eero) pick one...
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
> Reported-by: Eero T Tamminen
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 41651ac255fa..02fe0d22c470 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -191,7 +191,10 @@ static u64 get_rc6(struct intel_gt *gt)
>* on top of the last known real value, as the approximated RC6
>* counter value.
>*/
> - val = ktime_since_raw(pmu->sleep_last);
> + if (gt->rc6.supported)
> + val = ktime_since_raw(pmu->sleep_last);
> + else
> + val = 0;
> val += pmu->sample[__I915_SAMPLE_RC6].cur;
> }
>
> --
> 2.27.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Check actual RC6 status
On 01/04/2021 10:19, Rodrigo Vivi wrote:
On Wed, Mar 31, 2021 at 11:18:50AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
RC6 support cannot be simply established by looking at the static device
HAS_RC6() flag. There are cases which disable RC6 at driver load time so
use the status of those check when deciding whether to enumerate the rc6
counter.
Signed-off-by: Tvrtko Ursulin
Reported-by: Eero T Tamminen
---
drivers/gpu/drm/i915/i915_pmu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 41651ac255fa..a75cd1db320b 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -476,6 +476,8 @@ engine_event_status(struct intel_engine_cs *engine,
static int
config_status(struct drm_i915_private *i915, u64 config)
{
+ struct intel_gt *gt = &i915->gt;
+
switch (config) {
case I915_PMU_ACTUAL_FREQUENCY:
if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
@@ -489,7 +491,7 @@ config_status(struct drm_i915_private *i915, u64 config)
case I915_PMU_INTERRUPTS:
break;
case I915_PMU_RC6_RESIDENCY:
- if (!HAS_RC6(i915))
+ if (!gt->rc6.supported)
Is this really going to remove any confusion?
Right now it is there but with residency 0, but after this change the event is
not there anymore so I wonder if we are not just changing to a different kind
of confusion on users.
I think it is possible to argue both ways.
1)
HAS_RC6 means hardware has RC6 so if we view PMU as very low level we
can say always export it.
If i915 had to turn it off (rc6->supported == false) due firmware or
GVT-g, then we could say reporting zero RC6 is accurate in that sense.
Only the reason "why it is zero" is missing for PMU users.
2)
Or if we go with this patch we could say that presence of the PMU metric
means RC6 is active and enabled, while absence means it is either not
supported due platform (or firmware) or how the platform is getting used
(GVT-g).
So I think patch is a bit better. I don't see it is adding more confusion.
return -ENODEV;
would a different return help somehow?
Like distinguishing between not theoretically possible to support on
this GPU, versus not active? Perhaps.. suggest an errno? :)
Regards,
Tvrtko
break;
case I915_PMU_SOFTWARE_GT_AWAKE_TIME:
--
2.27.0
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Check actual RC6 status
On Thu, Apr 01, 2021 at 10:38:11AM +0100, Tvrtko Ursulin wrote:
>
> On 01/04/2021 10:19, Rodrigo Vivi wrote:
> > On Wed, Mar 31, 2021 at 11:18:50AM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > RC6 support cannot be simply established by looking at the static device
> > > HAS_RC6() flag. There are cases which disable RC6 at driver load time so
> > > use the status of those check when deciding whether to enumerate the rc6
> > > counter.
> > >
> > > Signed-off-by: Tvrtko Ursulin
> > > Reported-by: Eero T Tamminen
> > > ---
> > > drivers/gpu/drm/i915/i915_pmu.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > > b/drivers/gpu/drm/i915/i915_pmu.c
> > > index 41651ac255fa..a75cd1db320b 100644
> > > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > > @@ -476,6 +476,8 @@ engine_event_status(struct intel_engine_cs *engine,
> > > static int
> > > config_status(struct drm_i915_private *i915, u64 config)
> > > {
> > > + struct intel_gt *gt = &i915->gt;
> > > +
> > > switch (config) {
> > > case I915_PMU_ACTUAL_FREQUENCY:
> > > if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> > > @@ -489,7 +491,7 @@ config_status(struct drm_i915_private *i915, u64
> > > config)
> > > case I915_PMU_INTERRUPTS:
> > > break;
> > > case I915_PMU_RC6_RESIDENCY:
> > > - if (!HAS_RC6(i915))
> > > + if (!gt->rc6.supported)
> >
> > Is this really going to remove any confusion?
> > Right now it is there but with residency 0, but after this change the event
> > is
> > not there anymore so I wonder if we are not just changing to a different
> > kind
> > of confusion on users.
>
> I think it is possible to argue both ways.
>
> 1)
> HAS_RC6 means hardware has RC6 so if we view PMU as very low level we can
> say always export it.
>
> If i915 had to turn it off (rc6->supported == false) due firmware or GVT-g,
> then we could say reporting zero RC6 is accurate in that sense. Only the
> reason "why it is zero" is missing for PMU users.
>
> 2)
> Or if we go with this patch we could say that presence of the PMU metric
> means RC6 is active and enabled, while absence means it is either not
> supported due platform (or firmware) or how the platform is getting used
> (GVT-g).
>
yeap, these 2 cases described well my mental conflict...
> So I think patch is a bit better. I don't see it is adding more confusion.
As I said on the other patch I have no strong position on which is better,
but if you and Eero feel that this works better for the current case,
let's do it...
>
> >
> > > return -ENODEV;
> >
> > would a different return help somehow?
>
> Like distinguishing between not theoretically possible to support on this
> GPU, versus not active? Perhaps.. suggest an errno? :)
ENODATA? or EIDRM?
But only if it helps somehow... otherwise don't bother and move with
this as is:
Reviewed-by: Rodrigo Vivi
>
> Regards,
>
> Tvrtko
>
> >
> > > break;
> > > case I915_PMU_SOFTWARE_GT_AWAKE_TIME:
> > > --
> > > 2.27.0
> > >
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] zero-fill colormap in drivers/video/fbdev/core/fbcmap.c
On Thu, Apr 1, 2021 at 12:09 AM Phillip Potter wrote:
> Use kzalloc() rather than kmalloc() for the dynamically allocated parts
> of the colormap in fb_alloc_cmap_gfp, to prevent a leak of random kernel
> data to userspace under certain circumstances.
>
> Fixes a KMSAN-found infoleak bug reported by syzbot at:
> https://syzkaller.appspot.com/bug?id=741578659feabd108ad9e06696f0c1f2e69c4b6e
>
> Reported-by: syzbot+47fa9c9c648b76530...@syzkaller.appspotmail.com
> Signed-off-by: Phillip Potter
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/34] drm/amdkfd: register svm range
Hi Felix,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20210331]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
drm/drm-next v5.12-rc5 v5.12-rc4 v5.12-rc3 v5.12-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
base:7a43c78d0573e00456b033e2b9a895b89464
config: x86_64-randconfig-a011-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/55f4d035262443207d455427967806e33fb85c06
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
git checkout 55f4d035262443207d455427967806e33fb85c06
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:380:19: warning: no previous
>> prototype for 'svm_range_clone' [-Wmissing-prototypes]
380 | struct svm_range *svm_range_clone(struct svm_range *old)
| ^~~
vim +/svm_range_clone +380 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c
379
> 380 struct svm_range *svm_range_clone(struct svm_range *old)
381 {
382 struct svm_range *new;
383
384 new = svm_range_new(old->svms, old->start, old->last);
385 if (!new)
386 return NULL;
387
388 new->flags = old->flags;
389 new->preferred_loc = old->preferred_loc;
390 new->prefetch_loc = old->prefetch_loc;
391 new->actual_loc = old->actual_loc;
392 new->granularity = old->granularity;
393 bitmap_copy(new->bitmap_access, old->bitmap_access,
MAX_GPU_INSTANCE);
394 bitmap_copy(new->bitmap_aip, old->bitmap_aip, MAX_GPU_INSTANCE);
395
396 return new;
397 }
398
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Check actual RC6 status
Hi, On Thu, 2021-04-01 at 05:54 -0400, Rodrigo Vivi wrote: > On Thu, Apr 01, 2021 at 10:38:11AM +0100, Tvrtko Ursulin wrote: ... > > I think it is possible to argue both ways. > > > > 1) > > HAS_RC6 means hardware has RC6 so if we view PMU as very low level > > we can > > say always export it. > > > > If i915 had to turn it off (rc6->supported == false) due firmware or > > GVT-g, > > then we could say reporting zero RC6 is accurate in that sense. Only > > the > > reason "why it is zero" is missing for PMU users. > > > > 2) > > Or if we go with this patch we could say that presence of the PMU > > metric > > means RC6 is active and enabled, while absence means it is either > > not > > supported due platform (or firmware) or how the platform is getting > > used > > (GVT-g). > > > > yeap, these 2 cases described well my mental conflict... > > > So I think patch is a bit better. I don't see it is adding more > > confusion. > > As I said on the other patch I have no strong position on which is > better, > but if you and Eero feel that this works better for the current case, > let's do it... IMHO seeing case 1) i.e. zero RC6 could be slightly better from user point of view than not seeing RC6 at all, because: A) user then knows that GPU is not entering RC6, and B) then the question is why it's not going to RC6 => one can see from sysfs that it has been disabled Whereas in case 2), the question is why there's no RC6 info, and user doesn't know whether GPU is suspended or not (i.e. why GPU power consumption is higher than expected). It would help if i-g-t could show e.g. "RC6 OFF" in that case. - Eero ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Dave, Daniel, It's still a fairly quiet week, but here's what should be our last drm-misc-next PR for 5.13 Maxime drm-misc-next-2021-04-01: drm-misc-next for 5.13: UAPI Changes: Cross-subsystem Changes: Core Changes: - mst: Improve topology logging - edid: Rework and improvements for displayid Driver Changes: - anx7625: Regulators support - bridge: Support for the Chipone ICN6211, Lontium LT8912B - lt9611: Fix 4k panels handling The following changes since commit 51c3b916a4d7e24b4918925965867fdd9bd8dd59: Merge tag 'drm-misc-next-2021-03-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2021-03-16 17:08:46 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-04-01 for you to fetch changes up to 6c744983004ebc66756e582294672f8b991288d5: drm/bridge: anx7625: disable regulators when power off (2021-04-01 10:38:02 +0200) drm-misc-next for 5.13: UAPI Changes: Cross-subsystem Changes: Core Changes: - mst: Improve topology logging - edid: Rework and improvements for displayid Driver Changes: - anx7625: Regulators support - bridge: Support for the Chipone ICN6211, Lontium LT8912B - lt9611: Fix 4k panels handling Adrien Grassein (2): dt-bindings: display: bridge: Add documentation for LT8912B drm/bridge: Introduce LT8912B DSI to HDMI bridge Arnd Bergmann (3): fbdev: omapfb: avoid -Wempty-body warning vgaarb: avoid -Wempty-body warnings drm/omap: fix misleading indentation in pixinc() Bhaskar Chowdhury (2): drm: Few typo fixes drm/meson: Fix few typo Christian König (9): drm/sched: select new rq even if there is only one v3 drm/qxl: clean up qxl_bo_move_notify drm/nouveau: clean up nouveau_bo_move_ntfy drm/vmwgfx: clean up vmw_move_notify v2 drm/ttm: move swapout logic around v3 drm/ttm: remove swap LRU v3 drm/ttm: switch to per device LRU lock drm/ttm: fix invalid NULL deref drm/ttm: switch back to static allocation limits for now Dafna Hirschfeld (1): drm: Fix 3 typos in the inline doc Daniel Vetter (1): dma-fence: Document recoverable page fault implications Dario Binacchi (3): drm/tilcdc: rename req_rate to pclk_rate drm/tilcdc: fix LCD pixel clock setting drm/tilcdc: fix pixel clock setting warning message Dmitry Vyukov (1): drm/vkms: fix misuse of WARN_ON Douglas Anderson (6): drm/panel-simple: Undo enable if HPD never asserts drm/panel-simple: Don't wait longer for HPD than hpd_absent_delay drm/panel-simple: Retry if we timeout waiting for HPD dt-bindings: dt-bindings: display: simple: Add N116BCA-EA1 drm/panel-simple: Add N116BCA-EA1 drm: panel: simple: Set enable delay for BOE NV110WTM-N61 Eryk Brol (1): drm/mst: Enhance MST topology logging Hsin-Yi Wang (2): dt-bindings: drm/bridge: anx7625: Add power supplies drm/bridge: anx7625: disable regulators when power off Jagan Teki (3): drm/stm: ltdc: Use simple encoder dt-bindings: display: bridge: Add Chipone ICN6211 bindings drm: bridge: Add Chipone ICN6211 MIPI-DSI to RGB bridge Jani Nikula (8): drm/edid: make a number of functions, parameters and variables const drm/displayid: add separate drm_displayid.c drm/displayid: add new displayid section/block iterators drm/edid: use the new displayid iterator for detailed modes drm/edid: use the new displayid iterator for finding CEA extension drm/edid: use the new displayid iterator for tile info drm/displayid: allow data blocks with 0 payload length drm/displayid: rename displayid_hdr to displayid_header Jianhui Zhao (1): docs: gpu: fix typo Jiapeng Chong (1): drm: bridge: convert sysfs sprintf/snprintf family to sysfs_emit Linus Walleij (1): drm/mcde/panel: Inverse misunderstood flag Lyude Paul (9): drm/bridge/tc358767: Don't register DP AUX channel until bridge is attached drm/bridge/ti-sn65dsi86: (Un)register aux device on bridge attach/detach drm/bridge/analogix/anx78xx: Add missing drm_dp_aux_unregister() call drm/bridge/analogix/anx78xx: Setup encoder before registering connector drm/bridge/analogix/anx78xx: Cleanup on error in anx78xx_bridge_attach() drm/bridge/analogix/anx6345: Add missing drm_dp_aux_unregister() call drm/bridge/analogix/anx6345: Don't link encoder until after connector registration drm/bridge/analogix/anx6345: Cleanup on errors in anx6345_bridge_attach() drm/bridge/analogix/dp_core: Unregister DP AUX channel on error in analogix_dp_probe() Matthew Wilcox (Oracle) (1): fb_defio: Remove custom address_space_operations Maxime Ripard (2): Merge drm/drm-next into drm-misc-next drm/rockch
Re: [PATCH v2 2/5] drm/vc4: hdmi: Properly compute the BVB clock rate
Hi Maxime
Sorry for the delay in reviewing these patches.
On Thu, 18 Mar 2021 at 09:29, Maxime Ripard wrote:
>
> The BVB clock rate computation doesn't take into account a mode clock of
> 594MHz that we're going to need to support 4k60.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index eee9751009c2..eaee853bb404 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -91,7 +91,6 @@
> # define VC4_HD_M_ENABLE BIT(0)
>
> #define CEC_CLOCK_FREQ 4
> -#define VC4_HSM_MID_CLOCK 149985000
>
> #define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
>
> @@ -739,7 +738,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder,
> conn_state_to_vc4_hdmi_conn_state(conn_state);
> struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> - unsigned long pixel_rate, hsm_rate;
> + unsigned long bvb_rate, pixel_rate, hsm_rate;
> int ret;
>
> ret = pm_runtime_get_sync(&vc4_hdmi->pdev->dev);
> @@ -793,12 +792,14 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder,
>
> vc4_hdmi_cec_update_clk_div(vc4_hdmi);
>
> - /*
> -* FIXME: When the pixel freq is 594MHz (4k60), this needs to be setup
> -* at 300MHz.
> -*/
> - ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock,
> - (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 :
> 7500));
> + if (pixel_rate > 29700)
> + bvb_rate = 3;
> + else if (pixel_rate > 14850)
> + bvb_rate = 15000;
> + else
> + bvb_rate = 7500;
> +
> + ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock, bvb_rate);
> if (ret) {
> DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
> clk_disable_unprepare(vc4_hdmi->hsm_clock);
> --
> 2.30.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/14] drm/bridge: ti-sn65dsi86: Power things properly for reading the EDID
W dniu 31.03.2021 o 16:48, Doug Anderson pisze:
> Hi,
>
> On Wed, Mar 31, 2021 at 4:08 AM Andrzej Hajda wrote:
>>
>> W dniu 30.03.2021 o 04:53, Douglas Anderson pisze:
>>> eDP panels won't provide their EDID unless they're powered on. Let's
>>> chain a power-on before we read the EDID. This roughly matches what
>>> was done in 'parade-ps8640.c'.
>>>
>>> NOTE: The old code attempted to call pm_runtime_get_sync() before
>>> reading the EDID. While that was enough to power the bridge chip on,
>>> it wasn't enough to talk to the panel for two reasons:
>>> 1. Since we never ran the bridge chip's pre-enable then we never set
>>> the bit to ignore HPD. This meant the bridge chip didn't even _try_
>>> to go out on the bus and communicate with the panel.
>>> 2. Even if we fixed things to ignore HPD, the EDID still wouldn't read
>>> if the panel wasn't on.
>>>
>>> One thing that's a bit odd here is taking advantage of the EDID that
>>> the core might have cached for us. See the patch ("drm/edid: Use the
>>> cached EDID in drm_get_edid() if eDP"). We manage to get at the cache
>>> by:
>>> - Instantly failing aux transfers if we're not powered.
>>> - If the first read of the EDID fails we try again after powering.
>>>
>>> Fixes: 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC")
>>> Signed-off-by: Douglas Anderson
>>> ---
>>> Depending on what people think of the other patches in this series,
>>> some of this could change.
>>> - If everyone loves the "runtime PM" in the panel driver then we
>>> could, in theory, put the pre-enable chaining straight in the "aux
>>> transfer" function.
>>> - If everyone hates the EDID cache moving to the core then we can
>>> avoid some of the awkward flow of things and keep the EDID cache in
>>> the sn65dsi86 driver.
>>
>> I wonder if this shouldn't be solved in the core - ie caller of
>> get_modes callback should be responsible for powering up the pipeline,
>> otherwise we need to repeat this stuff in every bridge/panel driver.
>>
>> Any thoughts?
> Yeah, I did look at this a little bit. Presumably it would only make
> sense to do it for eDP connections since:
>
> a) The concept of reading an EDID doesn't make sense for things like MIPI.
I guess you mean MIPI DSI, and yes I agree, more generally it usually(!)
doesn't make sense for any setup with fixed display panel.
On the other hand there are DSI/HDMI or DSI/DP adapters which usually
have EDID reading logic.
And the concept makes sense for most connectors accepting external
displays: HDMI, DP, MHL, VGA...
>
> b) For something with an external connector (DP and HDMI) you don't
> even know they're inserted unless the EDID is ready to read (these
> devices are, essentially, always powered).
Usually there are two elements which are not the same:
1. HotPlug signal/wire.
2. EDID reading logic.
The logic responsible for reading EDID needs to be enabled only for time
required for EDID reading :) So it's power state often must be
controlled explicitly by the bridge driver. So even if in many cases
pre_enable powers on the logic for EDID reading it does not make it the
rule, so I must step back from my claim that it is up to caller :)
>
> So I started off trying to do this in the core for eDP, but then it
> wasn't completely clear how to write this code in a way that was super
> generic. Specifically:
>
> 1. I don't think it's a 100% guarantee that everything is powered on
> in pre-enable and powered off in post-disable. In this bridge chip
> it's true, but maybe not every eDP driver? Would you want me to just
> assume this, or add a flag?
Ok, pre_enable should power on the chip, but for performing
initialization of video transport layer. Assumption it will power on
EDID logic is incorrect, so my claim seems wrong, but also this patch
looks incorrect :)
In general only device containing EDID logic knows how to power it up.
Since I do not know your particular case I can propose few possible ways
to investigate:
- call bridge.next->get_modes - you leave responsibility for powering up
to the downstream device.
- ddc driver on i2c request should power up the panel - seems also correct,
Regards
Andrzej
>
> 2. It wasn't totally clear to me which state to use for telling if the
> bridge had already been pre-enabled so I could avoid double-calling
> it. I could dig more if need be but I spent a bit of time looking and
> was coming up empty. If you have advice I'd appreciate it, though.
>
> 3. It wasn't clear to me if I should be using the atomic version
> (drm_atomic_bridge_chain_pre_enable) if I put this in the core and how
> exactly to do this, though I am a self-admitted DRM noob. I can do
> more digging if need be. Again, advice is appreciated.
>
> 4. Since I got feedback that the EDID caching belongs in the driver,
> not in the core [1] then we might end up powering things up
> pointlessly since the core wouldn't know if the driver was going to
> return the cache or
Re: [PATCH v2 3/5] drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequencies
Hi Maxime
On Thu, 18 Mar 2021 at 09:29, Maxime Ripard wrote:
>
> In order to reach the frequencies needed to output at 594MHz, the
> firmware needs to be configured with the appropriate parameters in the
> config.txt file (enable_hdmi_4kp60 and force_turbo).
>
> Let's detect it at bind time, warn the user if we can't, and filter out
> the relevant modes.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 26 ++
> drivers/gpu/drm/vc4/vc4_hdmi.h | 8
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index eaee853bb404..0924a1b9e186 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -210,6 +210,18 @@ static int vc4_hdmi_connector_get_modes(struct
> drm_connector *connector)
> ret = drm_add_edid_modes(connector, edid);
> kfree(edid);
>
> + if (vc4_hdmi->disable_4kp60) {
> + struct drm_device *drm = connector->dev;
> + struct drm_display_mode *mode;
> +
> + list_for_each_entry(mode, &connector->probed_modes, head) {
> + if ((mode->clock * 1000) > HDMI_14_MAX_TMDS_CLK) {
> + drm_warn_once(drm, "The core clock cannot
> reach frequencies high enough to support 4k @ 60Hz.");
> + drm_warn_once(drm, "Please change your
> config.txt file to add hdmi_enable_4kp60.");
> + }
> + }
> + }
> +
> return ret;
> }
>
> @@ -959,6 +971,9 @@ static int vc4_hdmi_encoder_atomic_check(struct
> drm_encoder *encoder,
> if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
> return -EINVAL;
>
> + if (vc4_hdmi->disable_4kp60 && (pixel_rate > HDMI_14_MAX_TMDS_CLK))
> + return -EINVAL;
> +
> vc4_state->pixel_rate = pixel_rate;
>
> return 0;
> @@ -978,6 +993,9 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> if ((mode->clock * 1000) > vc4_hdmi->variant->max_pixel_clock)
> return MODE_CLOCK_HIGH;
>
> + if (vc4_hdmi->disable_4kp60 && ((mode->clock * 1000) >
> HDMI_14_MAX_TMDS_CLK))
> + return MODE_CLOCK_HIGH;
> +
> return MODE_OK;
> }
>
> @@ -1992,6 +2010,14 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> vc4_hdmi->disable_wifi_frequencies =
> of_property_read_bool(dev->of_node,
> "wifi-2.4ghz-coexistence");
>
> + if (variant->max_pixel_clock == 6) {
> + struct vc4_dev *vc4 = to_vc4_dev(drm);
> + long max_rate = clk_round_rate(vc4->hvs->core_clk, 55000);
> +
> + if (max_rate < 55000)
> + vc4_hdmi->disable_4kp60 = true;
> + }
> +
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 3cebd1fd00fc..3cd021136402 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -154,6 +154,14 @@ struct vc4_hdmi {
> */
> bool disable_wifi_frequencies;
>
> + /*
> +* Even if HDMI0 on the RPi4 can output modes requiring a pixel
> +* rate higher than 297MHz, it needs some adjustments in the
> +* config.txt file to be able to do so and thus won't always be
> +* available.
> +*/
> + bool disable_4kp60;
> +
> struct cec_adapter *cec_adap;
> struct cec_msg cec_rx_msg;
> bool cec_tx_ok;
> --
> 2.30.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/vc4: hdmi: Enable the scrambler
Hi Maxime
On Thu, 18 Mar 2021 at 09:29, Maxime Ripard wrote:
>
> The HDMI controller on the BCM2711 includes a scrambler in order to
> reach the modes that require it. Let's add the support for it.
Nit pick - it's as part of the HDMI2.0 spec.
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 56 +
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 3 ++
> 2 files changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 0924a1b9e186..530c83097b1a 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -76,6 +77,8 @@
> #define VC5_HDMI_VERTB_VSPO_SHIFT 16
> #define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
>
> +#define VC5_HDMI_SCRAMBLER_CTL_ENABLE BIT(0)
> +
> #define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
> #define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10,
> 8)
>
> @@ -457,6 +460,56 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
> *encoder)
> vc4_hdmi_set_audio_infoframe(encoder);
> }
>
> +static bool vc4_hdmi_supports_scrambling(struct drm_encoder *encoder,
> +struct drm_display_mode *mode)
> +{
> + struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> + struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> + struct drm_display_info *display = &vc4_hdmi->connector.display_info;
> +
> + if (!vc4_encoder->hdmi_monitor)
> + return false;
> +
> + if (!display->hdmi.scdc.supported ||
> + !display->hdmi.scdc.scrambling.supported)
> + return false;
> +
I think I made this comment last time, but possibly not very clearly.
Up to this point in the function is whether the display/hdmi interface
*supports* scrambling. The bit after is whether it is *required* to be
enabled by the mode.
At the moment, if the display/interface supports scrambling but the
mode doesn't need it, then the scrambling setup is never touched. That
makes a few assumptions about the default settings.
Boot with the firmware selecting 4k60 (ie scrambling on), but
video=HDMI-1:1920x1080 in the kernel command line and you'll have a
mess with scrambling enabled but not signalled.
I'd be happier if the display/interface says scrambling is supported
then we always call drm_scdc_set_high_tmds_clock_ratio,
drm_scdc_set_scrambling and set the VC5_HDMI_SCRAMBLER_CTL_ENABLE
register bit appropriately for the mode. Feel free to disagree with me
though.
Dave
> + if ((mode->clock * 1000) < HDMI_14_MAX_TMDS_CLK)
> + return false;
> +
> + return true;
> +}
> +
> +static void vc4_hdmi_enable_scrambling(struct drm_encoder *encoder)
> +{
> + struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
> + struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> +
> + if (!vc4_hdmi_supports_scrambling(encoder, mode))
> + return;
> +
> + drm_scdc_set_high_tmds_clock_ratio(vc4_hdmi->ddc, true);
> + drm_scdc_set_scrambling(vc4_hdmi->ddc, true);
> +
> + HDMI_WRITE(HDMI_SCRAMBLER_CTL, HDMI_READ(HDMI_SCRAMBLER_CTL) |
> + VC5_HDMI_SCRAMBLER_CTL_ENABLE);
> +}
> +
> +static void vc4_hdmi_disable_scrambling(struct drm_encoder *encoder)
> +{
> + struct drm_display_mode *mode = &encoder->crtc->mode;
> + struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> +
> + if (!vc4_hdmi_supports_scrambling(encoder, mode))
> + return;
> +
> + HDMI_WRITE(HDMI_SCRAMBLER_CTL, HDMI_READ(HDMI_SCRAMBLER_CTL) &
> + ~VC5_HDMI_SCRAMBLER_CTL_ENABLE);
> +
> + drm_scdc_set_scrambling(vc4_hdmi->ddc, false);
> + drm_scdc_set_high_tmds_clock_ratio(vc4_hdmi->ddc, false);
> +}
> +
> static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder,
>struct drm_atomic_state *state)
> {
> @@ -469,6 +522,8 @@ static void vc4_hdmi_encoder_post_crtc_disable(struct
> drm_encoder *encoder,
>
> HDMI_WRITE(HDMI_VID_CTL,
>HDMI_READ(HDMI_VID_CTL) | VC4_HD_VID_CTL_BLANKPIX);
> +
> + vc4_hdmi_disable_scrambling(encoder);
> }
>
> static void vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder,
> @@ -919,6 +974,7 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct
> drm_encoder *encoder,
> }
>
> vc4_hdmi_recenter_fifo(vc4_hdmi);
> + vc4_hdmi_enable_scrambling(encoder);
> }
>
> static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
> b/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
> index e1b58eac766f..19d2fdc446bc 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi_regs
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Check actual RC6 status
On 01/04/2021 11:24, Tamminen, Eero T wrote: Hi, On Thu, 2021-04-01 at 05:54 -0400, Rodrigo Vivi wrote: On Thu, Apr 01, 2021 at 10:38:11AM +0100, Tvrtko Ursulin wrote: ... I think it is possible to argue both ways. 1) HAS_RC6 means hardware has RC6 so if we view PMU as very low level we can say always export it. If i915 had to turn it off (rc6->supported == false) due firmware or GVT-g, then we could say reporting zero RC6 is accurate in that sense. Only the reason "why it is zero" is missing for PMU users. 2) Or if we go with this patch we could say that presence of the PMU metric means RC6 is active and enabled, while absence means it is either not supported due platform (or firmware) or how the platform is getting used (GVT-g). yeap, these 2 cases described well my mental conflict... So I think patch is a bit better. I don't see it is adding more confusion. As I said on the other patch I have no strong position on which is better, but if you and Eero feel that this works better for the current case, let's do it... IMHO seeing case 1) i.e. zero RC6 could be slightly better from user point of view than not seeing RC6 at all, because: A) user then knows that GPU is not entering RC6, and B) then the question is why it's not going to RC6 => one can see from sysfs that it has been disabled Whereas in case 2), the question is why there's no RC6 info, and user doesn't know whether GPU is suspended or not (i.e. why GPU power consumption is higher than expected). It would help if i-g-t could show e.g. "RC6 OFF" in that case. So many options.. :) It can be handle on the "presentation" layer (intel_gpu_top). If we go with this patch but different errnos it could indeed distinguish and either not show RC6 or say "RC6 OFF". If we go with the other patch (https://patchwork.freedesktop.org/patch/426589/?series=88580&rev=1) then intel_gpu_top could really still do the same by looking at /sys/class/drm/card0/power/rc6_enable. So strictly no i915 patch is even needed to provide clarity in intel_gpu_top. But still one of those two i915 patches is required to improve how low-level Perf/PMU RC6 counter gets exposed (or not exposed). I don't have a strong preference which one to take either. :) Regards, Tvrtko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/34] drm/amdkfd: deregister svm range
Hi Felix,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20210331]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
drm/drm-next v5.12-rc5 v5.12-rc4 v5.12-rc3 v5.12-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
base:7a43c78d0573e00456b033e2b9a895b89464
config: x86_64-randconfig-a011-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/545d8003c8da8397f0fa9657f97ed67441dd1087
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
git checkout 545d8003c8da8397f0fa9657f97ed67441dd1087
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:417:6: warning: no previous
>> prototype for 'svm_range_add_child' [-Wmissing-prototypes]
417 | void svm_range_add_child(struct svm_range *prange, struct mm_struct
*mm,
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:511:19: warning: no previous
prototype for 'svm_range_clone' [-Wmissing-prototypes]
511 | struct svm_range *svm_range_clone(struct svm_range *old)
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:766:1: warning: no previous
prototype for 'svm_range_add_list_work' [-Wmissing-prototypes]
766 | svm_range_add_list_work(struct svm_range_list *svms, struct
svm_range *prange,
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:788:6: warning: no previous
prototype for 'schedule_deferred_list_work' [-Wmissing-prototypes]
788 | void schedule_deferred_list_work(struct svm_range_list *svms)
| ^~~
vim +/svm_range_add_child +417 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c
416
> 417 void svm_range_add_child(struct svm_range *prange, struct mm_struct *mm,
418 struct svm_range *pchild, enum
svm_work_list_ops op)
419 {
420 pr_debug("add child 0x%p [0x%lx 0x%lx] to prange 0x%p child
list %d\n",
421 pchild, pchild->start, pchild->last, prange, op);
422
423 pchild->work_item.mm = mm;
424 pchild->work_item.op = op;
425 list_add_tail(&pchild->child_list, &prange->child_list);
426 }
427
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 5/8] mm: Device exclusive memory access
On Thu, Apr 01, 2021 at 01:20:05PM +1100, Alistair Popple wrote: > On Thursday, 1 April 2021 11:48:13 AM AEDT Jason Gunthorpe wrote: > > On Thu, Apr 01, 2021 at 11:45:57AM +1100, Alistair Popple wrote: > > > On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote: > > > > On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote: > > > > > On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote: > > > > > > On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote: > > > > > > > > > > > > > I guess that makes sense as the split could go either way at the > > > > > > > moment but I should add a check to make sure this isn't used with > > > > > > > pinned pages anyway. > > > > > > > > > > > > Is it possible to have a pinned page under one of these things? If I > > > > > > pin it before you migrate it then it remains pinned but hidden under > > > > > > the swap entry? > > > > > > > > > > At the moment yes. But I had planned (and this reminded me) to add a > check > > > to > > > > > prevent marking pinned pages for exclusive access. > > > > > > > > How do you even do that without races with GUP fast? > > > > > > Unless I've missed something I think I've convinced myself it should be > safe > > > to do the pin check after make_device_exclusive() has replaced all the > PTEs > > > with exclusive entries. > > > > > > GUP fast sequence: > > > 1. Read PTE > > > 2. Pin page > > > 3. Check PTE > > > 4. if PTE changed -> unpin and fallback > > > > > > If make_device_exclusive() runs after (1) it will either succeed or see > the > > > pin from (2) and fail (as desired). GUP should always see the PTE change > and > > > fallback which will revoke the exclusive access. > > > > AFAICT the user can trigger fork at that instant and fork will try to > > copy the desposited migration entry before it has been checked > > In that case the child will get a read-only exclusive entry and eventually a > page copy via do_wp_page() Having do_wp_page() do a copy is a security bug. We closed it with the at-fork checks. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/32] Fix broken documentation file references
Each patch on this series can be applied independently. They fix broken file references. Most of them are due to DT binding renames, but there are also other unrelated changes. This series is based on next-20210401. Mauro Carvalho Chehab (32): MAINTAINERS: update adi,ad5758.yaml reference MAINTAINERS: update ste,mcde.yaml reference MAINTAINERS: update brcm,bcm-v3d.yaml reference MAINTAINERS: update fsl,dpaa2-console.yaml reference MAINTAINERS: update st,hts221.yaml reference MAINTAINERS: update dpot-dac.yaml reference MAINTAINERS: update envelope-detector.yaml reference MAINTAINERS: update current-sense-amplifier.yaml reference MAINTAINERS: update current-sense-shunt.yaml reference MAINTAINERS: update voltage-divider.yaml reference MAINTAINERS: update invensense,mpu3050.yaml reference MAINTAINERS: update lego,ev3-battery.yaml reference MAINTAINERS: update marvell,armada-3700-utmi-phy.yaml reference MAINTAINERS: update mtk-sd.yaml reference MAINTAINERS: update atmel,sama5d2-adc.yaml reference MAINTAINERS: update pni,rm3100.yaml reference MAINTAINERS: update renesas,rcar-gyroadc.yaml reference MAINTAINERS: update st,lsm6dsx.yaml reference MAINTAINERS: update st,vl53l0x.yaml reference MAINTAINERS: update snps,dw-axi-dmac.yaml reference MAINTAINERS: update ti,dac7612.yaml reference MAINTAINERS: update nxp,imx8-jpeg.yaml reference MAINTAINERS: update ovti,ov2680.yaml reference MAINTAINERS: update imi,rdacm2x-gmsl.yaml reference dt-bindings:iio:dac: update microchip,mcp4725.yaml reference dt-bindings: iommu: mediatek: update mediatek,iommu.yaml references dt-bindings: i3c: update i3c.yaml references dt-bindings: power: update battery.yaml reference docs: dt: update writing-schema.rst references Documentation: net: dsa: update configuration.rst reference Documentation: update sysfs-platform_profile.rst reference pinctrl: update pin-control.rst references .../display/mediatek/mediatek,disp.txt| 2 +- .../bindings/i3c/cdns,i3c-master.txt | 6 +-- .../bindings/i3c/snps,dw-i3c-master.txt | 6 +-- .../bindings/media/mediatek-jpeg-decoder.txt | 2 +- .../bindings/media/mediatek-jpeg-encoder.txt | 2 +- .../bindings/media/mediatek-mdp.txt | 2 +- .../bindings/media/mediatek-vcodec.txt| 2 +- .../bindings/submitting-patches.rst | 2 +- Documentation/filesystems/cifs/cifsd.rst | 2 +- Documentation/power/power_supply_class.rst| 2 +- MAINTAINERS | 48 +-- include/linux/device.h| 2 +- include/linux/iio/dac/mcp4725.h | 2 +- include/linux/mfd/madera/pdata.h | 2 +- include/linux/pinctrl/pinconf-generic.h | 2 +- include/linux/platform_profile.h | 2 +- scripts/checkpatch.pl | 2 +- 17 files changed, 44 insertions(+), 44 deletions(-) -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 26/32] dt-bindings: iommu: mediatek: update mediatek, iommu.yaml references
Changeset bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT
schema")
renamed: Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
to: Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml.
Update the cross-references accordingly.
Fixes: bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT schema")
Signed-off-by: Mauro Carvalho Chehab
---
.../devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
.../devicetree/bindings/media/mediatek-jpeg-decoder.txt | 2 +-
.../devicetree/bindings/media/mediatek-jpeg-encoder.txt | 2 +-
Documentation/devicetree/bindings/media/mediatek-mdp.txt| 2 +-
Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 93b160df3eec..fbb59c9ddda6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -64,7 +64,7 @@ Required properties (DMA function blocks):
- larb: Should contain a phandle pointing to the local arbiter device as
defined
in
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
- iommus: Should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
Optional properties (RDMA function blocks):
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
index cf60c5acc0e4..39c1028b2dfb 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
@@ -19,7 +19,7 @@ Required properties:
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
for details.
- iommus: should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
Example:
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
index acfb50375b8a..5e53c6ab52d0 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
@@ -17,7 +17,7 @@ Required properties:
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
for details.
- iommus: should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
Example:
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
index f4798d04e925..caa24943da33 100644
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -25,7 +25,7 @@ Required properties (DMA function blocks, child node):
"mediatek,mt8173-mdp-wdma"
"mediatek,mt8173-mdp-wrot"
- iommus: should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
- mediatek,larb: must contain the local arbiters in the current Socs, see
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 8217424fd4bd..a83ebc1a1c7f 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -18,7 +18,7 @@ Required properties:
"univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
"venc_lt_sel", "vdec_bus_clk_src".
- iommus : should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
One of the two following nodes:
- mediatek,vpu : the node of the video processor unit, if using VPU.
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Try YCbCr420 color when YCbCr444 fails
Am 29.03.21 um 17:28 schrieb Alex Deucher:
> Applied. Thanks!
>
> Alex
Nice to hear that ^^
One quick question: Here do I find the amd-gfx dev branch?
Kind regards,
Werner Sembach
>
> On Fri, Mar 26, 2021 at 10:59 AM Harry Wentland
> wrote:
>>
>>
>> On 2021-03-24 4:23 p.m., Alex Deucher wrote:
>>> On Wed, Mar 17, 2021 at 11:25 AM Werner Sembach
>>> wrote:
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.
Signed-off-by: Werner Sembach
Cc:
>>>
>>> This seems reasonable to me. Harry, Leo, Any objections?
>>>
>> Looks good to me.
>>
>> Reviewed-by: Harry Wentland
>>
>> Harry
>>
>>> Alex
>>>
---
From c9398160caf4ff20e63b8ba3a4366d6ef95c4ac3 Mon Sep 17 00:00:00 2001
From: Werner Sembach
Date: Wed, 17 Mar 2021 12:52:22 +0100
Subject: [PATCH] Retry forcing YCbCr420 color on failed encoder validation
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
1 file changed, 9 insertions(+)
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 961abf1cf040..2d16389b5f1e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5727,6 +5727,15 @@ create_validate_stream_for_sink(struct
amdgpu_dm_connector *aconnector,
} while (stream == NULL && requested_bpc >= 6);
+ if (dc_result == DC_FAIL_ENC_VALIDATE &&
!aconnector->force_yuv420_output) {
+ DRM_DEBUG_KMS("Retry forcing YCbCr420 encoding\n");
+
+ aconnector->force_yuv420_output = true;
+ stream = create_validate_stream_for_sink(aconnector,
drm_mode,
+ dm_state, old_stream);
+ aconnector->force_yuv420_output = false;
+ }
+
return stream;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/5] dt-bindings:drm/bridge:anx7625:add vendor define flags
Hey Xin,
This series no longer applies to drm-misc/drm-misc-next, please rebase it.
On Wed, 24 Mar 2021 at 08:52, Xin Ji wrote:
>
> On Sun, Mar 21, 2021 at 02:00:38PM +0200, Laurent Pinchart wrote:
> > Hi Xin,
> >
> > Thank you for the patch.
> >
> > On Fri, Mar 19, 2021 at 02:32:39PM +0800, Xin Ji wrote:
> > > Add 'bus-type' and 'data-lanes' define for port0. Define DP tx lane0,
> > > lane1 swing register array define, and audio enable flag.
> > >
> > > Signed-off-by: Xin Ji
> > > ---
> > > .../display/bridge/analogix,anx7625.yaml | 58 ++-
> > > 1 file changed, 57 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > index c789784efe30..3f54d5876982 100644
> > > ---
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > +++
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > @@ -34,6 +34,26 @@ properties:
> > > description: used for reset chip control, RESET_N pin B7.
> > > maxItems: 1
> > >
> > > + analogix,lane0-swing:
> > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > > +minItems: 1
> > > +maxItems: 20
> > > +description:
> > > + an array of swing register setting for DP tx lane0 PHY, please
> > > don't
> > > + add this property, or contact vendor.
> >
> > DT properties need to be documented. Contacting the vendor doesn't count
> > as documentation I'm afraid.
>
> Hi Laurent Pinchart, thanks for your comment. For the DP phy swing
> setting, it is hard to describe in here, needs to refer the anx7625
> datasheet and programming guide. Basically, no need to change the DP phy
> swing setting.
>
Laurent is right. But if the value practically is a constant, you can
move the swing register into the driver. It should still be documented
as well as possible, but we can be a little bit more flexible.
> > > @@ -73,6 +123,10 @@ examples:
> > > enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> > > reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> > >
> > > +analogix,audio-enable;
> > > +analogix,lane0-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77
> > > 0x5b>;
> > > +analogix,lane1-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77
> > > 0x5b>;
> > > +
> > > ports {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/sched: add missing member documentation
Just fix a warning.
Signed-off-by: Christian König
Reported-by: Stephen Rothwell
Fixes: f2f12eb9c32b ("drm/scheduler: provide scheduler score externally")
---
include/drm/gpu_scheduler.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 1c815e0a14ed..f888b5e9583a 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -277,6 +277,7 @@ struct drm_sched_backend_ops {
* @hang_limit: once the hangs by a job crosses this limit then it is marked
* guilty and it will be considered for scheduling further.
* @score: score to help loadbalancer pick a idle sched
+ * @_score: score used when the driver doesn't provide one
* @ready: marks if the underlying HW is ready to work
* @free_guilty: A hit to time out handler to free the guilty job.
*
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/i915: Fix an uninitialized variable issue
From: Colin Ian King
Currently there is a while loop that contains a handful of continue
statements that can skip over the assignment of the variable err. At
the end of the loop there is a potiential for err to be unassigned
and possibly causing issues when err is checked for a non-zero value.
Fix this by setting err to zero before the while loop starts.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 3e248d3bd869..1e24ba872029 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -180,6 +180,7 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww,
* the unbound/bound list until actually freed.
*/
spin_lock_irqsave(&i915->mm.obj_lock, flags);
+ err = 0;
while (count < target &&
(obj = list_first_entry_or_null(phase->list,
typeof(*obj),
@@ -202,7 +203,6 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww,
spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
- err = 0;
if (unsafe_drop_pages(obj, shrink)) {
/* May arrive from get_pages on another bo */
if (!ww) {
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: add __user annotation in radeon_ttm_vram_read
Am 24.10.20 um 02:47 schrieb Rasmus Villemoes: Keep sparse happy by preserving the __user annotation when casting. Reported-by: kernel test robot Signed-off-by: Rasmus Villemoes Reviewed-by: Christian König Going over old patches and stumbled over that once. Alex did you missed to pick it up? Regards, Christian. --- kernel test robot has already started spamming me due to 9c5743dff. If I don't fix those warnings I'll keep getting those emails for months, so let me do the easy ones. drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 36150b7f31a90aa1eece..ecfe88b0a35d8f317712 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -1005,7 +1005,7 @@ static ssize_t radeon_ttm_vram_read(struct file *f, char __user *buf, value = RREG32(RADEON_MM_DATA); spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags); - r = put_user(value, (uint32_t *)buf); + r = put_user(value, (uint32_t __user *)buf); if (r) return r; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [v1] drm/msm/disp/dpu1: fix warn stack reported during dpu resume
On 2021-04-01 07:37, Dmitry Baryshkov wrote:
On 01/04/2021 01:47, Rob Clark wrote:
On Wed, Mar 31, 2021 at 9:03 AM Dmitry Baryshkov
wrote:
On 31/03/2021 14:27, Kalyan Thota wrote:
WARN_ON was introduced by the below commit to catch runtime resumes
that are getting triggered before icc path was set.
"drm/msm/disp/dpu1: icc path needs to be set before dpu runtime
resume"
For the targets where the bw scaling is not enabled, this WARN_ON is
a false alarm. Fix the WARN condition appropriately.
Should we change all DPU targets to use bw scaling to the mdp from
the
mdss nodes? The limitation to sc7180 looks artificial.
yes, we should, this keeps biting us on 845
Done,
https://lore.kernel.org/linux-arm-msm/20210401020533.3956787-2-dmitry.barysh...@linaro.org/
Hi Dmitry,
https://lore.kernel.org/linux-arm-msm/20210401020533.3956787-2-dmitry.barysh...@linaro.org/
you need to add clk_inefficiency_factor, bw_inefficiency_factor in the
catalogue for the new
targets where bw scaling is being enabled. please reuse sc7180 values.
secondly, the AXI clock needs to be moved from mdss to mdp device like
as in sc7180 dt if its not done already.
lastly, if you are planning to remove the static votes from dpu_mdss, do
you also want to move the
interconnect paths from mdss device to mdp device in the dt ?
Thanks,
Kalyan
Reported-by: Steev Klimaszewski
Please add Fixes: tag as well
Adding Fixes tag above my sign-off, should i push another version or can
it be picked from here ?
Fixes: Id252b9c2887 ("drm/msm/disp/dpu1: icc path needs to be set before
dpu runtime resume")
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 9 +
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 11 ++-
3 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index cab387f..0071a4d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -294,6 +294,9 @@ static int
dpu_kms_parse_data_bus_icc_path(struct dpu_kms *dpu_kms)
struct icc_path *path1;
struct drm_device *dev = dpu_kms->dev;
+ if (!dpu_supports_bw_scaling(dev))
+ return 0;
+
path0 = of_icc_get(dev->dev, "mdp0-mem");
path1 = of_icc_get(dev->dev, "mdp1-mem");
@@ -934,8 +937,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
DPU_DEBUG("REG_DMA is not defined");
}
- if (of_device_is_compatible(dev->dev->of_node,
"qcom,sc7180-mdss"))
- dpu_kms_parse_data_bus_icc_path(dpu_kms);
+ dpu_kms_parse_data_bus_icc_path(dpu_kms);
pm_runtime_get_sync(&dpu_kms->pdev->dev);
@@ -1198,7 +1200,7 @@ static int __maybe_unused
dpu_runtime_resume(struct device *dev)
ddev = dpu_kms->dev;
- WARN_ON(!(dpu_kms->num_paths));
+ WARN_ON((dpu_supports_bw_scaling(ddev) &&
!dpu_kms->num_paths));
/* Min vote of BW is required before turning on AXI clk */
for (i = 0; i < dpu_kms->num_paths; i++)
icc_set_bw(dpu_kms->path[i], 0,
Bps_to_icc(MIN_IB_BW));
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index d6717d6..f7bcc0a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -154,6 +154,15 @@ struct vsync_info {
#define to_dpu_global_state(x) container_of(x, struct
dpu_global_state, base)
+/**
+ * dpu_supports_bw_scaling: returns true for drivers that support
bw scaling.
+ * @dev: Pointer to drm_device structure
+ */
+static inline int dpu_supports_bw_scaling(struct drm_device *dev)
+{
+ return of_device_is_compatible(dev->dev->of_node,
"qcom,sc7180-mdss");
+}
+
/* Global private object state for tracking resources that are
shared across
* multiple kms objects (planes/crtcs/etc).
*/
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index cd40788..8cd712c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -41,6 +41,9 @@ static int dpu_mdss_parse_data_bus_icc_path(struct
drm_device *dev,
struct icc_path *path0 = of_icc_get(dev->dev, "mdp0-mem");
struct icc_path *path1 = of_icc_get(dev->dev, "mdp1-mem");
+ if (dpu_supports_bw_scaling(dev))
+ return 0;
+
if (IS_ERR_OR_NULL(path0))
return PTR_ERR_OR_ZERO(path0);
@@ -276,11 +279,9 @@ int dpu_mdss_init(struct drm_device *dev)
DRM_DEBUG("mapped mdss address space @%pK\n",
dpu_mdss->mmio);
- if (!of_device_is_compatible(dev->dev->of_node,
"qcom,sc7180-mdss")) {
- ret = dpu_mdss_parse_data_bus_icc_path(dev, dpu_mdss);
- if (ret)
- return ret;
- }
+ ret = dpu_mdss_parse_data_bus_icc_path(dev, dpu_mdss);
+ if (ret
Re: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
On Thu, Apr 01, 2021 at 11:59:45AM +0200, Christoph Hellwig wrote: > For now I'll just pass the iommu_domain to iommu_get_dma_strict, > so that we can check for it. We can do additional cleanups on top > of that later. Sounds good to me, cheers! Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/34] drm/amdkfd: map svm range to GPUs
Hi Felix,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20210331]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
drm/drm-next v5.12-rc5 v5.12-rc4 v5.12-rc3 v5.12-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
base:7a43c78d0573e00456b033e2b9a895b89464
config: x86_64-randconfig-a011-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/bb9c90022dd6afd456d4b40a20d007e57efc35ed
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
git checkout bb9c90022dd6afd456d4b40a20d007e57efc35ed
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:167:6: warning: no previous
prototype for 'svm_range_dma_unmap' [-Wmissing-prototypes]
167 | void svm_range_dma_unmap(struct device *dev, dma_addr_t *dma_addr,
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:599:6: warning: no previous
prototype for 'svm_range_add_child' [-Wmissing-prototypes]
599 | void svm_range_add_child(struct svm_range *prange, struct mm_struct
*mm,
| ^~~
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:795:5: warning: no previous
>> prototype for 'svm_range_reserve_bos' [-Wmissing-prototypes]
795 | int svm_range_reserve_bos(struct svm_validate_context *ctx)
| ^
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:849:6: warning: no previous
>> prototype for 'svm_range_unreserve_bos' [-Wmissing-prototypes]
849 | void svm_range_unreserve_bos(struct svm_validate_context *ctx)
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:967:19: warning: no previous
prototype for 'svm_range_clone' [-Wmissing-prototypes]
967 | struct svm_range *svm_range_clone(struct svm_range *old)
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:1222:1: warning: no previous
prototype for 'svm_range_add_list_work' [-Wmissing-prototypes]
1222 | svm_range_add_list_work(struct svm_range_list *svms, struct
svm_range *prange,
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:1244:6: warning: no previous
prototype for 'schedule_deferred_list_work' [-Wmissing-prototypes]
1244 | void schedule_deferred_list_work(struct svm_range_list *svms)
| ^~~
vim +/svm_range_reserve_bos +795 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c
794
> 795 int svm_range_reserve_bos(struct svm_validate_context *ctx)
796 {
797 struct kfd_process_device *pdd;
798 struct amdgpu_device *adev;
799 struct amdgpu_vm *vm;
800 uint32_t gpuidx;
801 int r;
802
803 INIT_LIST_HEAD(&ctx->validate_list);
804 for_each_set_bit(gpuidx, ctx->bitmap, MAX_GPU_INSTANCE) {
805 pdd = kfd_process_device_from_gpuidx(ctx->process,
gpuidx);
806 if (!pdd) {
807 pr_debug("failed to find device idx %d\n",
gpuidx);
808 return -EINVAL;
809 }
810 adev = (struct amdgpu_device *)pdd->dev->kgd;
811 vm = pdd->vm;
812
813 ctx->tv[gpuidx].bo = &vm->root.base.bo->tbo;
814 ctx->tv[gpuidx].num_shared = 4;
815 list_add(&ctx->tv[gpuidx].head, &ctx->validate_list);
816 }
817
818 r = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->validate_list,
819 ctx->intr, NULL);
820 if (r) {
821 pr_debug("failed %d to reserve bo\n", r);
822 return r;
823 }
824
825 for_each_set_bit(gpuidx, ctx->bitmap, MAX_GPU_INSTANCE) {
826 pdd = kfd_process_device_from_gpuidx(ctx->process,
gpuidx);
827 if (!pdd) {
828 pr_deb
Re: [Freedreno] [v1] drm/msm/disp/dpu1: fix warn stack reported during dpu resume
On Thu, 1 Apr 2021 at 16:19, wrote:
>
> On 2021-04-01 07:37, Dmitry Baryshkov wrote:
> > On 01/04/2021 01:47, Rob Clark wrote:
> >> On Wed, Mar 31, 2021 at 9:03 AM Dmitry Baryshkov
> >> wrote:
> >>>
> >>> On 31/03/2021 14:27, Kalyan Thota wrote:
> WARN_ON was introduced by the below commit to catch runtime resumes
> that are getting triggered before icc path was set.
>
> "drm/msm/disp/dpu1: icc path needs to be set before dpu runtime
> resume"
>
> For the targets where the bw scaling is not enabled, this WARN_ON is
> a false alarm. Fix the WARN condition appropriately.
> >>>
> >>> Should we change all DPU targets to use bw scaling to the mdp from
> >>> the
> >>> mdss nodes? The limitation to sc7180 looks artificial.
> >>
> >> yes, we should, this keeps biting us on 845
> >
> > Done,
> > https://lore.kernel.org/linux-arm-msm/20210401020533.3956787-2-dmitry.barysh...@linaro.org/
>
> Hi Dmitry,
>
> https://lore.kernel.org/linux-arm-msm/20210401020533.3956787-2-dmitry.barysh...@linaro.org/
>
> you need to add clk_inefficiency_factor, bw_inefficiency_factor in the
> catalogue for the new
> targets where bw scaling is being enabled. please reuse sc7180 values.
Done in patch 1 in that series.
>
> secondly, the AXI clock needs to be moved from mdss to mdp device like
> as in sc7180 dt if its not done already.
Is this enough:
sm8250 has <&gcc GCC_DISP_HF_AXI_CLK> both in mdss and mdp nodes
sdm845 has <&gcc GCC_DISP_AXI_CLK> in mdss node and <&dispcc
DISP_CC_MDSS_AXI_CLK> in the mdp node.
>
> lastly, if you are planning to remove the static votes from dpu_mdss, do
> you also want to move the
> interconnect paths from mdss device to mdp device in the dt ?
I have no strong opinion on this. So far I did not change dt to be
compatible with the current device trees.
>
>
> Thanks,
> Kalyan
>
> >
> >>
>
> Reported-by: Steev Klimaszewski
> >>
> >> Please add Fixes: tag as well
> Adding Fixes tag above my sign-off, should i push another version or can
> it be picked from here ?
>
> Fixes: Id252b9c2887 ("drm/msm/disp/dpu1: icc path needs to be set before
> dpu runtime resume")
> >>
> Signed-off-by: Kalyan Thota
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 +---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 9 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 11 ++-
> 3 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index cab387f..0071a4d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -294,6 +294,9 @@ static int
> dpu_kms_parse_data_bus_icc_path(struct dpu_kms *dpu_kms)
> struct icc_path *path1;
> struct drm_device *dev = dpu_kms->dev;
>
> + if (!dpu_supports_bw_scaling(dev))
> + return 0;
> +
> path0 = of_icc_get(dev->dev, "mdp0-mem");
> path1 = of_icc_get(dev->dev, "mdp1-mem");
>
> @@ -934,8 +937,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
> DPU_DEBUG("REG_DMA is not defined");
> }
>
> - if (of_device_is_compatible(dev->dev->of_node,
> "qcom,sc7180-mdss"))
> - dpu_kms_parse_data_bus_icc_path(dpu_kms);
> + dpu_kms_parse_data_bus_icc_path(dpu_kms);
>
> pm_runtime_get_sync(&dpu_kms->pdev->dev);
>
> @@ -1198,7 +1200,7 @@ static int __maybe_unused
> dpu_runtime_resume(struct device *dev)
>
> ddev = dpu_kms->dev;
>
> - WARN_ON(!(dpu_kms->num_paths));
> + WARN_ON((dpu_supports_bw_scaling(ddev) &&
> !dpu_kms->num_paths));
> /* Min vote of BW is required before turning on AXI clk */
> for (i = 0; i < dpu_kms->num_paths; i++)
> icc_set_bw(dpu_kms->path[i], 0,
> Bps_to_icc(MIN_IB_BW));
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> index d6717d6..f7bcc0a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> @@ -154,6 +154,15 @@ struct vsync_info {
>
> #define to_dpu_global_state(x) container_of(x, struct
> dpu_global_state, base)
>
> +/**
> + * dpu_supports_bw_scaling: returns true for drivers that support
> bw scaling.
> + * @dev: Pointer to drm_device structure
> + */
> +static inline int dpu_supports_bw_scaling(struct drm_device *dev)
> +{
> + return of_device_is_compatible(dev->dev->of_node,
> "qcom,sc7180-mdss");
> +}
> +
> /* Global private object state for tracking resources that are
> shared across
> * multiple kms objects (planes/crtcs/etc).
> */
> diff
Re: [PATCH v2 05/20] drm/dp: Add backpointer to drm_device in drm_dp_aux
On Fri, 26 Mar 2021, Lyude Paul wrote:
> * The @dev field should be set to a pointer to the device that implements
> the
> - * AUX channel.
> + * AUX channel. As well, the @drm_dev field should be set to the &drm_device
> + * that will be using this AUX channel as early as possible. For many
> graphics
> + * drivers this should happen before drm_dp_aux_init(), however it's
> perfectly
> + * fine to set this field later so long as it's assigned before calling
> + * drm_dp_aux_register().
Perhaps add a follow-up patch to actually ensure this is the case in
drm_dp_aux_register()?
> *
> * The @name field may be used to specify the name of the I2C adapter. If
> set to
> * %NULL, dev_name() of @dev will be used.
> @@ -1877,6 +1883,7 @@ struct drm_dp_aux {
> const char *name;
> struct i2c_adapter ddc;
> struct device *dev;
> + struct drm_device *drm_dev;
Bikeshed, I would probably have called it just drm for brevity, but no
strong feelings.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 00/20] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers
On Fri, 26 Mar 2021, Lyude Paul wrote:
> Since it's been asked quite a few times on some of the various DP
> related patch series I've submitted to use the new DRM printk helpers,
> and it technically wasn't really trivial to do this before due to the
> lack of a consistent way to find a drm_device for an AUX channel, this
> patch series aims to address this. In this series we:
>
> * Clean-up potentially erroneous usages of drm_dp_aux_init() and
> drm_dp_aux_register() so that actual AUX registration doesn't happen
> until we have an associated DRM device
> * Clean-up any obvious errors in drivers we find along the way
> * Add a backpointer to the respective drm_device for an AUX channel in
> drm_dp_aux.drm_dev, and hook it up in every driver with an AUX channel
> across the tree
> * Add a new ratelimited print helper we'll need for converting the DP
> helpers over to using the new DRM printk helpers
> * Fix any inconsistencies with logging in drm_dp_helper.c so we always
> have the aux channel name printed
> * Prepare the various DP helpers so they can find the correct drm_device
> to use for logging
> * And finally, convert all of the DP helpers over to using drm_dbg_*()
> and drm_err().
>
> Series-wide changes in v2:
> * Address most checkpatch issues ('most' as in all except for one line
> going two chars over 100 in "drm/dp_mst: Pass drm_dp_mst_topology_mgr
> to drm_dp_get_vc_payload_bw()" as this was the style in use
> previously, and 2 chars over the limit looks nicer then trying to
> line-wrap this
> * Don't rewrap comments
For anything touching i915, and for merging via whichever tree or branch
seems best,
Acked-by: Jani Nikula
That said, gut feeling says there will be conflicts before latest
drm-misc-next and drm-intel-next have been merged to drm-next, and
drm-next has been backmerged to drm-misc-next and drm-intel-next.
It just might be a good idea to wait for those (as well as other driver
feature pulls) to settle, do a topic branch with a common ancestor
between drm-next and drm-misc-next, apply there, merge the topic branch
to drm-misc-next, and let all drivers merge the topic branch as
needed. Due to the timing, otherwise we might have to carry the
conflicts for quite a while.
BR,
Jani.
>
> Lyude Paul (20):
> drm/dp: Fixup kernel docs for struct drm_dp_aux
> drm/tegra: Don't register DP AUX channels before connectors
> drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace
> drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late
> register/early unregister
> drm/dp: Add backpointer to drm_device in drm_dp_aux
> drm/dp: Clarify DP AUX registration time
> drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()
> drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()
> drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()
> drm/dp: Always print aux channel name in logs
> drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect()
> drm/dp_dual_mode: Pass drm_device to
> drm_dp_dual_mode_set_tmds_output()
> drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock()
> drm/dp_dual_mode: Pass drm_device to
> drm_dp_dual_mode_get_tmds_output()
> drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode()
> drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()
> drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()
> drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using
> drm_err/drm_dbg_kms()
> drm/dp_mst: Drop DRM_ERROR() on kzalloc() fail in
> drm_dp_mst_handle_up_req()
> drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()
>
> drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 5 +-
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 +
> .../drm/bridge/analogix/analogix-anx6345.c| 1 +
> .../drm/bridge/analogix/analogix-anx78xx.c| 1 +
> .../drm/bridge/analogix/analogix_dp_core.c| 1 +
> .../drm/bridge/cadence/cdns-mhdp8546-core.c | 12 +-
> drivers/gpu/drm/bridge/tc358767.c | 1 +
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 +
> drivers/gpu/drm/drm_dp_aux_dev.c | 6 +
> drivers/gpu/drm/drm_dp_dual_mode_helper.c | 68 ++--
> drivers/gpu/drm/drm_dp_helper.c | 181 +
> drivers/gpu/drm/drm_dp_mst_topology.c | 381 +-
> drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 +
> .../drm/i915/display/intel_dp_link_training.c | 6 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +-
> drivers/gpu/drm/i915/display/intel_lspcon.c | 17 +-
> drivers/gpu/drm/msm/dp/dp_ctrl.c | 6 +-
> drivers/gpu/drm/msm/edp/edp.h | 3 +-
> drivers/gpu/drm/msm/edp/edp_aux.c | 5 +-
> drivers/gpu/drm/msm/edp/edp_ctrl.c| 8 +-
> drivers/gpu/drm/nouveau/nouveau_connector.c | 27 +-
> drivers/gpu/drm/
Re: [PATCH v6 3/5] drm/bridge: anx7625: add MIPI DPI input feature support
Hey Xin,
This patch looks good to me, feel free to add my r-b.
Reviewed-by: Robert Foss
On Fri, 19 Mar 2021 at 07:34, Xin Ji wrote:
>
> Add MIPI rx DPI input support.
>
> Reported-by: kernel test robot
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 245 --
> drivers/gpu/drm/bridge/analogix/anx7625.h | 18 +-
> 2 files changed, 203 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 04536cc7afe7..8c514b46d361 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -150,18 +150,18 @@ static int anx7625_write_and(struct anx7625_data *ctx,
> return anx7625_reg_write(ctx, client, offset, (val & (mask)));
> }
>
> -static int anx7625_write_and_or(struct anx7625_data *ctx,
> - struct i2c_client *client,
> - u8 offset, u8 and_mask, u8 or_mask)
> +static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
> {
> - int val;
> + int i, ret;
>
> - val = anx7625_reg_read(ctx, client, offset);
> - if (val < 0)
> - return val;
> + ret = anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
> + AUDIO_CONTROL_REGISTER, 0x80);
> + for (i = 0; i < 13; i++)
> + ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
> +VIDEO_BIT_MATRIX_12 + i,
> +0x18 + i);
>
> - return anx7625_reg_write(ctx, client,
> -offset, (val & and_mask) | (or_mask));
> + return ret;
> }
>
> static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
> @@ -219,38 +219,6 @@ static int anx7625_video_mute_control(struct
> anx7625_data *ctx,
> return ret;
> }
>
> -static int anx7625_config_audio_input(struct anx7625_data *ctx)
> -{
> - struct device *dev = &ctx->client->dev;
> - int ret;
> -
> - /* Channel num */
> - ret = anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_6, I2S_CH_2 << 5);
> -
> - /* FS */
> - ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_4,
> - 0xf0, AUDIO_FS_48K);
> - /* Word length */
> - ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_5,
> - 0xf0, AUDIO_W_LEN_24_24MAX);
> - /* I2S */
> - ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_6, I2S_SLAVE_MODE);
> - ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
> -AUDIO_CONTROL_REGISTER, ~TDM_TIMING_MODE);
> - /* Audio change flag */
> - ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
> - AP_AV_STATUS, AP_AUDIO_CHG);
> -
> - if (ret < 0)
> - DRM_DEV_ERROR(dev, "fail to config audio.\n");
> -
> - return ret;
> -}
> -
> /* Reduction of fraction a/b */
> static void anx7625_reduction_of_a_fraction(unsigned long *a, unsigned long
> *b)
> {
> @@ -410,7 +378,7 @@ static int anx7625_dsi_video_timing_config(struct
> anx7625_data *ctx)
> ret |= anx7625_write_and(ctx, ctx->i2c.rx_p1_client,
> MIPI_LANE_CTRL_0, 0xfc);
> ret |= anx7625_write_or(ctx, ctx->i2c.rx_p1_client,
> - MIPI_LANE_CTRL_0, 3);
> + MIPI_LANE_CTRL_0, ctx->pdata.mipi_lanes - 1);
>
> /* Htotal */
> htotal = ctx->dt.hactive.min + ctx->dt.hfront_porch.min +
> @@ -595,6 +563,76 @@ static int anx7625_dsi_config(struct anx7625_data *ctx)
> return ret;
> }
>
> +static int anx7625_api_dpi_config(struct anx7625_data *ctx)
> +{
> + struct device *dev = &ctx->client->dev;
> + u16 freq = ctx->dt.pixelclock.min / 1000;
> + int ret;
> +
> + /* configure pixel clock */
> + ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> + PIXEL_CLOCK_L, freq & 0xFF);
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +PIXEL_CLOCK_H, (freq >> 8));
> +
> + /* set DPI mode */
> + /* set to DPI PLL module sel */
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
> +MIPI_DIGITAL_PLL_9, 0x20);
> + /* power down MIPI */
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
> +MIPI_LANE_CTRL_10, 0x08);
> + /* enable DPI mode */
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
> +MIPI_DIGITAL_PLL_18, 0x1C);
> +
[PATCH] drm/ttm: optimize the pool shrinker a bit
Switch back to using a spinlock again by moving the IOMMU unmap outside
of the locked region.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 40 +++---
include/linux/shrinker.h | 1 +
mm/vmscan.c| 10 +
3 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index cb38b1a17b09..a8b4abe687ce 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -70,7 +70,7 @@ static struct ttm_pool_type global_uncached[MAX_ORDER];
static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
-static struct mutex shrinker_lock;
+static spinlock_t shrinker_lock;
static struct list_head shrinker_list;
static struct shrinker mm_shrinker;
@@ -263,9 +263,9 @@ static void ttm_pool_type_init(struct ttm_pool_type *pt,
struct ttm_pool *pool,
spin_lock_init(&pt->lock);
INIT_LIST_HEAD(&pt->pages);
- mutex_lock(&shrinker_lock);
+ spin_lock(&shrinker_lock);
list_add_tail(&pt->shrinker_list, &shrinker_list);
- mutex_unlock(&shrinker_lock);
+ spin_unlock(&shrinker_lock);
}
/* Remove a pool_type from the global shrinker list and free all pages */
@@ -273,9 +273,9 @@ static void ttm_pool_type_fini(struct ttm_pool_type *pt)
{
struct page *p;
- mutex_lock(&shrinker_lock);
+ spin_lock(&shrinker_lock);
list_del(&pt->shrinker_list);
- mutex_unlock(&shrinker_lock);
+ spin_unlock(&shrinker_lock);
while ((p = ttm_pool_type_take(pt)))
ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
@@ -313,24 +313,19 @@ static struct ttm_pool_type *ttm_pool_select_type(struct
ttm_pool *pool,
static unsigned int ttm_pool_shrink(void)
{
struct ttm_pool_type *pt;
- unsigned int num_freed;
struct page *p;
- mutex_lock(&shrinker_lock);
+ spin_lock(&shrinker_lock);
pt = list_first_entry(&shrinker_list, typeof(*pt), shrinker_list);
+ list_move_tail(&pt->shrinker_list, &shrinker_list);
+ spin_unlock(&shrinker_lock);
p = ttm_pool_type_take(pt);
- if (p) {
- ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
- num_freed = 1 << pt->order;
- } else {
- num_freed = 0;
- }
-
- list_move_tail(&pt->shrinker_list, &shrinker_list);
- mutex_unlock(&shrinker_lock);
+ if (!p)
+ return 0;
- return num_freed;
+ ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
+ return 1 << pt->order;
}
/* Return the allocation order based for a page */
@@ -530,6 +525,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
for (j = 0; j < MAX_ORDER; ++j)
ttm_pool_type_fini(&pool->caching[i].orders[j]);
}
+ sync_shrinkers();
}
/* As long as pages are available make sure to release at least one */
@@ -604,7 +600,7 @@ static int ttm_pool_debugfs_globals_show(struct seq_file
*m, void *data)
{
ttm_pool_debugfs_header(m);
- mutex_lock(&shrinker_lock);
+ spin_lock(&shrinker_lock);
seq_puts(m, "wc\t:");
ttm_pool_debugfs_orders(global_write_combined, m);
seq_puts(m, "uc\t:");
@@ -613,7 +609,7 @@ static int ttm_pool_debugfs_globals_show(struct seq_file
*m, void *data)
ttm_pool_debugfs_orders(global_dma32_write_combined, m);
seq_puts(m, "uc 32\t:");
ttm_pool_debugfs_orders(global_dma32_uncached, m);
- mutex_unlock(&shrinker_lock);
+ spin_unlock(&shrinker_lock);
ttm_pool_debugfs_footer(m);
@@ -640,7 +636,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct seq_file
*m)
ttm_pool_debugfs_header(m);
- mutex_lock(&shrinker_lock);
+ spin_lock(&shrinker_lock);
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
seq_puts(m, "DMA ");
switch (i) {
@@ -656,7 +652,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct seq_file
*m)
}
ttm_pool_debugfs_orders(pool->caching[i].orders, m);
}
- mutex_unlock(&shrinker_lock);
+ spin_unlock(&shrinker_lock);
ttm_pool_debugfs_footer(m);
return 0;
@@ -693,7 +689,7 @@ int ttm_pool_mgr_init(unsigned long num_pages)
if (!page_pool_size)
page_pool_size = num_pages;
- mutex_init(&shrinker_lock);
+ spin_lock_init(&shrinker_lock);
INIT_LIST_HEAD(&shrinker_list);
for (i = 0; i < MAX_ORDER; ++i) {
diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
index 0f80123650e2..6b75dc372fce 100644
--- a/include/linux/shrinker.h
+++ b/include/linux/shrinker.h
@@ -92,4 +92,5 @@ extern void register_shrinker_prepared(struct shrinker
*shrinker);
extern int register_sh
Re: [PATCH v6 5/5] drm/bridge: anx7625: add HDMI audio function
Hey Xin,
This patch looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Mar 2021 at 07:35, Xin Ji wrote:
>
> Add audio HDMI codec function support, enable it through device true flag
> "analogix,audio-enable".
>
> Reported-by: kernel test robot
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 227 ++
> drivers/gpu/drm/bridge/analogix/anx7625.h | 5 +
> 2 files changed, 232 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index b424a570effa..02bb169d9c57 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -30,6 +30,8 @@
> #include
> #include
>
> +#include
> +
> #include
>
> #include "anx7625.h"
> @@ -150,6 +152,20 @@ static int anx7625_write_and(struct anx7625_data *ctx,
> return anx7625_reg_write(ctx, client, offset, (val & (mask)));
> }
>
> +static int anx7625_write_and_or(struct anx7625_data *ctx,
> + struct i2c_client *client,
> + u8 offset, u8 and_mask, u8 or_mask)
> +{
> + int val;
> +
> + val = anx7625_reg_read(ctx, client, offset);
> + if (val < 0)
> + return val;
> +
> + return anx7625_reg_write(ctx, client,
> +offset, (val & and_mask) | (or_mask));
> +}
> +
> static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
> {
> int i, ret;
> @@ -1498,6 +1514,9 @@ static int anx7625_parse_dt(struct device *dev,
> else
> DRM_DEV_DEBUG_DRIVER(dev, "found MIPI DSI host node.\n");
>
> + if (of_property_read_bool(np, "analogix,audio-enable"))
> + pdata->audio_en = 1;
> +
> ret = drm_of_find_panel_or_bridge(np, 1, 0, &panel, NULL);
> if (ret < 0) {
> if (ret == -ENODEV)
> @@ -1568,6 +1587,208 @@ static enum drm_connector_status
> anx7625_sink_detect(struct anx7625_data *ctx)
> connector_status_disconnected;
> }
>
> +static int anx7625_audio_hw_params(struct device *dev, void *data,
> + struct hdmi_codec_daifmt *fmt,
> + struct hdmi_codec_params *params)
> +{
> + struct anx7625_data *ctx = dev_get_drvdata(dev);
> + int wl, ch, rate;
> + int ret = 0;
> +
> + if (fmt->fmt != HDMI_DSP_A) {
> + DRM_DEV_ERROR(dev, "only supports DSP_A\n");
> + return -EINVAL;
> + }
> +
> + DRM_DEV_DEBUG_DRIVER(dev, "setting %d Hz, %d bit, %d channels\n",
> +params->sample_rate, params->sample_width,
> +params->cea.channels);
> +
> + ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> + AUDIO_CHANNEL_STATUS_6,
> + ~I2S_SLAVE_MODE,
> + TDM_SLAVE_MODE);
> +
> + /* Word length */
> + switch (params->sample_width) {
> + case 16:
> + wl = AUDIO_W_LEN_16_20MAX;
> + break;
> + case 18:
> + wl = AUDIO_W_LEN_18_20MAX;
> + break;
> + case 20:
> + wl = AUDIO_W_LEN_20_20MAX;
> + break;
> + case 24:
> + wl = AUDIO_W_LEN_24_24MAX;
> + break;
> + default:
> + DRM_DEV_DEBUG_DRIVER(dev, "wordlength: %d bit not support",
> +params->sample_width);
> + return -EINVAL;
> + }
> + ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> + AUDIO_CHANNEL_STATUS_5,
> + 0xf0, wl);
> +
> + /* Channel num */
> + switch (params->cea.channels) {
> + case 2:
> + ch = I2S_CH_2;
> + break;
> + case 4:
> + ch = TDM_CH_4;
> + break;
> + case 6:
> + ch = TDM_CH_6;
> + break;
> + case 8:
> + ch = TDM_CH_8;
> + break;
> + default:
> + DRM_DEV_DEBUG_DRIVER(dev, "channel number: %d not support",
> +params->cea.channels);
> + return -EINVAL;
> + }
> + ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> + AUDIO_CHANNEL_STATUS_6, 0x1f, ch << 5);
> + if (ch > I2S_CH_2)
> + ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
> + AUDIO_CHANNEL_STATUS_6, AUDIO_LAYOUT);
> + else
> + ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
> + AUDIO_CHANNEL_STATUS_6, ~AUDIO_LAYOUT);
> +
> + /* FS */
> + switch (params->sample_rate) {
> + case 32000:
> +
re: drm/i915/selftests: Prepare gtt tests for obj->mm.lock removal
Hi,
Static analysis with Coverity on Linux-next has detected a potential
issue with the following commit:
commit 480ae79537b28f30ef6e07b7de69a9ae2599daa7
Author: Maarten Lankhorst
Date: Tue Mar 23 16:50:49 2021 +0100
drm/i915/selftests: Prepare gtt tests for obj->mm.lock removal
The analysis by Coverity is as follows:
145 static int igt_ppgtt_alloc(void *arg)
146 {
147struct drm_i915_private *dev_priv = arg;
148struct i915_ppgtt *ppgtt;
1. var_decl: Declaring variable ww without initializer.
149struct i915_gem_ww_ctx ww;
150u64 size, last, limit;
151int err = 0;
152
153/* Allocate a ppggt and try to fill the entire range */
154
2. Condition !(dev_priv->__info.ppgtt_type != INTEL_PPGTT_NONE),
taking false branch.
155if (!HAS_PPGTT(dev_priv))
156return 0;
157
158ppgtt = i915_ppgtt_create(&dev_priv->gt);
3. Condition IS_ERR(ppgtt), taking false branch.
159if (IS_ERR(ppgtt))
160return PTR_ERR(ppgtt);
161
4. Condition !ppgtt->vm.allocate_va_range, taking true branch.
162if (!ppgtt->vm.allocate_va_range)
5. Jumping to label err_ppgtt_cleanup.
163goto err_ppgtt_cleanup;
164
165/*
166 * While we only allocate the page tables here and so we could
167 * address a much larger GTT than we could actually fit into
168 * RAM, a practical limit is the amount of physical pages in
the system.
169 * This should ensure that we do not run into the oomkiller
during
170 * the test and take down the machine wilfully.
171 */
172limit = totalram_pages() << PAGE_SHIFT;
173limit = min(ppgtt->vm.total, limit);
174
175i915_gem_ww_ctx_init(&ww, false);
176retry:
177err = i915_vm_lock_objects(&ppgtt->vm, &ww);
178if (err)
179goto err_ppgtt_cleanup;
180
181/* Check we can allocate the entire range */
182for (size = 4096; size <= limit; size <<= 2) {
183struct i915_vm_pt_stash stash = {};
184
185err = i915_vm_alloc_pt_stash(&ppgtt->vm, &stash, size);
186if (err)
187goto err_ppgtt_cleanup;
188
189err = i915_vm_pin_pt_stash(&ppgtt->vm, &stash);
190if (err) {
191i915_vm_free_pt_stash(&ppgtt->vm, &stash);
192goto err_ppgtt_cleanup;
193}
194
195ppgtt->vm.allocate_va_range(&ppgtt->vm, &stash, 0, size);
196cond_resched();
197
198ppgtt->vm.clear_range(&ppgtt->vm, 0, size);
199
200i915_vm_free_pt_stash(&ppgtt->vm, &stash);
201}
202
203/* Check we can incrementally allocate the entire range */
204for (last = 0, size = 4096; size <= limit; last = size, size
<<= 2) {
205struct i915_vm_pt_stash stash = {};
206
207err = i915_vm_alloc_pt_stash(&ppgtt->vm, &stash, size
- last);
208if (err)
209goto err_ppgtt_cleanup;
210
211err = i915_vm_pin_pt_stash(&ppgtt->vm, &stash);
212if (err) {
213i915_vm_free_pt_stash(&ppgtt->vm, &stash);
214goto err_ppgtt_cleanup;
215}
216
217ppgtt->vm.allocate_va_range(&ppgtt->vm, &stash,
218last, size - last);
219cond_resched();
220
221i915_vm_free_pt_stash(&ppgtt->vm, &stash);
222}
223
224 err_ppgtt_cleanup:
6. Condition err == -35, taking false branch.
225if (err == -EDEADLK) {
226err = i915_gem_ww_ctx_backoff(&ww);
227if (!err)
228goto retry;
229}
7. uninit_use_in_call: Using uninitialized value ww.contended when
calling i915_gem_ww_ctx_fini.
Uninitialized pointer read (UNINIT)
8. uninit_use_in_call: Using uninitialized value ww.ctx.acquired when
calling i915_gem_ww_ctx_fini.
230i915_gem_ww_ctx_fini(&ww);
231
232i915_vm_put(&ppgtt->vm);
233return err;
234 }
Coverity is reporting use of uninitialized values in (lines 230. Not
sure what the best fix is for this, so I'm reporting this as a potential
issue.
Colin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/2] drm/mediatek: Don't support hdmi connector creation
Hi, Dafna:
Dafna Hirschfeld 於 2021年3月30日 週二 下午7:09寫道：
>
> commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
> broke the display support for elm device since mtk_dpi calls
> drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
> while mtk_hdmi does not yet support this flag.
For this series, applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> These three patches fix that by adding support for
> DRM_BRIDGE_ATTACH_NO_CONNECTOR
> in mtk_hdmi bridge attachment.
>
> changes since v2:
> 1. squash patch 3 with patch 2 to not break bisection
> 2. remove the funtion mtk_hdmi_get_edid and inline its code in
> mtk_hdmi_bridge_get_edid
> 3. small aligment
>
> changes since v1:
> 1. split the first patch - now the first patch only moves the bridge ops to
> the atomic API
> while the replacement of the field 'conn' with the field '*curr_conn' is done
> in a new third patch.
> 2. in the function 'get_eld' use the current conn only if 'enabled = true'.
>
> Dafna Hirschfeld (2):
> drm/mediatek: Switch the hdmi bridge ops to the atomic versions
> drm/mediatek: Don't support hdmi connector creation
>
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 174
> 1 file changed, 71 insertions(+), 103 deletions(-)
>
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers: gpu: drm: bridge: fix kconfig dependency on DRM_KMS_HELPER
Hey Julian, Nice catch, this patch looks good to me. I've pushed it to drm-misc-next. https://cgit.freedesktop.org/drm/drm-misc/commit/?id=62066d3164467167fc27b2383f67d097e39bf176 On Mon, 22 Feb 2021 at 22:56, Julian Braha wrote: > > When DRM_TOSHIBA_TC358762 is enabled and DRM_KMS_HELPER is disabled, > Kbuild gives the following warning: > > WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE > Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n] > Selected by [y]: > - DRM_TOSHIBA_TC358762 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE > [=y] && OF [=y] > > This is because DRM_TOSHIBA_TC358762 selects DRM_PANEL_BRIDGE, > without depending on or selecting DRM_KMS_HELPER, > despite that config option depending on DRM_KMS_HELPER. > > Signed-off-by: Julian Braha > --- > drivers/gpu/drm/bridge/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index e4110d6ca7b3..909d0a5643c2 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -183,6 +183,7 @@ config DRM_TOSHIBA_TC358762 > tristate "TC358762 DSI/DPI bridge" > depends on OF > select DRM_MIPI_DSI > + select DRM_KMS_HELPER > select DRM_PANEL_BRIDGE > help > Toshiba TC358762 DSI/DPI bridge driver. > -- > 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/14] drm/bridge: ti-sn65dsi86: Power things properly for reading the EDID
Hi,
On Thu, Apr 1, 2021 at 4:12 AM Andrzej Hajda wrote:
>
>
> W dniu 31.03.2021 o 16:48, Doug Anderson pisze:
> > Hi,
> >
> > On Wed, Mar 31, 2021 at 4:08 AM Andrzej Hajda wrote:
> >>
> >> W dniu 30.03.2021 o 04:53, Douglas Anderson pisze:
> >>> eDP panels won't provide their EDID unless they're powered on. Let's
> >>> chain a power-on before we read the EDID. This roughly matches what
> >>> was done in 'parade-ps8640.c'.
> >>>
> >>> NOTE: The old code attempted to call pm_runtime_get_sync() before
> >>> reading the EDID. While that was enough to power the bridge chip on,
> >>> it wasn't enough to talk to the panel for two reasons:
> >>> 1. Since we never ran the bridge chip's pre-enable then we never set
> >>> the bit to ignore HPD. This meant the bridge chip didn't even _try_
> >>> to go out on the bus and communicate with the panel.
> >>> 2. Even if we fixed things to ignore HPD, the EDID still wouldn't read
> >>> if the panel wasn't on.
> >>>
> >>> One thing that's a bit odd here is taking advantage of the EDID that
> >>> the core might have cached for us. See the patch ("drm/edid: Use the
> >>> cached EDID in drm_get_edid() if eDP"). We manage to get at the cache
> >>> by:
> >>> - Instantly failing aux transfers if we're not powered.
> >>> - If the first read of the EDID fails we try again after powering.
> >>>
> >>> Fixes: 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC")
> >>> Signed-off-by: Douglas Anderson
> >>> ---
> >>> Depending on what people think of the other patches in this series,
> >>> some of this could change.
> >>> - If everyone loves the "runtime PM" in the panel driver then we
> >>> could, in theory, put the pre-enable chaining straight in the "aux
> >>> transfer" function.
> >>> - If everyone hates the EDID cache moving to the core then we can
> >>> avoid some of the awkward flow of things and keep the EDID cache in
> >>> the sn65dsi86 driver.
> >>
> >> I wonder if this shouldn't be solved in the core - ie caller of
> >> get_modes callback should be responsible for powering up the pipeline,
> >> otherwise we need to repeat this stuff in every bridge/panel driver.
> >>
> >> Any thoughts?
> > Yeah, I did look at this a little bit. Presumably it would only make
> > sense to do it for eDP connections since:
> >
> > a) The concept of reading an EDID doesn't make sense for things like MIPI.
>
> I guess you mean MIPI DSI
Yes, sorry! I'll try to be more clear.
> and yes I agree, more generally it usually(!)
> doesn't make sense for any setup with fixed display panel.
>
> On the other hand there are DSI/HDMI or DSI/DP adapters which usually
> have EDID reading logic.
>
> And the concept makes sense for most connectors accepting external
> displays: HDMI, DP, MHL, VGA...
So, actually, IMO the concept doesn't make sense for anything with an
external connector. Here's the logic for a handful of connectors:
1. MIPI DSI: there is no EDID so this doesn't make sense.
2. An external connector (HDMI, DP, etc): the display that's plugged
in is externally powered so doesn't need us to power it up to read the
EDID. By definition, when the HPD signal is asserted then it's OK to
read the EDID and we don't even know if a display is plugged in until
HPD is asserted. Thus no special power sequencing is needed to read
the EDID. (Yes, we need to make sure that the eDP controller itself
is powered, but that doesn't seem like it's the core's business).
3. eDP: this is where it matters. This is because:
3a) eDP displays aren't powered all the time. If you just boot up or
you blank your screen, likely the display has no power at all.
3b) Because the display has no power, the "HPD" signal doesn't assert.
In fact, for eDP the "HPD" signal really should mean "display ready"
or "display finished powering up".
3c) Even though we never get a HPD signal, we still simply assume that
a display is present because this is an "embedded" device.
So eDP is unique (as far as I know) in that it's a type of display
that has an EDID but that we will report "a display is here" before
we've powered up the display and before we can read the EDID.
> > b) For something with an external connector (DP and HDMI) you don't
> > even know they're inserted unless the EDID is ready to read (these
> > devices are, essentially, always powered).
>
> Usually there are two elements which are not the same:
>
> 1. HotPlug signal/wire.
>
> 2. EDID reading logic.
>
> The logic responsible for reading EDID needs to be enabled only for time
> required for EDID reading :) So it's power state often must be
> controlled explicitly by the bridge driver. So even if in many cases
> pre_enable powers on the logic for EDID reading it does not make it the
> rule, so I must step back from my claim that it is up to caller :)
OK, I'll plan to keep it in the bridge chip driver now.
> > So I started off trying to do this in the core for eDP, but then it
> > wasn't completely clear how to write this co
Re: [PATCH 10/34] drm/amdkfd: svm range eviction and restore
Hi Felix,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20210331]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
drm/drm-next v5.12-rc5 v5.12-rc4 v5.12-rc3 v5.12-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
base:7a43c78d0573e00456b033e2b9a895b89464
config: x86_64-randconfig-a011-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/07dfb6a9dad338dae38a3a840ce14f77e7498b1f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
git checkout 07dfb6a9dad338dae38a3a840ce14f77e7498b1f
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:170:6: warning: no previous
prototype for 'svm_range_dma_unmap' [-Wmissing-prototypes]
170 | void svm_range_dma_unmap(struct device *dev, dma_addr_t *dma_addr,
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:603:6: warning: no previous
prototype for 'svm_range_add_child' [-Wmissing-prototypes]
603 | void svm_range_add_child(struct svm_range *prange, struct mm_struct
*mm,
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:799:5: warning: no previous
prototype for 'svm_range_reserve_bos' [-Wmissing-prototypes]
799 | int svm_range_reserve_bos(struct svm_validate_context *ctx)
| ^
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:853:6: warning: no previous
prototype for 'svm_range_unreserve_bos' [-Wmissing-prototypes]
853 | void svm_range_unreserve_bos(struct svm_validate_context *ctx)
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c: In function
'svm_range_evict':
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:1071:6: warning: variable
>> 'invalid' set but not used [-Wunused-but-set-variable]
1071 | int invalid, evicted_ranges;
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c: At top level:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:1094:19: warning: no previous
prototype for 'svm_range_clone' [-Wmissing-prototypes]
1094 | struct svm_range *svm_range_clone(struct svm_range *old)
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:1349:1: warning: no previous
prototype for 'svm_range_add_list_work' [-Wmissing-prototypes]
1349 | svm_range_add_list_work(struct svm_range_list *svms, struct
svm_range *prange,
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:1371:6: warning: no previous
prototype for 'schedule_deferred_list_work' [-Wmissing-prototypes]
1371 | void schedule_deferred_list_work(struct svm_range_list *svms)
| ^~~
vim +/invalid +1071 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c
1054
1055 /**
1056 * svm_range_evict - evict svm range
1057 *
1058 * Stop all queues of the process to ensure GPU doesn't access the
memory, then
1059 * return to let CPU evict the buffer and proceed CPU pagetable update.
1060 *
1061 * Don't need use lock to sync cpu pagetable invalidation with GPU
execution.
1062 * If invalidation happens while restore work is running, restore work
will
1063 * restart to ensure to get the latest CPU pages mapping to GPU, then
start
1064 * the queues.
1065 */
1066 static int
1067 svm_range_evict(struct svm_range *prange, struct mm_struct *mm,
1068 unsigned long start, unsigned long last)
1069 {
1070 struct svm_range_list *svms = prange->svms;
> 1071 int invalid, evicted_ranges;
1072 int r = 0;
1073
1074 invalid = atomic_inc_return(&prange->invalid);
1075 evicted_ranges = atomic_inc_return(&svms->evicted_ranges);
1076 if (evicted_ranges != 1)
1077 return r;
1078
1079 pr_debug("evicting svms 0x%p range [0x%lx 0x%lx]\n",
1080 prange->svms, prange->start, prange->last);
1081
1082 /* First evict
Re: [PATCH] drm/sched: add missing member documentation
On Thu, Apr 1, 2021 at 8:52 AM Christian König
wrote:
>
> Just fix a warning.
>
> Signed-off-by: Christian König
> Reported-by: Stephen Rothwell
> Fixes: f2f12eb9c32b ("drm/scheduler: provide scheduler score externally")
Reviewed-by: Alex Deucher
> ---
> include/drm/gpu_scheduler.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 1c815e0a14ed..f888b5e9583a 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -277,6 +277,7 @@ struct drm_sched_backend_ops {
> * @hang_limit: once the hangs by a job crosses this limit then it is marked
> * guilty and it will be considered for scheduling further.
> * @score: score to help loadbalancer pick a idle sched
> + * @_score: score used when the driver doesn't provide one
> * @ready: marks if the underlying HW is ready to work
> * @free_guilty: A hit to time out handler to free the guilty job.
> *
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/msm: Remove unused freed llist node
Hi,
On Wed, Mar 31, 2021 at 6:23 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Unused since commit c951a9b284b9 ("drm/msm: Remove msm_gem_free_work")
>
> Signed-off-by: Rob Clark
> Tested-by: Douglas Anderson
> ---
> drivers/gpu/drm/msm/msm_gem.h | 2 --
> 1 file changed, 2 deletions(-)
Reviewed-by: Douglas Anderson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/msm: Avoid mutex in shrinker_count()
Hi,
On Wed, Mar 31, 2021 at 6:24 PM Rob Clark wrote:
>
> @@ -45,6 +30,9 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
> shrink_control *sc)
> list_for_each_entry(msm_obj, &priv->inactive_dontneed, mm_list) {
> if (freed >= sc->nr_to_scan)
> break;
> + /* Use trylock, because we cannot block on a obj that
> +* might be trying to acquire mm_lock
> +*/
nit: I thought the above multi-line commenting style was only for
"net" subsystem?
> if (!msm_gem_trylock(&msm_obj->base))
> continue;
> if (is_purgeable(msm_obj)) {
> @@ -56,8 +44,11 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
> shrink_control *sc)
>
> mutex_unlock(&priv->mm_lock);
>
> - if (freed > 0)
> + if (freed > 0) {
> trace_msm_gem_purge(freed << PAGE_SHIFT);
> + } else {
> + return SHRINK_STOP;
> + }
It probably doesn't matter, but I wonder if we should still be
returning SHRINK_STOP if we got any trylock failures. It could
possibly be worth returning 0 in that case?
> @@ -75,6 +66,9 @@ vmap_shrink(struct list_head *mm_list)
> unsigned unmapped = 0;
>
> list_for_each_entry(msm_obj, mm_list, mm_list) {
> + /* Use trylock, because we cannot block on a obj that
> +* might be trying to acquire mm_lock
> +*/
If you end up changing the commenting style above, should also be here.
At this point this seems fine to land to me. Though I'm not an expert
on every interaction in this code, I've spent enough time starting at
it that I'm comfortable with:
Reviewed-by: Douglas Anderson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/msm: Fix debugfs deadlock
Hi,
On Wed, Mar 31, 2021 at 6:24 PM Rob Clark wrote:
>
> From: Rob Clark
>
> In normal cases the gem obj lock is acquired first before mm_lock. The
> exception is iterating the various object lists. In the shrinker path,
> deadlock is avoided by using msm_gem_trylock() and skipping over objects
> that cannot be locked. But for debugfs the straightforward thing is to
> split things out into a separate list of all objects protected by it's
> own lock.
>
> Fixes: d984457b31c4 ("drm/msm: Add priv->mm_lock to protect active/inactive
> lists")
> Signed-off-by: Rob Clark
> Tested-by: Douglas Anderson
Reviewed-by: Douglas Anderson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] gpu: host1x: Split up client initalization and registration
From: Thierry Reding
In some cases we may need to initialize the host1x client first before
registering it. This commit adds a new helper that will do nothing but
the initialization of the data structure.
At the same time, the initialization is removed from the registration
function. Note, however, that for simplicity we explicitly initialize
the client when the host1x_client_register() function is called, as
opposed to the low-level __host1x_client_register() function. This
allows existing callers to remain unchanged.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/bus.c | 30 --
include/linux/host1x.h | 30 --
2 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 46f69c532b6b..218e3718fd68 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -735,6 +735,29 @@ void host1x_driver_unregister(struct host1x_driver *driver)
}
EXPORT_SYMBOL(host1x_driver_unregister);
+/**
+ * __host1x_client_init() - initialize a host1x client
+ * @client: host1x client
+ * @key: lock class key for the client-specific mutex
+ */
+void __host1x_client_init(struct host1x_client *client, struct lock_class_key
*key)
+{
+ INIT_LIST_HEAD(&client->list);
+ __mutex_init(&client->lock, "host1x client lock", key);
+ client->usecount = 0;
+}
+EXPORT_SYMBOL(__host1x_client_init);
+
+/**
+ * host1x_client_exit() - uninitialize a host1x client
+ * @client: host1x client
+ */
+void host1x_client_exit(struct host1x_client *client)
+{
+ mutex_destroy(&client->lock);
+}
+EXPORT_SYMBOL(host1x_client_exit);
+
/**
* __host1x_client_register() - register a host1x client
* @client: host1x client
@@ -747,16 +770,11 @@ EXPORT_SYMBOL(host1x_driver_unregister);
* device and call host1x_device_init(), which will in turn call each client's
* &host1x_client_ops.init implementation.
*/
-int __host1x_client_register(struct host1x_client *client,
-struct lock_class_key *key)
+int __host1x_client_register(struct host1x_client *client)
{
struct host1x *host1x;
int err;
- INIT_LIST_HEAD(&client->list);
- __mutex_init(&client->lock, "host1x client lock", key);
- client->usecount = 0;
-
mutex_lock(&devices_lock);
list_for_each_entry(host1x, &devices, list) {
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index ef13bc69b493..7310ce9c70e0 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -349,12 +349,30 @@ static inline struct host1x_device
*to_host1x_device(struct device *dev)
int host1x_device_init(struct host1x_device *device);
int host1x_device_exit(struct host1x_device *device);
-int __host1x_client_register(struct host1x_client *client,
-struct lock_class_key *key);
-#define host1x_client_register(class) \
- ({ \
- static struct lock_class_key __key; \
- __host1x_client_register(class, &__key); \
+void __host1x_client_init(struct host1x_client *client, struct lock_class_key
*key);
+void host1x_client_exit(struct host1x_client *client);
+
+#define host1x_client_init(client) \
+ ({ \
+ static struct lock_class_key __key; \
+ __host1x_client_init(client, &__key); \
+ })
+
+int __host1x_client_register(struct host1x_client *client);
+
+/*
+ * Note that this wrapper calls __host1x_client_init() for compatibility
+ * with existing callers. Callers that want to separately initialize and
+ * register a host1x client must first initialize using either of the
+ * __host1x_client_init() or host1x_client_init() functions and then use
+ * the low-level __host1x_client_register() function to avoid the client
+ * getting reinitialized.
+ */
+#define host1x_client_register(client) \
+ ({ \
+ static struct lock_class_key __key; \
+ __host1x_client_init(client, &__key); \
+ __host1x_client_register(client); \
})
int host1x_client_unregister(struct host1x_client *client);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/tegra: sor: Fully initialize SOR before registration
From: Thierry Reding
Before registering the SOR host1x client, make sure that it is fully
initialized. This avoids a potential race condition between the SOR's
probe and the host1x device initialization in cases where the SOR is
the final sub-device to register to a host1x instance.
Reported-by: Jonathan Hunter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 7b88261f57bb..b29bc10a0a4d 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -3916,17 +3916,10 @@ static int tegra_sor_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, sor);
pm_runtime_enable(&pdev->dev);
- INIT_LIST_HEAD(&sor->client.list);
+ host1x_client_init(&sor->client);
sor->client.ops = &sor_client_ops;
sor->client.dev = &pdev->dev;
- err = host1x_client_register(&sor->client);
- if (err < 0) {
- dev_err(&pdev->dev, "failed to register host1x client: %d\n",
- err);
- goto rpm_disable;
- }
-
/*
* On Tegra210 and earlier, provide our own implementation for the
* pad output clock.
@@ -3938,13 +3931,13 @@ static int tegra_sor_probe(struct platform_device *pdev)
sor->index);
if (!name) {
err = -ENOMEM;
- goto unregister;
+ goto uninit;
}
err = host1x_client_resume(&sor->client);
if (err < 0) {
dev_err(sor->dev, "failed to resume: %d\n", err);
- goto unregister;
+ goto uninit;
}
sor->clk_pad = tegra_clk_sor_pad_register(sor, name);
@@ -3955,14 +3948,20 @@ static int tegra_sor_probe(struct platform_device *pdev)
err = PTR_ERR(sor->clk_pad);
dev_err(sor->dev, "failed to register SOR pad clock: %d\n",
err);
- goto unregister;
+ goto uninit;
+ }
+
+ err = __host1x_client_register(&sor->client);
+ if (err < 0) {
+ dev_err(&pdev->dev, "failed to register host1x client: %d\n",
+ err);
+ goto uninit;
}
return 0;
-unregister:
- host1x_client_unregister(&sor->client);
-rpm_disable:
+uninit:
+ host1x_client_exit(&sor->client);
pm_runtime_disable(&pdev->dev);
remove:
tegra_output_remove(&sor->output);
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 07/14] dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module binding
On Thu, Apr 1, 2021 at 4:18 AM Liu Ying wrote: > > On Wed, 2021-03-31 at 08:40 -0500, Rob Herring wrote: > > On Wed, 31 Mar 2021 14:33:18 +0800, Liu Ying wrote: > > > This patch adds bindings for i.MX8qm/qxp Control and Status Registers > > > module. > > > > > > Reviewed-by: Rob Herring > > > Signed-off-by: Liu Ying > > > --- > > > v6->v7: > > > * Add Rob's R-b tag. > > > > > > v5->v6: > > > * Drop 'select' schema. (Rob) > > > > > > v4->v5: > > > * Newly introduced in v5. (Rob) > > > > > > .../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml | 192 > > > + > > > 1 file changed, 192 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > yamllint warnings/errors: > > > > dtschema/dtc warnings/errors: > > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: > > /example-0/syscon@56221000/pxl2dpi: failed to match any schema with > > compatible: ['fsl,imx8qxp-pxl2dpi'] > > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: > > /example-0/syscon@56221000/ldb: failed to match any schema with compatible: > > ['fsl,imx8qxp-ldb'] > > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: > > /example-0/phy@56228300: failed to match any schema with compatible: > > ['fsl,imx8qxp-mipi-dphy'] > > > > Sorry for the errors. > But, my patch passes 'make dt_binding_check' locally upon > v5.12-rc1-dontuse at least. > My yamllint and dt-schema are up to date. > > Does your bot _additionally_ check all compatibles in example? > I guess I missed something? Yes, it now adds 'DT_CHECKER_FLAGS=-m' which is new and pending in linux-next. It's off by default until we get rid of the ~90 existing cases. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] dt-bindings: display: sitronix, st7789v-dbi: Add Waveshare 2inch LCD module
On Wed, 31 Mar 2021 03:05:50 +, Carlis wrote: > From: Xuezhi Zhang > > Document support for the Waveshare 2inch LCD module display, which is a > 240x320 2" TFT display driven by a Sitronix ST7789V TFT Controller. > > Signed-off-by: Xuezhi Zhang > --- > v2:change compatible value. > v3:change author name. > v4:delete a maintainer. > --- > .../display/sitronix,st7789v-dbi.yaml | 72 +++ > 1 file changed, 72 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/sitronix,st7789v-dbi.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] dt-bindings: display: add bindings for newhaven, 1.8-128160EF
On Wed, 31 Mar 2021 11:21:13 +0200, Daniel Mack wrote: > This adds documentation for a new ILI9163 based, SPI connected display. > > Signed-off-by: Daniel Mack > --- > .../display/panel/ilitek,ili9163.yaml | 69 +++ > 1 file changed, 69 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/tegra: Fixes for v5.12-rc6
Hi Dave, The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.12-rc6 for you to fetch changes up to ac097aecfef0bb289ca53d2fe0b73fc7e1612a05: drm/tegra: sor: Grab runtime PM reference across reset (2021-03-30 19:51:39 +0200) Thanks, Thierry drm/tegra: Fixes for v5.12-rc6 This contains a couple of fixes for various issues such as lockdep warnings, runtime PM references, coupled display controllers and misconfigured PLLs. Dmitry Osipenko (1): drm/tegra: dc: Don't set PLL clock to 0Hz Mikko Perttunen (1): gpu: host1x: Use different lock classes for each client Thierry Reding (2): drm/tegra: dc: Restore coupling of display controllers drm/tegra: sor: Grab runtime PM reference across reset drivers/gpu/drm/tegra/dc.c | 30 +- drivers/gpu/drm/tegra/sor.c | 7 +++ drivers/gpu/host1x/bus.c| 10 ++ include/linux/host1x.h | 9 - 4 files changed, 34 insertions(+), 22 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/tegra: Changes for v5.13-rc1
Hi Dave, The following changes since commit 51c3b916a4d7e24b4918925965867fdd9bd8dd59: Merge tag 'drm-misc-next-2021-03-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2021-03-16 17:08:46 +1000) are available in the Git repository at: ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.13-rc1 for you to fetch changes up to 7b6f846785f41d57917e36851c120cfbe87f0809: drm/tegra: Support sector layout on Tegra194 (2021-03-31 17:42:14 +0200) Note that I've based this on your pull of drm-misc-next-2021-03-03 and the drm/tegra/for-5.12-rc6 fixes branch that I just sent out a PR for because otherwise there would've been a bunch of non-trivial conflicts. The shortlog below includes everything from drm/tegra/for-5.12-rc6 for clarity. Thierry drm/tegra: Changes for v5.13-rc1 The changes this time around contain a couple of fixes for host1x along with some improvements for Tegra DRM. Most notably the Tegra DRM driver now supports the hardware cursor on Tegra186 and later, more correctly reflects the capabilities of the display pipelines on various Tegra SoC generations and knows how to deal with the dGPU sector layout by using framebuffer modifiers. Dmitry Osipenko (1): drm/tegra: dc: Don't set PLL clock to 0Hz Jon Hunter (1): gpu: host1x: Fix Tegra194 syncpt interrupt threshold Mikko Perttunen (9): gpu: host1x: Use different lock classes for each client gpu: host1x: Allow syncpoints without associated client gpu: host1x: Show number of pending waiters in debugfs gpu: host1x: Remove cancelled waiters immediately gpu: host1x: Use HW-equivalent syncpoint expiration check gpu: host1x: Cleanup and refcounting for syncpoints gpu: host1x: Reset max value when freeing a syncpoint gpu: host1x: Reserve VBLANK syncpoints at initialization gpu: host1x: Assign intr waiter inside lock Thierry Reding (11): drm/tegra: dc: Restore coupling of display controllers drm/tegra: sor: Grab runtime PM reference across reset Merge branch 'drm/tegra/fixes' into drm/tegra/for-next gpu: host1x: Add early init and late exit callbacks drm/tegra: dc: Inherit DMA mask drm/tegra: dc: Parameterize maximum resolution drm/tegra: dc: Implement hardware cursor on Tegra186 and later drm/tegra: fb: Add diagnostics for framebuffer modifiers drm/tegra: gem: Add a clarifying comment drm/tegra: Count number of display controllers at runtime drm/tegra: Support sector layout on Tegra194 drivers/gpu/drm/tegra/dc.c | 143 ++- drivers/gpu/drm/tegra/dc.h | 6 + drivers/gpu/drm/tegra/drm.c| 27 +++-- drivers/gpu/drm/tegra/drm.h| 5 + drivers/gpu/drm/tegra/fb.c | 10 ++ drivers/gpu/drm/tegra/gem.h| 6 + drivers/gpu/drm/tegra/gr2d.c | 4 +- drivers/gpu/drm/tegra/gr3d.c | 4 +- drivers/gpu/drm/tegra/hub.c| 41 ++- drivers/gpu/drm/tegra/plane.c | 32 ++ drivers/gpu/drm/tegra/sor.c| 7 ++ drivers/gpu/drm/tegra/vic.c| 4 +- drivers/gpu/host1x/bus.c | 41 ++- drivers/gpu/host1x/cdma.c | 11 +- drivers/gpu/host1x/debug.c | 14 ++- drivers/gpu/host1x/dev.c | 6 + drivers/gpu/host1x/dev.h | 13 ++- drivers/gpu/host1x/hw/cdma_hw.c| 2 +- drivers/gpu/host1x/hw/channel_hw.c | 10 +- drivers/gpu/host1x/hw/debug_hw.c | 2 +- drivers/gpu/host1x/hw/hw_host1x07_vm.h | 2 +- drivers/gpu/host1x/intr.c | 28 +++-- drivers/gpu/host1x/intr.h | 4 +- drivers/gpu/host1x/job.c | 5 +- drivers/gpu/host1x/syncpt.c| 202 - drivers/gpu/host1x/syncpt.h| 4 +- drivers/staging/media/tegra-video/vi.c | 6 +- include/linux/host1x.h | 27 - 28 files changed, 494 insertions(+), 172 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/msm: Avoid mutex in shrinker_count()
On Thu, Apr 1, 2021 at 8:34 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Mar 31, 2021 at 6:24 PM Rob Clark wrote:
> >
> > @@ -45,6 +30,9 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
> > shrink_control *sc)
> > list_for_each_entry(msm_obj, &priv->inactive_dontneed, mm_list) {
> > if (freed >= sc->nr_to_scan)
> > break;
> > + /* Use trylock, because we cannot block on a obj that
> > +* might be trying to acquire mm_lock
> > +*/
>
> nit: I thought the above multi-line commenting style was only for
> "net" subsystem?
we do use the "net" style a fair bit already.. (OTOH I tend to not
really care what checkpatch says)
> > if (!msm_gem_trylock(&msm_obj->base))
> > continue;
> > if (is_purgeable(msm_obj)) {
> > @@ -56,8 +44,11 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
> > shrink_control *sc)
> >
> > mutex_unlock(&priv->mm_lock);
> >
> > - if (freed > 0)
> > + if (freed > 0) {
> > trace_msm_gem_purge(freed << PAGE_SHIFT);
> > + } else {
> > + return SHRINK_STOP;
> > + }
>
> It probably doesn't matter, but I wonder if we should still be
> returning SHRINK_STOP if we got any trylock failures. It could
> possibly be worth returning 0 in that case?
On the surface, you'd think that, but there be mm dragons.. we can hit
shrinker from the submit path when the obj is locked already and we
are trying to allocate backing pages. We don't want to tell vmscan to
keep trying, because we'll keep failing to grab that objects lock
>
> > @@ -75,6 +66,9 @@ vmap_shrink(struct list_head *mm_list)
> > unsigned unmapped = 0;
> >
> > list_for_each_entry(msm_obj, mm_list, mm_list) {
> > + /* Use trylock, because we cannot block on a obj that
> > +* might be trying to acquire mm_lock
> > +*/
>
> If you end up changing the commenting style above, should also be here.
>
> At this point this seems fine to land to me. Though I'm not an expert
> on every interaction in this code, I've spent enough time starting at
> it that I'm comfortable with:
>
> Reviewed-by: Douglas Anderson
thanks
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Drop mm_lock in scan loop
From: Rob Clark
lock_stat + mmm_donut[1] say that this reduces contention on mm_lock
significantly (~350x lower waittime-max, and ~100x lower waittime-avg)
[1]
https://chromium.googlesource.com/chromiumos/platform/microbenchmarks/+/refs/heads/main/mmm_donut.py
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/msm/msm_gem_shrinker.c | 48 ++
2 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 2ecf7f1cef25..75cea5b801da 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -719,7 +719,7 @@ void msm_gem_purge(struct drm_gem_object *obj)
put_iova_vmas(obj);
msm_obj->madv = __MSM_MADV_PURGED;
- mark_unpurgable(msm_obj);
+ update_inactive(msm_obj);
drm_vma_node_unmap(&obj->vma_node, dev->anon_inode->i_mapping);
drm_gem_free_mmap_offset(obj);
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c
b/drivers/gpu/drm/msm/msm_gem_shrinker.c
index f3e948af01c5..6bbb15d64861 100644
--- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
+++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
@@ -22,26 +22,62 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
{
struct msm_drm_private *priv =
container_of(shrinker, struct msm_drm_private, shrinker);
- struct msm_gem_object *msm_obj;
+ struct list_head still_in_list;
unsigned long freed = 0;
+ INIT_LIST_HEAD(&still_in_list);
+
mutex_lock(&priv->mm_lock);
- list_for_each_entry(msm_obj, &priv->inactive_dontneed, mm_list) {
- if (freed >= sc->nr_to_scan)
+ while (freed < sc->nr_to_scan) {
+ struct msm_gem_object *msm_obj = list_first_entry_or_null(
+ &priv->inactive_dontneed, typeof(*msm_obj),
mm_list);
+
+ if (!msm_obj)
break;
- /* Use trylock, because we cannot block on a obj that
-* might be trying to acquire mm_lock
+
+ /*
+* If it is in the process of being freed, msm_gem_free_object
+* can be blocked on mm_lock waiting to remove it. So just
+* skip it.
*/
- if (!msm_gem_trylock(&msm_obj->base))
+ if (!kref_get_unless_zero(&msm_obj->base.refcount))
continue;
+
+ /*
+* Now that we own a reference, we can move it to our own
+* private temporary list and drop mm_lock for the rest of
+* the loop body, to reduce contention with the retire_submit
+* path (which could make more objects available to purge)
+*/
+ list_move_tail(&msm_obj->mm_list, &still_in_list);
+
+ mutex_unlock(&priv->mm_lock);
+
+ /*
+* Note that this still needs to be trylock, since we can
+* hit shrinker in response to trying to get backing pages
+* for this obj (ie. while it's lock is already held)
+*/
+ if (!msm_gem_trylock(&msm_obj->base))
+ goto tail;
+
if (is_purgeable(msm_obj)) {
+ /*
+* This will move the obj out of still_in_list to
+* the purged list
+*/
msm_gem_purge(&msm_obj->base);
freed += msm_obj->base.size >> PAGE_SHIFT;
}
msm_gem_unlock(&msm_obj->base);
+
+tail:
+ drm_gem_object_put(&msm_obj->base);
+ mutex_lock(&priv->mm_lock);
}
+ list_splice_tail(&still_in_list, &priv->inactive_dontneed);
mutex_unlock(&priv->mm_lock);
if (freed > 0) {
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: a6xx: fix version check for the A650 SQE microcode
On Wed, Mar 31, 2021 at 05:02:23PM +0300, Dmitry Baryshkov wrote:
> I suppose the microcode version check for a650 is incorrect. It checks
> for the version 1.95, while the firmware released have major version of 0:
> 0.91 (vulnerable), 0.99 (fixing the issue).
>
> Lower version requirements to accept firmware 0.99.
Ugh, my ugly. .95 is the actual version that fixed it but since .99 is what is
going into the l-f repo it is fine to use that as a baseline.
Acked-by: Jordan Crouse
> Fixes: 8490f02a3ca4 ("drm/msm: a6xx: Make sure the SQE microcode is safe")
> Cc: Akhil P Oommen
> Cc: Jordan Crouse
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index cb2df8736ca8..896b47dc9c85 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -567,17 +567,17 @@ static bool a6xx_ucode_check_version(struct a6xx_gpu
> *a6xx_gpu,
> } else {
> /*
>* a650 tier targets don't need whereami but still need to be
> - * equal to or newer than 1.95 for other security fixes
> + * equal to or newer than 0.95 for other security fixes
>*/
> if (adreno_is_a650(adreno_gpu)) {
> - if ((buf[0] & 0xfff) >= 0x195) {
> + if ((buf[0] & 0xfff) >= 0x095) {
> ret = true;
> goto out;
> }
>
> DRM_DEV_ERROR(&gpu->pdev->dev,
> "a650 SQE ucode is too old. Have version %x
> need at least %x\n",
> - buf[0] & 0xfff, 0x195);
> + buf[0] & 0xfff, 0x095);
> }
>
> /*
> --
> 2.30.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.12-rc6
Hi Linus, Things have settled down in time for Easter, a random smattering of small fixes across a few drivers. I'm guessing though there might be some i915 and misc fixes out there I haven't gotten yet, but since today is a public holiday here, I'm sending this early so I can have the day off, I'll see if more requests come in and decide what to do with them later. Dave. drm-fixes-2021-04-02: drm fixes for 5.12-rc6 amdgpu: - Polaris idle power fix - VM fix - Vangogh S3 fix - Fixes for non-4K page sizes amdkfd: - dqm fence memory corruption fix tegra: - lockdep warning fix - runtine PM reference fix - display controller fix - PLL Fix imx: - memory leak in error path fix - LDB driver channel registration fix - oob array warning in LDB driver exynos - unused header file removal The following changes since commit a5e13c6df0e41702d2b2c77c8ad41677ebb065b3: Linux 5.12-rc5 (2021-03-28 15:48:16 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-02 for you to fetch changes up to 6fdb8e5aba6a33fe5f1a0bd1bcf0cf2884437ead: Merge tag 'imx-drm-fixes-2021-04-01' of git://git.pengutronix.de/git/pza/linux into drm-fixes (2021-04-02 04:53:16 +1000) drm fixes for 5.12-rc6 amdgpu: - Polaris idle power fix - VM fix - Vangogh S3 fix - Fixes for non-4K page sizes amdkfd: - dqm fence memory corruption fix tegra: - lockdep warning fix - runtine PM reference fix - display controller fix - PLL Fix imx: - memory leak in error path fix - LDB driver channel registration fix - oob array warning in LDB driver exynos - unused header file removal Alex Deucher (1): drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in suspend Arnd Bergmann (1): drm/imx: imx-ldb: fix out of bounds array access warning Dave Airlie (4): Merge tag 'exynos-drm-fixes-for-v5.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes Merge tag 'amd-drm-fixes-5.12-2021-03-31' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm/tegra/for-5.12-rc6' of ssh://git.freedesktop.org/git/tegra/linux into drm-fixes Merge tag 'imx-drm-fixes-2021-04-01' of git://git.pengutronix.de/git/pza/linux into drm-fixes Dmitry Osipenko (1): drm/tegra: dc: Don't set PLL clock to 0Hz Evan Quan (1): drm/amd/pm: no need to force MCLK to highest when no display connected Huacai Chen (1): drm/amdgpu: Set a suitable dev_info.gart_page_size Liu Ying (1): drm/imx: imx-ldb: Register LDB channel1 when it is the only channel to be used Mikko Perttunen (1): gpu: host1x: Use different lock classes for each client Nirmoy Das (1): drm/amdgpu: fix offset calculation in amdgpu_vm_bo_clear_mappings() Pan Bian (1): drm/imx: fix memory leak when fails to init Qu Huang (1): drm/amdkfd: dqm fence memory corruption Thierry Reding (2): drm/tegra: dc: Restore coupling of display controllers drm/tegra: sor: Grab runtime PM reference across reset Tian Tao (1): drm/exynos/decon5433: Remove the unused include statements Xℹ Ruoyao (1): drm/amdgpu: check alignment on CPU page for bo map drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 4 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 10 drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c| 2 +- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 6 ++--- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c| 2 +- drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 8 +++--- .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c| 3 ++- drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 5 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 - drivers/gpu/drm/imx/imx-drm-core.c | 2 +- drivers/gpu/drm/imx/imx-ldb.c | 12 - drivers/gpu/drm/tegra/dc.c | 30 ++ drivers/gpu/drm/tegra/sor.c| 7 + drivers/gpu/host1x/bus.c | 10 +--- include/linux/host1x.h | 9 ++- 18 files changed, 72 insertions(+), 45 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/34] drm/amdkfd: register HMM device private zone
Hi Felix,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20210331]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
drm/drm-next v5.12-rc5 v5.12-rc4 v5.12-rc3 v5.12-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
base:7a43c78d0573e00456b033e2b9a895b89464
config: x86_64-randconfig-a011-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/1b956676a808da2199942fd64b49fd1cec2c12be
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
git checkout 1b956676a808da2199942fd64b49fd1cec2c12be
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c: In function
'svm_migrate_fini':
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c:102:2: error: implicit
>> declaration of function 'memunmap_pages'; did you mean 'memcmp_pages'?
>> [-Werror=implicit-function-declaration]
102 | memunmap_pages(&adev->kfd.dev->pgmap);
| ^~
| memcmp_pages
cc1: some warnings being treated as errors
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for DEVICE_PRIVATE
Depends on ZONE_DEVICE
Selected by
- HSA_AMD && HAS_IOMEM && DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
vim +102 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c
99
100 void svm_migrate_fini(struct amdgpu_device *adev)
101 {
> 102 memunmap_pages(&adev->kfd.dev->pgmap);
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.12-rc6
The pull request you sent on Fri, 2 Apr 2021 05:17:07 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-02 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a80314c327a937ff1213288adf0d11414c40a898 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/tegra: sor: Fully initialize SOR before registration
On 01/04/2021 16:41, Thierry Reding wrote:
> From: Thierry Reding
>
> Before registering the SOR host1x client, make sure that it is fully
> initialized. This avoids a potential race condition between the SOR's
> probe and the host1x device initialization in cases where the SOR is
> the final sub-device to register to a host1x instance.
>
> Reported-by: Jonathan Hunter
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/sor.c | 27 +--
> 1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index 7b88261f57bb..b29bc10a0a4d 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -3916,17 +3916,10 @@ static int tegra_sor_probe(struct platform_device
> *pdev)
> platform_set_drvdata(pdev, sor);
> pm_runtime_enable(&pdev->dev);
>
> - INIT_LIST_HEAD(&sor->client.list);
> + host1x_client_init(&sor->client);
> sor->client.ops = &sor_client_ops;
> sor->client.dev = &pdev->dev;
>
> - err = host1x_client_register(&sor->client);
> - if (err < 0) {
> - dev_err(&pdev->dev, "failed to register host1x client: %d\n",
> - err);
> - goto rpm_disable;
> - }
> -
> /*
>* On Tegra210 and earlier, provide our own implementation for the
>* pad output clock.
> @@ -3938,13 +3931,13 @@ static int tegra_sor_probe(struct platform_device
> *pdev)
> sor->index);
> if (!name) {
> err = -ENOMEM;
> - goto unregister;
> + goto uninit;
> }
>
> err = host1x_client_resume(&sor->client);
> if (err < 0) {
> dev_err(sor->dev, "failed to resume: %d\n", err);
> - goto unregister;
> + goto uninit;
> }
>
> sor->clk_pad = tegra_clk_sor_pad_register(sor, name);
> @@ -3955,14 +3948,20 @@ static int tegra_sor_probe(struct platform_device
> *pdev)
> err = PTR_ERR(sor->clk_pad);
> dev_err(sor->dev, "failed to register SOR pad clock: %d\n",
> err);
> - goto unregister;
> + goto uninit;
> + }
> +
> + err = __host1x_client_register(&sor->client);
> + if (err < 0) {
> + dev_err(&pdev->dev, "failed to register host1x client: %d\n",
> + err);
> + goto uninit;
> }
>
> return 0;
>
> -unregister:
> - host1x_client_unregister(&sor->client);
> -rpm_disable:
> +uninit:
> + host1x_client_exit(&sor->client);
> pm_runtime_disable(&pdev->dev);
> remove:
> tegra_output_remove(&sor->output);
>
Thanks! Completed 200 boots on Jetson TX1 without any further probing
issues, so ...
Tested-by: Jon Hunter
Cheers
Jon
--
nvpublic
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/a6xx: fix for kernels without CONFIG_NVMEM
On Mon, Feb 22, 2021 at 8:06 AM Rob Clark wrote:
>
> On Mon, Feb 22, 2021 at 7:45 AM Akhil P Oommen wrote:
> >
> > On 2/19/2021 9:30 PM, Rob Clark wrote:
> > > On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen
> > > wrote:
> > >>
> > >> On 2/18/2021 9:41 PM, Rob Clark wrote:
> > >>> On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen
> > >>> wrote:
> >
> > On 2/18/2021 2:05 AM, Jonathan Marek wrote:
> > > On 2/17/21 3:18 PM, Rob Clark wrote:
> > >> On Wed, Feb 17, 2021 at 11:08 AM Jordan Crouse
> > >> wrote:
> > >>>
> > >>> On Wed, Feb 17, 2021 at 07:14:16PM +0530, Akhil P Oommen wrote:
> > On 2/17/2021 8:36 AM, Rob Clark wrote:
> > > On Tue, Feb 16, 2021 at 12:10 PM Jonathan Marek
> > >
> > > wrote:
> > >>
> > >> Ignore nvmem_cell_get() EOPNOTSUPP error in the same way as a
> > >> ENOENT error,
> > >> to fix the case where the kernel was compiled without
> > >> CONFIG_NVMEM.
> > >>
> > >> Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618
> > >> gpu")
> > >> Signed-off-by: Jonathan Marek
> > >> ---
> > >> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
> > >> 1 file changed, 3 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > >> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > >> index ba8e9d3cf0fe..7fe5d97606aa 100644
> > >> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > >> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > >> @@ -1356,10 +1356,10 @@ static int a6xx_set_supported_hw(struct
> > >> device *dev, struct a6xx_gpu *a6xx_gpu,
> > >>
> > >>cell = nvmem_cell_get(dev, "speed_bin");
> > >>/*
> > >> -* -ENOENT means that the platform doesn't support
> > >> speedbin which is
> > >> -* fine
> > >> +* -ENOENT means no speed bin in device tree,
> > >> +* -EOPNOTSUPP means kernel was built without
> > >> CONFIG_NVMEM
> > >
> > > very minor nit, it would be nice to at least preserve the gist of
> > > the
> > > "which is fine" (ie. some variation of "this is an optional thing
> > > and
> > > things won't catch fire without it" ;-))
> > >
> > > (which is, I believe, is true, hopefully Akhil could confirm.. if
> > > not
> > > we should have a harder dependency on CONFIG_NVMEM..)
> > IIRC, if the gpu opp table in the DT uses the 'opp-supported-hw'
> > property,
> > we will see some error during boot up if we don't call
> > dev_pm_opp_set_supported_hw(). So calling "nvmem_cell_get(dev,
> > "speed_bin")"
> > is a way to test this.
> >
> > If there is no other harm, we can put a hard dependency on
> > CONFIG_NVMEM.
> > >>>
> > >>> I'm not sure if we want to go this far given the squishiness about
> > >>> module
> > >>> dependencies. As far as I know we are the only driver that uses this
> > >>> seriously
> > >>> on QCOM SoCs and this is only needed for certain targets. I don't
> > >>> know if we
> > >>> want to force every target to build NVMEM and QFPROM on our behalf.
> > >>> But maybe
> > >>> I'm just saying that because Kconfig dependencies tend to break my
> > >>> brain (and
> > >>> then Arnd has to send a patch to fix it).
> > >>>
> > >>
> > >> Hmm, good point.. looks like CONFIG_NVMEM itself doesn't have any
> > >> other dependencies, so I suppose it wouldn't be the end of the world
> > >> to select that.. but I guess we don't want to require QFPROM
> > >>
> > >> I guess at the end of the day, what is the failure mode if you have a
> > >> speed-bin device, but your kernel config misses QFPROM (and possibly
> > >> NVMEM)? If the result is just not having the highest clk rate(s)
> >
> > Atleast on sc7180's gpu, using an unsupported FMAX breaks gmu. It won't
> > be very obvious what went wrong when this happens!
> > >>>
> > >>> Ugg, ok..
> > >>>
> > >>> I suppose we could select NVMEM, but not QFPROM, and then the case
> > >>> where QFPROM is not enabled on platforms that have the speed-bin field
> > >>> in DT will fail gracefully and all other platforms would continue on
> > >>> happily?
> > >>>
> > >>> BR,
> > >>> -R
> > >>
> > >> Sounds good to me.
> > >>
> > >
> > > You probably should do a quick test with NVMEM enabled but QFPROM
> > > disabled to confirm my theory, but I *think* that should work
> > >
> > > BR,
> > > -R
> > >
> >
> > I tried it on an sc7180 device. The suggested combo (CONFIG_NVMEM + no
> > CONFIG_QCOM_QFPROM) makes the gpu probe fail with error "failed to read
> > speed-bin. Some OPPs may not be supported by hardware
Update firmware for Qualcomm SM8250 platform
Hello linux-firmware maintainers, Could you please pull updated firmware for Qualcomm SM8250-based platforms. Firmware successfully tested on Qualcomm Robotics RB5 platform. The following changes since commit 3f026a2f13a8f130cde849168a111ec80f12e27b: rtl_bt: Update RTL8822C BT(UART I/F) FW to 0x59A_76A3 (2021-03-22 10:17:18 -0400) are available in the Git repository at: https://github.com/lumag/linux-firmware sm8250-new-fw for you to fetch changes up to d8fa0cfb4a285d11fd7102efd1763f1be90fac99: qcom: sm8250: update remoteproc firmware (2021-04-01 23:05:00 +0300) Dmitry Baryshkov (2): qcom: update a650 firmware files qcom: sm8250: update remoteproc firmware WHENCE | 2 +- qcom/a650_sqe.fw | Bin 31488 -> 31804 bytes qcom/sm8250/a650_zap.mbn | Bin 13964 -> 13964 bytes qcom/sm8250/adsp.mbn | Bin 15515796 -> 15515796 bytes qcom/sm8250/cdsp.mbn | Bin 588 -> 588 bytes 5 files changed, 1 insertion(+), 1 deletion(-) -- With best wishes Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/a6xx: fix for kernels without CONFIG_NVMEM
On Thu, 1 Apr 2021 at 23:09, Rob Clark wrote:
>
> On Mon, Feb 22, 2021 at 8:06 AM Rob Clark wrote:
> >
> > On Mon, Feb 22, 2021 at 7:45 AM Akhil P Oommen
> > wrote:
> > >
> > > On 2/19/2021 9:30 PM, Rob Clark wrote:
> > > > On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen
> > > > wrote:
> > > >>
> > > >> On 2/18/2021 9:41 PM, Rob Clark wrote:
> > > >>> On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen
> > > >>> wrote:
> > >
> > > On 2/18/2021 2:05 AM, Jonathan Marek wrote:
> > > > On 2/17/21 3:18 PM, Rob Clark wrote:
> > > >> On Wed, Feb 17, 2021 at 11:08 AM Jordan Crouse
> > > >> wrote:
> > > >>>
> > > >>> On Wed, Feb 17, 2021 at 07:14:16PM +0530, Akhil P Oommen wrote:
> > > On 2/17/2021 8:36 AM, Rob Clark wrote:
> > > > On Tue, Feb 16, 2021 at 12:10 PM Jonathan Marek
> > > >
> > > > wrote:
> > > >>
> > > >> Ignore nvmem_cell_get() EOPNOTSUPP error in the same way as a
> > > >> ENOENT error,
> > > >> to fix the case where the kernel was compiled without
> > > >> CONFIG_NVMEM.
> > > >>
> > > >> Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618
> > > >> gpu")
> > > >> Signed-off-by: Jonathan Marek
> > > >> ---
> > > >> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
> > > >> 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > >> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > >> index ba8e9d3cf0fe..7fe5d97606aa 100644
> > > >> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > >> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > >> @@ -1356,10 +1356,10 @@ static int a6xx_set_supported_hw(struct
> > > >> device *dev, struct a6xx_gpu *a6xx_gpu,
> > > >>
> > > >>cell = nvmem_cell_get(dev, "speed_bin");
> > > >>/*
> > > >> -* -ENOENT means that the platform doesn't support
> > > >> speedbin which is
> > > >> -* fine
> > > >> +* -ENOENT means no speed bin in device tree,
> > > >> +* -EOPNOTSUPP means kernel was built without
> > > >> CONFIG_NVMEM
> > > >
> > > > very minor nit, it would be nice to at least preserve the gist
> > > > of the
> > > > "which is fine" (ie. some variation of "this is an optional
> > > > thing and
> > > > things won't catch fire without it" ;-))
> > > >
> > > > (which is, I believe, is true, hopefully Akhil could confirm..
> > > > if not
> > > > we should have a harder dependency on CONFIG_NVMEM..)
> > > IIRC, if the gpu opp table in the DT uses the 'opp-supported-hw'
> > > property,
> > > we will see some error during boot up if we don't call
> > > dev_pm_opp_set_supported_hw(). So calling "nvmem_cell_get(dev,
> > > "speed_bin")"
> > > is a way to test this.
> > >
> > > If there is no other harm, we can put a hard dependency on
> > > CONFIG_NVMEM.
> > > >>>
> > > >>> I'm not sure if we want to go this far given the squishiness about
> > > >>> module
> > > >>> dependencies. As far as I know we are the only driver that uses
> > > >>> this
> > > >>> seriously
> > > >>> on QCOM SoCs and this is only needed for certain targets. I don't
> > > >>> know if we
> > > >>> want to force every target to build NVMEM and QFPROM on our
> > > >>> behalf.
> > > >>> But maybe
> > > >>> I'm just saying that because Kconfig dependencies tend to break my
> > > >>> brain (and
> > > >>> then Arnd has to send a patch to fix it).
> > > >>>
> > > >>
> > > >> Hmm, good point.. looks like CONFIG_NVMEM itself doesn't have any
> > > >> other dependencies, so I suppose it wouldn't be the end of the
> > > >> world
> > > >> to select that.. but I guess we don't want to require QFPROM
> > > >>
> > > >> I guess at the end of the day, what is the failure mode if you
> > > >> have a
> > > >> speed-bin device, but your kernel config misses QFPROM (and
> > > >> possibly
> > > >> NVMEM)? If the result is just not having the highest clk rate(s)
> > >
> > > Atleast on sc7180's gpu, using an unsupported FMAX breaks gmu. It
> > > won't
> > > be very obvious what went wrong when this happens!
> > > >>>
> > > >>> Ugg, ok..
> > > >>>
> > > >>> I suppose we could select NVMEM, but not QFPROM, and then the case
> > > >>> where QFPROM is not enabled on platforms that have the speed-bin field
> > > >>> in DT will fail gracefully and all other platforms would continue on
> > > >>> happily?
> > > >>>
> > > >>> BR,
> > > >>> -R
> > > >>
> > > >> Sounds good to me.
> > > >>
> > > >
> > > > You probably should d
Re: [PATCH] drm/amd: use kmalloc_array over kmalloc with multiply
Applied. Thanks! On Wed, Mar 31, 2021 at 9:36 AM Bernard Zhao wrote: > > Fix patch check warning: > WARNING: Prefer kmalloc_array over kmalloc with multiply > + buf = kmalloc(MAX_KFIFO_SIZE * sizeof(*buf), GFP_KERNEL); > > Signed-off-by: Bernard Zhao > --- > drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c > b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c > index 17d1736367ea..246522423559 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c > @@ -81,7 +81,7 @@ static ssize_t kfd_smi_ev_read(struct file *filep, char > __user *user, > struct kfd_smi_client *client = filep->private_data; > unsigned char *buf; > > - buf = kmalloc(MAX_KFIFO_SIZE * sizeof(*buf), GFP_KERNEL); > + buf = kmalloc_array(MAX_KFIFO_SIZE, sizeof(*buf), GFP_KERNEL); > if (!buf) > return -ENOMEM; > > -- > 2.31.0 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd: cleanup coding style a bit
Applied. Thanks!
Alex
On Wed, Mar 31, 2021 at 9:36 AM Bernard Zhao wrote:
>
> Fix patch check warning:
> WARNING: suspect code indent for conditional statements (8, 17)
> + if (obj && obj->use < 0) {
> +DRM_ERROR("RAS ERROR: Unbalance obj(%s) use\n",
> obj->head.name);
>
> WARNING: braces {} are not necessary for single statement blocks
> + if (obj && obj->use < 0) {
> +DRM_ERROR("RAS ERROR: Unbalance obj(%s) use\n",
> obj->head.name);
> + }
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 1fb2a91ad30a..43d17b72c265 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -449,11 +449,10 @@ static ssize_t amdgpu_ras_sysfs_read(struct device *dev,
>
> static inline void put_obj(struct ras_manager *obj)
> {
> - if (obj && --obj->use == 0)
> + if (obj && (--obj->use == 0))
> list_del(&obj->node);
> - if (obj && obj->use < 0) {
> -DRM_ERROR("RAS ERROR: Unbalance obj(%s) use\n",
> obj->head.name);
> - }
> + if (obj && (obj->use < 0))
> + DRM_ERROR("RAS ERROR: Unbalance obj(%s) use\n",
> obj->head.name);
> }
>
> /* make one obj and return it. */
> --
> 2.31.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amd/amdgpu: code refactoring to clean code style a bit
This code has been dropped.
Alex
On Wed, Mar 31, 2021 at 9:36 AM Bernard Zhao wrote:
>
> Fix checkpatch.pl warning:
> Too many leading tabs - consider code refactoring
> WARNING: Too many leading tabs - consider code refactoring
> + for (j = 0; j <
> profile->ucLeakageBinNum; j++) {
>
> WARNING: Too many leading tabs - consider code refactoring
> + if (vbios_voltage_id
> <= leakage_bin[j]) {
>
> WARNING: Too many leading tabs - consider code refactoring
> + for (j = 0; j <
> profile->ucLeakageBinNum; j++) {
>
> WARNING: Too many leading tabs - consider code refactoring
> + if (vbios_voltage_id
> <= leakage_bin[j]) {
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 84
> 1 file changed, 35 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> index 86add0f4ea4d..9968ff8ddc9c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> @@ -1283,65 +1283,51 @@ int
> amdgpu_atombios_get_leakage_vddc_based_on_leakage_params(struct amdgpu_devic
> profile = (ATOM_ASIC_PROFILING_INFO_V2_1 *)
> (adev->mode_info.atom_context->bios + data_offset);
>
> - switch (frev) {
> - case 1:
> + if ((frev != 2) || (crev != 1)) {
> + DRM_ERROR("Unknown table version %d, %d\n", frev, crev);
> return -EINVAL;
> - case 2:
> - switch (crev) {
> - case 1:
> - if (size < sizeof(ATOM_ASIC_PROFILING_INFO_V2_1))
> - return -EINVAL;
> - leakage_bin = (u16 *)
> - (adev->mode_info.atom_context->bios +
> data_offset +
> -
> le16_to_cpu(profile->usLeakageBinArrayOffset));
> - vddc_id_buf = (u16 *)
> - (adev->mode_info.atom_context->bios +
> data_offset +
> -
> le16_to_cpu(profile->usElbVDDC_IdArrayOffset));
> - vddc_buf = (u16 *)
> - (adev->mode_info.atom_context->bios +
> data_offset +
> -
> le16_to_cpu(profile->usElbVDDC_LevelArrayOffset));
> - vddci_id_buf = (u16 *)
> - (adev->mode_info.atom_context->bios +
> data_offset +
> -
> le16_to_cpu(profile->usElbVDDCI_IdArrayOffset));
> - vddci_buf = (u16 *)
> - (adev->mode_info.atom_context->bios +
> data_offset +
> -
> le16_to_cpu(profile->usElbVDDCI_LevelArrayOffset));
> -
> - if (profile->ucElbVDDC_Num > 0) {
> - for (i = 0; i < profile->ucElbVDDC_Num; i++) {
> - if (vddc_id_buf[i] ==
> virtual_voltage_id) {
> - for (j = 0; j <
> profile->ucLeakageBinNum; j++) {
> - if (vbios_voltage_id
> <= leakage_bin[j]) {
> - *vddc =
> vddc_buf[j * profile->ucElbVDDC_Num + i];
> - break;
> - }
> - }
> + }
> +
> + if (size < sizeof(ATOM_ASIC_PROFILING_INFO_V2_1))
> + return -EINVAL;
> +
> + leakage_bin = (u16 *)(adev->mode_info.atom_context->bios +
> data_offset +
> +le16_to_cpu(profile->usLeakageBinArrayOffset));
> + vddc_id_buf = (u16 *)(adev->mode_info.atom_context->bios +
> data_offset +
> +le16_to_cpu(profile->usElbVDDC_IdArrayOffset));
> + vddc_buf = (u16 *)(adev->mode_info.atom_context->bios + data_offset +
> +le16_to_cpu(profile->usElbVDDC_LevelArrayOffset));
> + vddci_id_buf = (u16 *)(adev->mode_info.atom_context->bios +
> data_offset +
> +le16_to_cpu(profile->usElbVDDCI_IdArrayOffset));
> + vddci_buf = (u16 *)(adev->mode_info.atom_context->bios + data_offset +
> +le16_to_cpu(profile->usElbVDDCI_LevelArrayOffset));
> +
> + if (profile->ucElbVDDC_Num > 0) {
> + for (i = 0; i < profile->ucElbVDDC_Num; i++) {
> + if (vddc_id_buf[i] == virtual_voltage_id) {
> + for (j = 0; j < profile->ucLeakageBinNum;
> j++) {
> + if (vbios_voltage_id <=
> leakage_bin[j]) {
> +
Re: [PATCH] drm/ttm: add __user annotation in radeon_ttm_vram_read
Current code already contains the fix. Alex On Thu, Apr 1, 2021 at 9:09 AM Christian König wrote: > > Am 24.10.20 um 02:47 schrieb Rasmus Villemoes: > > Keep sparse happy by preserving the __user annotation when casting. > > > > Reported-by: kernel test robot > > Signed-off-by: Rasmus Villemoes > > Reviewed-by: Christian König > > Going over old patches and stumbled over that once. > > Alex did you missed to pick it up? > > Regards, > Christian. > > > --- > > > > kernel test robot has already started spamming me due to 9c5743dff. If > > I don't fix those warnings I'll keep getting those emails for > > months, so let me do the easy ones. > > > > > > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c > > b/drivers/gpu/drm/radeon/radeon_ttm.c > > index 36150b7f31a90aa1eece..ecfe88b0a35d8f317712 100644 > > --- a/drivers/gpu/drm/radeon/radeon_ttm.c > > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c > > @@ -1005,7 +1005,7 @@ static ssize_t radeon_ttm_vram_read(struct file *f, > > char __user *buf, > > value = RREG32(RADEON_MM_DATA); > > spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags); > > > > - r = put_user(value, (uint32_t *)buf); > > + r = put_user(value, (uint32_t __user *)buf); > > if (r) > > return r; > > > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 03/21] gpu: host1x: Show number of pending waiters in debugfs
On Fri, Mar 26, 2021 at 04:34:13PM +0200, Mikko Perttunen wrote:
> On 3/23/21 12:16 PM, Thierry Reding wrote:
> > On Mon, Jan 11, 2021 at 03:00:01PM +0200, Mikko Perttunen wrote:
> > > Show the number of pending waiters in the debugfs status file.
> > > This is useful for testing to verify that waiters do not leak
> > > or accumulate incorrectly.
> > >
> > > Signed-off-by: Mikko Perttunen
> > > ---
> > > drivers/gpu/host1x/debug.c | 14 +++---
> > > 1 file changed, 11 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
> > > index 1b4997bda1c7..8a14880c61bb 100644
> > > --- a/drivers/gpu/host1x/debug.c
> > > +++ b/drivers/gpu/host1x/debug.c
> > > @@ -69,6 +69,7 @@ static int show_channel(struct host1x_channel *ch, void
> > > *data, bool show_fifo)
> > > static void show_syncpts(struct host1x *m, struct output *o)
> > > {
> > > + struct list_head *pos;
> > > unsigned int i;
> > > host1x_debug_output(o, " syncpts \n");
> > > @@ -76,12 +77,19 @@ static void show_syncpts(struct host1x *m, struct
> > > output *o)
> > > for (i = 0; i < host1x_syncpt_nb_pts(m); i++) {
> > > u32 max = host1x_syncpt_read_max(m->syncpt + i);
> > > u32 min = host1x_syncpt_load(m->syncpt + i);
> > > + unsigned int waiters = 0;
> > > - if (!min && !max)
> > > + spin_lock(&m->syncpt[i].intr.lock);
> > > + list_for_each(pos, &m->syncpt[i].intr.wait_head)
> > > + waiters++;
> > > + spin_unlock(&m->syncpt[i].intr.lock);
> >
> > Would it make sense to keep a running count so that we don't have to
> > compute it here?
>
> Considering this is just a debug facility, I think I prefer not adding a new
> field just for it.
This looks like IRQ-disabled region, so unless only root can trigger
this code, maybe the additional field could save a potential headache?
How many waiters can there be in the worst case?
Best Regards
Michał Mirosław
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Fri, Mar 26, 2021 at 06:15:22PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 25, 2021 at 03:01:29PM -0700, Navare, Manasi wrote:
> > On Fri, Mar 19, 2021 at 11:27:59PM +0200, Ville Syrjälä wrote:
> > > On Fri, Mar 19, 2021 at 02:26:24PM -0700, Navare, Manasi wrote:
> > > > On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote:
> > > > > On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> > > > > > On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> > > > > > > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > > > > > > > So basically we see this warning only in case of bigjoiner when
> > > > > > > > drm_atomic_check gets called without setting the
> > > > > > > > state->allow_modeset flag.
> > > > > > >
> > > > > > > Considering the code is 'WARN(!state->allow_modeset, ...' that
> > > > > > > fact should be rather obvious.
> > > > > > >
> > > > > > > >
> > > > > > > > So do you think that in i915, in intel_atomic_check_bigjoiner()
> > > > > > > > we should only
> > > > > > > > steal the crtc when allow_modeset flag is set in state?
> > > > > > >
> > > > > > > No. If you fully read drm_atomic_check_only() you will observe
> > > > > > > that it will reject any commit w/ allow_modeset==false which
> > > > > > > needs a modeset. And it does that before the WARN.
> > > > > > >
> > > > > > > So you're barking up the wrong tree here. The problem I think
> > > > > > > is that you're just computing requested_crtcs wrong.
> > > > > >
> > > > > > So here in this case, requested CRTC = 0x1 since it requests
> > > > > > modeset on CRTC 0
> > > > > > Now in teh atomic check, it steals the slave CRTC 1 and hence
> > > > > > affected CRTC comes out
> > > > > > as 0x3 and hence the mismatch.
> > > > >
> > > > > Hmm. How can it be 0x3 if we filtered out the uapi.enable==false case?
> > > > >
> > > >
> > > > Yes if I add that condition like in this patch then it correctly
> > > > calculates
> > > > the affected crtc bitmask as only 0x1 since it doesnt include the slave
> > > > crtc.
> > > > So with this patch, requested crtc = 0x 1, affected crtc = 0x1
> > > >
> > > > If this looks good then this fixes our bigjoiner warnings.
> > > > Does this patch look good to you as is then?
> > >
> > > I think you still need to fix the requested_crtcs calculation.
> >
> > We calculate requested crtc at the beginning :
> > for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > requested_crtc |= drm_crtc_mask(crtc);
> >
> > Are you suggesting adding this to after:
> > if (config->funcs->atomic_check) {
> > ret = config->funcs->atomic_check(state->dev, state);
> >
> > if (ret) {
> > DRM_DEBUG_ATOMIC("atomic driver check for %p
> > failed: %d\n",
> > state, ret);
> > return ret;
> > }
> > requested_crtc |= drm_crtc_mask(crtc);// Here it will have
> > requested crtc = 0x11
> > }
> >
> > in this case here the state should already have master crtc 0 and slave
> > crtc 1
> > and that requested crtc should already be 0x11
> >
> > Then in that case we dont need any special check for calculating affected
> > crtc, that also will be 0x11
>
> All I'm saying is that you're currently calculating requested_crtcs and
> affected_crtcs differently. So I'm not at all surprised that they might
> not match.
>
I dont get your point yet.
requested crtc is calculated before the atomic check call and we dont check for
crtc uapi.enable to be true.
And hence requested crtc = CRTC 0 = 0x2
After I added the check in this patch where affected crtc will include only the
crtcs that have uapi.enable = true
then it perfectly matches the requested crtc and return 0x2 but without this
check when the calculation of
requested and affected crtc is the same is where we see the affected crtc =
CRTC 0 and 1 = 0x3
So when the calculation is different infcat we dont see the mismatch
What is your point here?
Manasi
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/a6xx: fix for kernels without CONFIG_NVMEM
On Thu, Apr 1, 2021 at 2:03 PM Dmitry Baryshkov
wrote:
>
> On Thu, 1 Apr 2021 at 23:09, Rob Clark wrote:
> >
> > On Mon, Feb 22, 2021 at 8:06 AM Rob Clark wrote:
> > >
> > > On Mon, Feb 22, 2021 at 7:45 AM Akhil P Oommen
> > > wrote:
> > > >
> > > > On 2/19/2021 9:30 PM, Rob Clark wrote:
> > > > > On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen
> > > > > wrote:
> > > > >>
> > > > >> On 2/18/2021 9:41 PM, Rob Clark wrote:
> > > > >>> On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen
> > > > >>> wrote:
> > > >
> > > > On 2/18/2021 2:05 AM, Jonathan Marek wrote:
> > > > > On 2/17/21 3:18 PM, Rob Clark wrote:
> > > > >> On Wed, Feb 17, 2021 at 11:08 AM Jordan Crouse
> > > > >> wrote:
> > > > >>>
> > > > >>> On Wed, Feb 17, 2021 at 07:14:16PM +0530, Akhil P Oommen wrote:
> > > > On 2/17/2021 8:36 AM, Rob Clark wrote:
> > > > > On Tue, Feb 16, 2021 at 12:10 PM Jonathan Marek
> > > > >
> > > > > wrote:
> > > > >>
> > > > >> Ignore nvmem_cell_get() EOPNOTSUPP error in the same way as a
> > > > >> ENOENT error,
> > > > >> to fix the case where the kernel was compiled without
> > > > >> CONFIG_NVMEM.
> > > > >>
> > > > >> Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618
> > > > >> gpu")
> > > > >> Signed-off-by: Jonathan Marek
> > > > >> ---
> > > > >> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
> > > > >> 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >>
> > > > >> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > > >> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > > >> index ba8e9d3cf0fe..7fe5d97606aa 100644
> > > > >> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > > >> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > > > >> @@ -1356,10 +1356,10 @@ static int
> > > > >> a6xx_set_supported_hw(struct
> > > > >> device *dev, struct a6xx_gpu *a6xx_gpu,
> > > > >>
> > > > >>cell = nvmem_cell_get(dev, "speed_bin");
> > > > >>/*
> > > > >> -* -ENOENT means that the platform doesn't support
> > > > >> speedbin which is
> > > > >> -* fine
> > > > >> +* -ENOENT means no speed bin in device tree,
> > > > >> +* -EOPNOTSUPP means kernel was built without
> > > > >> CONFIG_NVMEM
> > > > >
> > > > > very minor nit, it would be nice to at least preserve the
> > > > > gist of the
> > > > > "which is fine" (ie. some variation of "this is an optional
> > > > > thing and
> > > > > things won't catch fire without it" ;-))
> > > > >
> > > > > (which is, I believe, is true, hopefully Akhil could
> > > > > confirm.. if not
> > > > > we should have a harder dependency on CONFIG_NVMEM..)
> > > > IIRC, if the gpu opp table in the DT uses the
> > > > 'opp-supported-hw'
> > > > property,
> > > > we will see some error during boot up if we don't call
> > > > dev_pm_opp_set_supported_hw(). So calling "nvmem_cell_get(dev,
> > > > "speed_bin")"
> > > > is a way to test this.
> > > >
> > > > If there is no other harm, we can put a hard dependency on
> > > > CONFIG_NVMEM.
> > > > >>>
> > > > >>> I'm not sure if we want to go this far given the squishiness
> > > > >>> about
> > > > >>> module
> > > > >>> dependencies. As far as I know we are the only driver that uses
> > > > >>> this
> > > > >>> seriously
> > > > >>> on QCOM SoCs and this is only needed for certain targets. I
> > > > >>> don't
> > > > >>> know if we
> > > > >>> want to force every target to build NVMEM and QFPROM on our
> > > > >>> behalf.
> > > > >>> But maybe
> > > > >>> I'm just saying that because Kconfig dependencies tend to break
> > > > >>> my
> > > > >>> brain (and
> > > > >>> then Arnd has to send a patch to fix it).
> > > > >>>
> > > > >>
> > > > >> Hmm, good point.. looks like CONFIG_NVMEM itself doesn't have any
> > > > >> other dependencies, so I suppose it wouldn't be the end of the
> > > > >> world
> > > > >> to select that.. but I guess we don't want to require QFPROM
> > > > >>
> > > > >> I guess at the end of the day, what is the failure mode if you
> > > > >> have a
> > > > >> speed-bin device, but your kernel config misses QFPROM (and
> > > > >> possibly
> > > > >> NVMEM)? If the result is just not having the highest clk rate(s)
> > > >
> > > > Atleast on sc7180's gpu, using an unsupported FMAX breaks gmu. It
> > > > won't
> > > > be very obvious what went wrong when this happens!
> > > > >>>
> > > > >>> Ugg, ok..
> > > > >>>
> > > > >>> I sup
[pull] amdgpu, radeon, ttm, sched drm-next-5.13
Hi Dave, Daniel, New stuff for 5.13. There are two small patches for ttm and scheduler that were dependencies for amdgpu changes. The following changes since commit 2cbcb78c9ee5520c8d836c7ff57d1b60ebe8e9b7: Merge tag 'amd-drm-next-5.13-2021-03-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-03-26 15:53:21 +0100) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.13-2021-04-01 for you to fetch changes up to ef95d2a98d642a537190d73c45ae3c308afee890: drm/amdgpu/display: fix warning on 32 bit in dmub (2021-04-01 17:32:32 -0400) amd-drm-next-5.13-2021-04-01: amdgpu: - Re-enable GPU reset on VanGogh - Enable DPM flags for SMART_SUSPEND and MAY_SKIP_RESUME - Disentangle HG from vga_switcheroo - S0ix fixes - W=1 fixes - Resource iterator fixes - DMCUB updates - UBSAN fixes - More PM API cleanup - Aldebaran updates - Modifier fixes - Enable VCN load balancing with asymmetric engines - Rework BO structs - Aldebaran reset support - Initial LTTPR display work - Display MALL fixes - Fall back to YCbCr420 when YCbCr444 fails - SR-IOV fixes - Misc cleanups and fixes radeon: - Typo fixes ttm: - Handle cached requests (required for Aldebaran) scheduler: - Fix runqueue selection when changing priorities (required to fix VCN load balancing) Alex Deucher (20): drm/amdgpu/display/dm: add missing parameter documentation drm/amdgpu: Add additional Sienna Cichlid PCI ID drm/amdgpu: add a dev_pm_ops prepare callback (v2) drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and DPM_FLAG_SMART_SUSPEND flags (v2) drm/amdgpu: disentangle HG systems from vgaswitcheroo drm/amdgpu: rework S3/S4/S0ix state handling drm/amdgpu: don't evict vram on APUs for suspend to ram (v4) drm/amdgpu: clean up non-DC suspend/resume handling drm/amdgpu: move s0ix check into amdgpu_device_ip_suspend_phase2 (v3) drm/amdgpu: re-enable suspend phase 2 for S0ix drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend drm/amdgpu: update comments about s0ix suspend/resume drm/amdgpu: drop S0ix checks around CG/PG in suspend drm/amdgpu: skip kfd suspend/resume for S0ix drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x drm/amdgpu/display: fix memory leak for dimgrey cavefish drm/amdgpu/pm: mark pcie link/speed arrays as const drm/amdgpu/pm: bail on sysfs/debugfs queries during platform suspend drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in suspend drm/amdgpu/display: fix warning on 32 bit in dmub Alex Sierra (2): drm/amdgpu: replace per_device_list by array drm/amdgpu: ih reroute for newer asics than vega20 Alvin Lee (1): drm/amd/display: Change input parameter for set_drr Anson Jacob (2): drm/amd/display: Fix UBSAN: shift-out-of-bounds warning drm/amd/display: Removing unused code from dmub_cmd.h Anthony Koo (2): drm/amd/display: [FW Promotion] Release 0.0.57 drm/amd/display: [FW Promotion] Release 0.0.58 Aric Cyr (2): drm/amd/display: 3.2.128 drm/amd/display: 3.2.129 Arnd Bergmann (3): amdgpu: avoid incorrect %hu format string amdgpu: fix gcc -Wrestrict warning amdgpu: securedisplay: simplify i2c hexdump output Bhaskar Chowdhury (6): drm/amdgpu: Fix a typo drm/amdgpu: Fix a typo drm/atomic: Couple of typo fixes drm/radeon/r600_cs: Few typo fixes drm/amd/amdgpu/gfx_v7_0: Trivial typo fixes drm/amd: Fix a typo in two different sentences Bindu Ramamurthy (1): drm/amd/display: Allow idle optimization based on vblank. Chengming Gui (1): drm/amd/amdgpu: set MP1 state to UNLOAD before reload its FW for vega20/ALDEBARAN Chris Park (1): drm/amd/display: Disable MALL when SMU not present Christian König (5): drm/amdgpu: remove irq_src->data handling drm/amdgpu: add the sched_score to amdgpu_ring_init drm/amdgpu: share scheduler score on VCN3 instances drm/sched: select new rq even if there is only one v3 drm/amdgpu: load balance VCN3 decode as well v8 Daniel Gomez (2): drm/amdgpu/ttm: Fix memory leak userptr pages drm/radeon/ttm: Fix memory leak userptr pages David Galiffi (1): drm/amd/display: Fixed Clock Recovery Sequence Dennis Li (1): drm/amdgpu: add codes to capture invalid hardware access when recovery Diego Viola (1): drm/amd/display: fix typo: liason -> liaison Dmytro Laktyushkin (3): drm/amd/display: hide VGH asic specific structs drm/amd/display: revert max lb lines change drm/amd/display: revert max lb use by default for n10 Eryk Brol (1): drm/amd/display: Fix MST topology debugfs Evan Quan (9): drm/amd/pm: fix Navi1x runtime resume failure V2 drm/amd/pm: make DAL co
Re: [PATCH 19/34] drm/amdkfd: HMM migrate vram to ram
Hi Felix,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20210331]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
drm/drm-next v5.12-rc5 v5.12-rc4 v5.12-rc3 v5.12-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
base:7a43c78d0573e00456b033e2b9a895b89464
config: x86_64-randconfig-a011-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/31c45957000fde18a71d7e93c0d6be26bc45a239
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Felix-Kuehling/Add-HMM-based-SVM-memory-manager-to-KFD-v3/20210401-122712
git checkout 31c45957000fde18a71d7e93c0d6be26bc45a239
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c:194:1: warning: no
previous prototype for 'svm_migrate_copy_done' [-Wmissing-prototypes]
194 | svm_migrate_copy_done(struct amdgpu_device *adev, struct dma_fence
*mfence)
| ^
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c:283:6: warning: no
>> previous prototype for 'svm_migrate_put_sys_page' [-Wmissing-prototypes]
283 | void svm_migrate_put_sys_page(unsigned long addr)
| ^~~~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c: In function
'svm_migrate_fini':
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c:875:2: error: implicit
declaration of function 'memunmap_pages'; did you mean 'memcmp_pages'?
[-Werror=implicit-function-declaration]
875 | memunmap_pages(&adev->kfd.dev->pgmap);
| ^~
| memcmp_pages
cc1: some warnings being treated as errors
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for DEVICE_PRIVATE
Depends on ZONE_DEVICE
Selected by
- HSA_AMD && HAS_IOMEM && DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
vim +/svm_migrate_put_sys_page +283
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c
282
> 283 void svm_migrate_put_sys_page(unsigned long addr)
284 {
285 struct page *page;
286
287 page = pfn_to_page(addr >> PAGE_SHIFT);
288 unlock_page(page);
289 put_page(page);
290 }
291
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/9] dt-bindings: display/panel: add Jenson JT60249-01
Add DT binding for "jenson,jt60249-01". Signed-off-by: Giulio Benetti Acked-by: Rob Herring --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 35c335aa085e..68eaa353be0d 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -172,6 +172,8 @@ properties: - jenson,jt60245-01 # Jenson Display JT60248-01 4,3" (480x272) TFT LCD panel - jenson,jt60248-01 +# Jenson Display JT60249-01 5" (800x480) TFT LCD panel + - jenson,jt60249-01 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel - kingdisplay,kd116n21-30nv-a010 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/9] dt-bindings: display/panel: add Jenson JT60248-01
Add DT binding for "jenson,jt60248-01". Signed-off-by: Giulio Benetti Acked-by: Rob Herring --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index ce41a589a3f4..35c335aa085e 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -170,6 +170,8 @@ properties: - innolux,zj070na-01p # Jenson Display JT60245-01 7" (800x480) TFT LCD panel - jenson,jt60245-01 +# Jenson Display JT60248-01 4,3" (480x272) TFT LCD panel + - jenson,jt60248-01 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel - kingdisplay,kd116n21-30nv-a010 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/9] drm/panel: simple: add Jenson JT60245-01
This patch adds support for Jenson JT60245-01 800x480 7" panel to DRM
simple panel driver.
Signed-off-by: Giulio Benetti
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4e2dad314c79..f63fa75ae4ef 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2532,6 +2532,30 @@ static const struct panel_desc ivo_m133nwf4_r0 = {
.connector_type = DRM_MODE_CONNECTOR_eDP,
};
+static const struct drm_display_mode jenson_jt60245_01_mode = {
+ .clock = 35000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 210,
+ .hsync_end = 800 + 210 + 20,
+ .htotal = 800 + 210 + 20 + 46,
+ .vdisplay = 480,
+ .vsync_start = 480 + 22,
+ .vsync_end = 480 + 22 + 10,
+ .vtotal = 480 + 22 + 10 + 23,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60245_01 = {
+ .modes = &jenson_jt60245_01_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+};
+
static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4301,6 +4325,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "ivo,m133nwf4-r0",
.data = &ivo_m133nwf4_r0,
+ }, {
+ .compatible = "jenson,jt60245-01",
+ .data = &jenson_jt60245_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = &kingdisplay_kd116n21_30nv_a010,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/9] Add 4 Jenson simple panels
This patchset introduce Jenson vendor and add 4 of its panels to panel-simple driver. --- V2-V3: * changed my SoB and authorship * added some forgotten acked-by * fixed alpha-numeric order on adding bindings --- Giulio Benetti (9): dt-bindings: Add Jenson Display vendor prefix dt-bindings: display/panel: add Jenson JT60245-01 dt-bindings: display/panel: add Jenson JT60248-01 dt-bindings: display/panel: add Jenson JT60249-01 dt-bindings: display/panel: add Jenson JT60250-02 drm/panel: simple: add Jenson JT60245-01 drm/panel: simple: add Jenson JT60248-01 drm/panel: simple: add Jenson JT60249-01 drm/panel: simple: add Jenson JT60250-02 .../bindings/display/panel/panel-simple.yaml | 8 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/gpu/drm/panel/panel-simple.c | 108 ++ 3 files changed, 118 insertions(+) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/9] drm/panel: simple: add Jenson JT60249-01
This patch adds support for Jenson JT60249-01 800x480 5" panel to DRM
simple panel driver.
Signed-off-by: Giulio Benetti
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f96f820a890b..1966ace764c3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2580,6 +2580,30 @@ static const struct panel_desc jenson_jt60248_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
};
+static const struct drm_display_mode jenson_jt60249_01_mode = {
+ .clock = 25000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 8,
+ .hsync_end = 800 + 8 + 4,
+ .htotal = 800 + 8 + 4 + 8,
+ .vdisplay = 480,
+ .vsync_start = 480 + 8,
+ .vsync_end = 480 + 8 + 4,
+ .vtotal = 480 + 8 + 4 + 8,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60249_01 = {
+ .modes = &jenson_jt60249_01_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 108,
+ .height = 65,
+ },
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4355,6 +4379,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60248-01",
.data = &jenson_jt60248_01,
+ }, {
+ .compatible = "jenson,jt60249-01",
+ .data = &jenson_jt60249_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = &kingdisplay_kd116n21_30nv_a010,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/9] drm/panel: simple: add Jenson JT60248-01
This patch adds support for Jenson JT60248-01 480x272 4.3" panel to DRM
simple panel driver.
Signed-off-by: Giulio Benetti
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f63fa75ae4ef..f96f820a890b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2556,6 +2556,30 @@ static const struct panel_desc jenson_jt60245_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
};
+static const struct drm_display_mode jenson_jt60248_01_mode = {
+ .clock = 9000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 8,
+ .hsync_end = 480 + 8 + 4,
+ .htotal = 480 + 8 + 4 + 43,
+ .vdisplay = 272,
+ .vsync_start = 272 + 8,
+ .vsync_end = 272 + 8 + 4,
+ .vtotal = 272 + 8 + 4 + 12,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60248_01 = {
+ .modes = &jenson_jt60248_01_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 95,
+ .height = 54,
+ },
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4328,6 +4352,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60245-01",
.data = &jenson_jt60245_01,
+ }, {
+ .compatible = "jenson,jt60248-01",
+ .data = &jenson_jt60248_01,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = &kingdisplay_kd116n21_30nv_a010,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/9] dt-bindings: Add Jenson Display vendor prefix
Update Documentation/devicetree/bindings/vendor-prefixes.yaml to include "jenson" as a vendor prefix for "Jenson Display". Company website: http://www.jensondisplay.com/ Signed-off-by: Giulio Benetti Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index f6064d84a424..a1312637d6ff 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -553,6 +553,8 @@ patternProperties: description: Japan Display Inc. "^jedec,.*": description: JEDEC Solid State Technology Association + "^jenson,.*": +description: Jenson Display "^jesurun,.*": description: Shenzhen Jesurun Electronics Business Dept. "^jianda,.*": -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/9] dt-bindings: display/panel: add Jenson JT60250-02
Add DT binding for "jenson,jt60250-02". Signed-off-by: Giulio Benetti Acked-by: Rob Herring --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 68eaa353be0d..cd2f4421de7e 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -174,6 +174,8 @@ properties: - jenson,jt60248-01 # Jenson Display JT60249-01 5" (800x480) TFT LCD panel - jenson,jt60249-01 +# Jenson Display JT60250-02 10.1" (1024x600) TFT LCD panel + - jenson,jt60250-02 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel - kingdisplay,kd116n21-30nv-a010 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/9] dt-bindings: display/panel: add Jenson JT60245-01
Add DT binding for "jenson,jt60245-01". Signed-off-by: Giulio Benetti --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 62b0d54d87b7..ce41a589a3f4 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -168,6 +168,8 @@ properties: - innolux,n156bge-l21 # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel - innolux,zj070na-01p +# Jenson Display JT60245-01 7" (800x480) TFT LCD panel + - jenson,jt60245-01 # King & Display KD116N21-30NV-A010 eDP TFT LCD panel - kingdisplay,kd116n21-30nv-a010 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 9/9] drm/panel: simple: add Jenson JT60250-02
This patch adds support for Jenson JT60250-02 1024x600 10.1" panel to DRM
simple panel driver.
Signed-off-by: Giulio Benetti
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 1966ace764c3..2ebfe529e0c7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2604,6 +2604,30 @@ static const struct panel_desc jenson_jt60249_01 = {
.bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
};
+static const struct drm_display_mode jenson_jt60250_02_mode = {
+ .clock = 51000,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 160,
+ .hsync_end = 1204 + 160 + 10,
+ .htotal = 1024 + 160 + 10 + 160,
+ .vdisplay = 600,
+ .vsync_start = 600 + 12,
+ .vsync_end = 600 + 12 + 70,
+ .vtotal = 600 + 12 + 70 + 23,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc jenson_jt60250_02 = {
+ .modes = &jenson_jt60250_02_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 223,
+ .height = 125,
+ },
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
static const struct drm_display_mode kingdisplay_kd116n21_30nv_a010_mode = {
.clock = 81000,
.hdisplay = 1366,
@@ -4382,6 +4406,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "jenson,jt60249-01",
.data = &jenson_jt60249_01,
+ }, {
+ .compatible = "jenson,jt60250-02",
+ .data = &jenson_jt60250_02,
}, {
.compatible = "kingdisplay,kd116n21-30nv-a010",
.data = &kingdisplay_kd116n21_30nv_a010,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[X11][Question] Any plan on explicit synchronization for X11?
Hi guys, I have some interest to enable explicit sync for X11, so send a draft MR to collect feedback: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/34 As no comments on the gitlab MR, send this to mailing list and hope to hear some voice. If NAKed early, it will save me a bunch of time. Thanks, Qiang ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/5] drm/bridge: anx7625: add HDCP support
On Mon, Mar 29, 2021 at 02:02:08PM -0400, Sean Paul wrote:
> On Mon, Mar 29, 2021 at 6:27 AM Xin Ji wrote:
> >
> > On Thu, Mar 25, 2021 at 02:19:23PM -0400, Sean Paul wrote:
> > > On Fri, Mar 19, 2021 at 2:35 AM Xin Ji wrote:
> > > >
> > > > Add HDCP feature, enable HDCP function through chip internal key
> > > > and downstream's capability.
> > > >
> > > > Signed-off-by: Xin Ji
> > > > ---
>
> /snip
>
> > > > static void anx7625_dp_start(struct anx7625_data *ctx)
> > > > {
> > > > int ret;
> > > > @@ -643,6 +787,9 @@ static void anx7625_dp_start(struct anx7625_data
> > > > *ctx)
> > > > return;
> > > > }
> > > >
> > > > + /* HDCP config */
> > > > + anx7625_hdcp_setting(ctx);
> > >
> > > You should really use the "Content Protection" property to
> > > enable/disable HDCP instead of force-enabling it at all times.
> > >
> > > Sean
> > Hi Sean, it's hard to implement "Content Protection" property, we have
> > implemented HDCP in firmware, it is not compatible with it. We don't
> > have interface to get Downstream Cert.
> > Thanks,
> > Xin
>
> Hi Xin,
> I'm sorry, I don't understand what you mean when you say you don't
> have an interface to get Downstream Cert.
>
> The Content Protection property is just a means through which
> userspace can turn on and turn off HDCP when it needs. As far as I can
> tell, your patch turns on HDCP when the display is enabled and leaves
> it on until it is disabled. This is undesirable since it forces HDCP
> on the user.
>
> Is it impossible to enable/disable HDCP outside of display
> enable/disable on your hardware?
>
> Thanks,
>
> Sean
Hi Sean, I have commit a test patch on google review site, can you
please help to review it? I'll use Connector's ".atomic_check()"
interface to detect Content Protection property change.
(https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2674580)
Thanks,
Xin
>
> > >
> > > > +
> > > > if (ctx->pdata.is_dpi)
> > > > ret = anx7625_dpi_config(ctx);
> > > > else
>
> /snip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/5] dt-bindings:drm/bridge:anx7625:add vendor define flags
On Thu, Apr 01, 2021 at 02:33:47PM +0200, Robert Foss wrote:
> Hey Xin,
>
> This series no longer applies to drm-misc/drm-misc-next, please rebase it.
Hi Robert Foss, OK, I'll rebase it on the drm-misc-next after confirmed
HDCP patch with Sean Paul.
Thanks,
Xin
>
> On Wed, 24 Mar 2021 at 08:52, Xin Ji wrote:
> >
> > On Sun, Mar 21, 2021 at 02:00:38PM +0200, Laurent Pinchart wrote:
> > > Hi Xin,
> > >
> > > Thank you for the patch.
> > >
> > > On Fri, Mar 19, 2021 at 02:32:39PM +0800, Xin Ji wrote:
> > > > Add 'bus-type' and 'data-lanes' define for port0. Define DP tx lane0,
> > > > lane1 swing register array define, and audio enable flag.
> > > >
> > > > Signed-off-by: Xin Ji
> > > > ---
> > > > .../display/bridge/analogix,anx7625.yaml | 58 ++-
> > > > 1 file changed, 57 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > >
> > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > index c789784efe30..3f54d5876982 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > +++
> > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > @@ -34,6 +34,26 @@ properties:
> > > > description: used for reset chip control, RESET_N pin B7.
> > > > maxItems: 1
> > > >
> > > > + analogix,lane0-swing:
> > > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > > > +minItems: 1
> > > > +maxItems: 20
> > > > +description:
> > > > + an array of swing register setting for DP tx lane0 PHY, please
> > > > don't
> > > > + add this property, or contact vendor.
> > >
> > > DT properties need to be documented. Contacting the vendor doesn't count
> > > as documentation I'm afraid.
> >
> > Hi Laurent Pinchart, thanks for your comment. For the DP phy swing
> > setting, it is hard to describe in here, needs to refer the anx7625
> > datasheet and programming guide. Basically, no need to change the DP phy
> > swing setting.
> >
>
> Laurent is right. But if the value practically is a constant, you can
> move the swing register into the driver. It should still be documented
> as well as possible, but we can be a little bit more flexible.
>
> > > > @@ -73,6 +123,10 @@ examples:
> > > > enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> > > > reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> > > >
> > > > +analogix,audio-enable;
> > > > +analogix,lane0-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77
> > > > 0x5b>;
> > > > +analogix,lane1-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77
> > > > 0x5b>;
> > > > +
> > > > ports {
> > > > #address-cells = <1>;
> > > > #size-cells = <0>;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Fix a potential sdma invalid access
Before dma_resv_lock(bo->base.resv, NULL) in amdgpu_bo_release_notify(),
the bo->base.resv lock may be held by ttm_mem_evict_first(),
and the VRAM mem will be evicted, mem region was replaced
by Gtt mem region. amdgpu_bo_release_notify() will then
hold the bo->base.resv lock, and SDMA will get an invalid
address in amdgpu_fill_buffer(), resulting in a VMFAULT
or memory corruption.
To avoid it, we have to hold bo->base.resv lock first, and
check whether the mem.mem_type is TTM_PL_VRAM.
Signed-off-by: Qu Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 4b29b82..8018574 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1300,12 +1300,16 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object
*bo)
if (bo->base.resv == &bo->base._resv)
amdgpu_amdkfd_remove_fence_on_pt_pd_bos(abo);
- if (bo->mem.mem_type != TTM_PL_VRAM || !bo->mem.mm_node ||
- !(abo->flags & AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE))
+ if (!(abo->flags & AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE))
return;
dma_resv_lock(bo->base.resv, NULL);
+ if (bo->mem.mem_type != TTM_PL_VRAM || !bo->mem.mm_node) {
+ dma_resv_unlock(bo->base.resv);
+ return;
+ }
+
r = amdgpu_fill_buffer(abo, AMDGPU_POISON, bo->base.resv, &fence);
if (!WARN_ON(r)) {
amdgpu_bo_fence(abo, fence, false);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: optimize the pool shrinker a bit
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next next-20210401]
[cannot apply to drm-intel/for-linux-next linus/master drm/drm-next v5.12-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-optimize-the-pool-shrinker-a-bit/20210401-215623
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a004-20210401 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
1c268a8ff4e90a85d0e634350b1104080614cf2b)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/c0f3e98ef4f78d5e9d874be1f339186faf5c60bc
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/drm-ttm-optimize-the-pool-shrinker-a-bit/20210401-215623
git checkout c0f3e98ef4f78d5e9d874be1f339186faf5c60bc
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> mm/vmscan.c:415: warning: expecting prototype for sync_shrinker(). Prototype
>> was for sync_shrinkers() instead
mm/vmscan.c:1627: warning: wrong kernel-doc identifier on line:
* Isolating page from the lruvec to fill in @dst list by nr_to_scan times.
vim +415 mm/vmscan.c
410
411 /**
412 * sync_shrinker - Wait for all running shrinkers to complete.
413 */
414 void sync_shrinkers(void)
> 415 {
416 down_write(&shrinker_rwsem);
417 up_write(&shrinker_rwsem);
418 }
419 EXPORT_SYMBOL(sync_shrinkers);
420
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
