Re: [PATCH v2 4/8] dt-bindings: phy: convert HDMI PHY binding to YAML schema
Hi, Chunfeng:
On Tue, 2020-10-13 at 16:52 +0800, Chunfeng Yun wrote:
> Convert HDMI PHY binding to YAML schema mediatek,ufs-phy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v2: fix binding check warning of reg in example
> ---
> .../display/mediatek/mediatek,hdmi.txt| 17 +---
> .../bindings/phy/mediatek,hdmi-phy.yaml | 90 +++
> 2 files changed, 91 insertions(+), 16 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> index 7b124242b0c5..edac18951a75 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> @@ -50,22 +50,7 @@ Required properties:
>
> HDMI PHY
>
> -
> -The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
> -output and drives the HDMI pads.
> -
> -Required properties:
> -- compatible: "mediatek,-hdmi-phy"
> -- reg: Physical base address and length of the module's registers
> -- clocks: PLL reference clock
> -- clock-names: must contain "pll_ref"
> -- clock-output-names: must be "hdmitx_dig_cts" on mt8173
> -- #phy-cells: must be <0>
> -- #clock-cells: must be <0>
> -
> -Optional properties:
> -- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
> -- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
> +See phy/mediatek,hdmi-phy.yaml
>
> Example:
>
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
> b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
> new file mode 100644
> index ..77df50204606
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/mediatek,hdmi-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek High Definition Multimedia Interface (HDMI) PHY binding
> +
> +maintainers:
> + - CK Hu
I think you should remove "CK Hu " and add latest
mediatek drm maintainer:
DRM DRIVERS FOR MEDIATEK
M: Chun-Kuang Hu
M: Philipp Zabel
L: dri-devel@lists.freedesktop.org
S: Supported
F: Documentation/devicetree/bindings/display/mediatek/
F: drivers/gpu/drm/mediatek/
Regards,
CK
> + - Chunfeng Yun
> +
> +description: |
> + The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
> + output and drives the HDMI pads.
> +
> +properties:
> + $nodename:
> +pattern: "^hdmi-phy@[0-9a-f]+$"
> +
> + compatible:
> +enum:
> + - mediatek,mt2701-hdmi-phy
> + - mediatek,mt8173-hdmi-phy
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: PLL reference clock
> +
> + clock-names:
> +items:
> + - const: pll_ref
> +
> + clock-output-names:
> +items:
> + - const: hdmitx_dig_cts
> +
> + "#phy-cells":
> +const: 0
> +
> + "#clock-cells":
> +const: 0
> +
> + mediatek,ibias:
> +description:
> + TX DRV bias current for < 1.65Gbps
> +$ref: /schemas/types.yaml#/definitions/uint32
> +minimum: 0
> +maximum: 63
> +default: 0xa
> +
> + mediatek,ibias_up:
> +description:
> + TX DRV bias current for >= 1.65Gbps
> +$ref: /schemas/types.yaml#/definitions/uint32
> +minimum: 0
> +maximum: 63
> +default: 0x1c
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - clock-output-names
> + - "#phy-cells"
> + - "#clock-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +hdmi_phy: hdmi-phy@10209100 {
> +compatible = "mediatek,mt8173-hdmi-phy";
> +reg = <0x10209100 0x24>;
> +clocks = < CLK_APMIXED_HDMI_REF>;
> +clock-names = "pll_ref";
> +clock-output-names = "hdmitx_dig_cts";
> +mediatek,ibias = <0xa>;
> +mediatek,ibias_up = <0x1c>;
> +#clock-cells = <0>;
> +#phy-cells = <0>;
> +};
> +
> +...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [2/2] drm/msm: Add support for GPU cooling
On Wed, Oct 14, 2020 at 12:51:55AM +0530, Akhil P Oommen wrote:
> On 10/13/2020 11:10 PM, m...@chromium.org wrote:
> > On Tue, Oct 13, 2020 at 07:23:34PM +0530, Akhil P Oommen wrote:
> > > On 10/12/2020 11:10 PM, m...@chromium.org wrote:
> > > > On Mon, Oct 12, 2020 at 07:03:51PM +0530, Akhil P Oommen wrote:
> > > > > On 10/10/2020 12:06 AM, m...@chromium.org wrote:
> > > > > > Hi Akhil,
> > > > > >
> > > > > > On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
> > > > > > > Register GPU as a devfreq cooling device so that it can be
> > > > > > > passively
> > > > > > > cooled by the thermal framework.
> > > > > > >
> > > > > > > Signed-off-by: Akhil P Oommen
> > > > > > > ---
> > > > > > > drivers/gpu/drm/msm/msm_gpu.c | 13 -
> > > > > > > drivers/gpu/drm/msm/msm_gpu.h | 2 ++
> > > > > > > 2 files changed, 14 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/msm/msm_gpu.c
> > > > > > > b/drivers/gpu/drm/msm/msm_gpu.c
> > > > > > > index 55d1648..93ffd66 100644
> > > > > > > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > > > > > > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > > > > > > @@ -14,6 +14,7 @@
> > > > > > > #include
> > > > > > > #include
> > > > > > > #include
> > > > > > > +#include
> > > > > > > #include
> > > > > > > #include
> > > > > > > @@ -107,9 +108,18 @@ static void msm_devfreq_init(struct msm_gpu
> > > > > > > *gpu)
> > > > > > > if (IS_ERR(gpu->devfreq.devfreq)) {
> > > > > > > DRM_DEV_ERROR(>pdev->dev, "Couldn't
> > > > > > > initialize GPU devfreq\n");
> > > > > > > gpu->devfreq.devfreq = NULL;
> > > > > > > + return;
> > > > > > > }
> > > > > > > devfreq_suspend_device(gpu->devfreq.devfreq);
> > > > > > > +
> > > > > > > + gpu->cooling =
> > > > > > > of_devfreq_cooling_register(gpu->pdev->dev.of_node,
> > > > > > > + gpu->devfreq.devfreq);
> > > > > > > + if (IS_ERR(gpu->cooling)) {
> > > > > > > + DRM_DEV_ERROR(>pdev->dev,
> > > > > > > + "Couldn't register GPU cooling
> > > > > > > device\n");
> > > > > > > + gpu->cooling = NULL;
> > > > > > > + }
> > > > > > > }
> > > > > > > static int enable_pwrrail(struct msm_gpu *gpu)
> > > > > > > @@ -926,7 +936,6 @@ int msm_gpu_init(struct drm_device *drm,
> > > > > > > struct platform_device *pdev,
> > > > > > > msm_devfreq_init(gpu);
> > > > > > > -
> > > Will remove this unintended change.
> > > > > > > gpu->aspace = gpu->funcs->create_address_space(gpu,
> > > > > > > pdev);
> > > > > > > if (gpu->aspace == NULL)
> > > > > > > @@ -1005,4 +1014,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
> > > > > > >
> > > > > > > gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu);
> > > > > > > msm_gem_address_space_put(gpu->aspace);
> > > > > > > }
> > > > > > > +
> > > > > > > + devfreq_cooling_unregister(gpu->cooling);
> > > > > >
> > > > > > Resources should be released in reverse order, otherwise the
> > > > > > cooling device
> > > > > > could use resources that have already been freed.
> > > > > > Why do you think this is not the correct order? If you are thinking
> > > > > about devfreq struct, it is managed device resource.
> > > >
> > > > I did not check specifically if changing the frequency really uses any
> > > > of the
> > > > resources that are released previously, In any case it's not a good
> > > > idea to
> > > > allow other parts of the kernel to use a half initialized/torn down
> > > > device.
> > > > Even if it isn't a problem today someone could change the driver to use
> > > > any
> > > > of these resources (or add a new one) in a frequency change, without
> > > > even
> > > > thinking about the cooling device, just (rightfully) asuming that
> > > > things are
> > > > set up and torn down in a sane order.
> > > 'sane order' relative to what specifically here? Should we worry about
> > > freq
> > > change at this point because we have already disabled gpu runtime pm and
> > > devfreq?
> >
> > GPU runtime PM and the devfreq being disabled is not evident from the
> > context
> > of the function. You are probably right that it's not a problem in practice,
> > but why give reason for doubts in the first place if this could be avoided
> > by following a common practice?
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> Other option I see is to create a managed device resource (devm) version of
> the devfreq_cooling_register API and use that. Is that what you are trying
> to suggest?
No, I was not thinking about a devm version, just manual reverse removal.
Actually you can even argue the you are using the right order, I saw the
ring buffer and the address space are actually
Re: [PATCH v2 2/2] drm/mediatek: mtk_hdmi: add MT8167 support for HDMI
Hi, Fabien:
Fabien Parent 於 2020年10月14日 週三 上午2:19寫道：
>
> Add support for HDMI on MT8167. HDMI on MT8167 is similar to
> MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
>
> Signed-off-by: Fabien Parent
> ---
>
> Changelog:
> v2: fix name of pdata structure
>
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +++
> drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 57370c036497..484ea9cd654a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1835,9 +1835,16 @@ static struct mtk_hdmi_data mt8173_hdmi_driver_data = {
> .sys_cfg20 = HDMI_SYS_CFG20,
> };
>
> +static struct mtk_hdmi_data mt8167_hdmi_driver_data = {
> + .sys_cfg1c = MT8167_HDMI_SYS_CFG1C,
> + .sys_cfg20 = MT8167_HDMI_SYS_CFG20,
> +};
> +
> static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
> { .compatible = "mediatek,mt8173-hdmi",
> .data = _hdmi_driver_data },
> + { .compatible = "mediatek,mt8167-hdmi",
I think we should add this compatible string in Mediatek HDMI binding
document [1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt?h=v5.9
Regards,
Chun-Kuang.
> + .data = _hdmi_driver_data },
> {}
> };
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> index 2050ba45b23a..a0f9c367d7aa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> @@ -195,6 +195,7 @@
> #define GEN_RGB(0 << 7)
>
> #define HDMI_SYS_CFG1C 0x000
> +#define MT8167_HDMI_SYS_CFG1C 0x800
> #define HDMI_ONBIT(0)
> #define HDMI_RST BIT(1)
> #define ANLG_ONBIT(2)
> @@ -211,6 +212,7 @@
> #define HTPLG_PIN_SEL_OFF BIT(30)
> #define AES_EFUSE_ENABLE BIT(31)
> #define HDMI_SYS_CFG20 0x004
> +#define MT8167_HDMI_SYS_CFG20 0x804
> #define DEEP_COLOR_MODE_MASK (3 << 1)
> #define COLOR_8BIT_MODE(0 << 1)
> #define COLOR_10BIT_MODE (1 << 1)
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v9 1/5] dt-bindings: display: Add support for Intel KeemBay Display
> -Original Message- > From: dri-devel On Behalf Of Rob > Herring > Sent: Tuesday, October 13, 2020 8:43 AM > To: Chrisanthus, Anitha > Cc: devicet...@vger.kernel.org; Neil Armstrong ; > Dea, Edmund J ; dri-devel@lists.freedesktop.org; > Vetter, Daniel ; s...@ravnborg.org > Subject: Re: [PATCH v9 1/5] dt-bindings: display: Add support for Intel > KeemBay > Display > > On Tue, Oct 13, 2020 at 12:24:38AM +, Chrisanthus, Anitha wrote: > > Hi Neil, > > > > Thanks for your review, please see my reply inline. > > > > > -Original Message- > > > From: Neil Armstrong > > > Sent: Friday, October 9, 2020 2:10 AM > > > To: Chrisanthus, Anitha ; dri- > > > de...@lists.freedesktop.org; devicet...@vger.kernel.org; Vetter, Daniel > > > > > > Cc: Dea, Edmund J ; s...@ravnborg.org > > > Subject: Re: [PATCH v9 1/5] dt-bindings: display: Add support for Intel > > > KeemBay Display > > > > > > Hi, > > > > > > On 09/10/2020 03:03, Anitha Chrisanthus wrote: > > > > This patch adds bindings for Intel KeemBay Display > > > > > > > > v2: review changes from Rob Herring > > > > > > > > Signed-off-by: Anitha Chrisanthus > > > > --- > > > > .../bindings/display/intel,keembay-display.yaml| 99 > > > ++ > > > > 1 file changed, 99 insertions(+) > > > > create mode 100644 > > > Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/intel,keembay- > > > display.yaml b/Documentation/devicetree/bindings/display/intel,keembay- > > > display.yaml > > > > new file mode 100644 > > > > index 000..a38493d > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/intel,keembay- > > > display.yaml > > > > @@ -0,0 +1,99 @@ > > > > +# SPDX-License-Identifier: GPL-2.0-only > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/intel,keembay- > > > display.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Devicetree bindings for Intel Keem Bay display controller > > > > + > > > > +maintainers: > > > > + - Anitha Chrisanthus > > > > + - Edmond J Dea > > > > + > > > > +properties: > > > > + compatible: > > > > +const: intel,kmb_display > > > > + > > > > + reg: > > > > +items: > > > > + - description: Lcd registers range > > > > + - description: Mipi registers range > > > > > > Looking at the registers, the MIPI transceiver seems to be a separate IP, > > > same for D-PHY which should have a proper PHY driver instead of beeing > > > handled > > > here. > > > > > The LCD, MIPI DSI, DPHY and MSSCAM as a group, are considered the > > display subsystem for Keem Bay. As such, there are several > > interdependencies that make splitting them up next to impossible and > > Please detail what those inter-dependencies are. It's doubtful that you > have anything we have not had to deal with in other SoCs. > > > currently we do not have the resources available for that effort. > > That is certainly not justification for accepting this. > > Rob Hi Rob, the wording was probably a bit exaggerated and you're right in that there it's not unique from a hardware perspective. The problem we have (and I know, it's our problem, not yours) is that our program required us to develop this internally first and then try to upstream it. So now that we've put a large effort into developing and testing the driver, it's very difficult for us to justify the resources to re-design it to better match the design of other SOC display drivers. We did review other SOC display drivers before creating this and thought that we were following the best practices for the design. I fully agree that lack of resources is not justification for not fixing something broken. But on the flip side, neither is changing the design because it could be "better" justification for not accepting it. If there is something wrong with the driver and it will cause problems in the future, then please, let us know. That would provide the data needed to justify additional effort. Bob > ___ > 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 2/3] drm/ingenic: Reset pixclock rate when parent clock rate changes
Quoting Paul Cercueil (2020-09-25 05:29:12)
> >> +static int ingenic_drm_update_pixclk(struct notifier_block *nb,
> >> +unsigned long action,
> >> +void *data)
> >> +{
> >> + struct ingenic_drm *priv = drm_nb_get_priv(nb);
> >> +
> >> + switch (action) {
> >> + case PRE_RATE_CHANGE:
> >> + mutex_lock(>clk_mutex);
> >> + priv->update_clk_rate = true;
> >> + drm_crtc_wait_one_vblank(>crtc);
> >> + return NOTIFY_OK;
> >> + default:
> >> + mutex_unlock(>clk_mutex);
> > Any risk the POST_RATE_CHANGE or ABORT_RATE_CHANGE may go missing so
> > we
> > fail to unlock the mutex?
> > I think not but wanted to make sure you had thought about it.
>
> My assumption was that you always get POST_RATE_CHANGE or
> ABORT_RATE_CHANGE. But I am not 100% sure about that.
>
> Michael, Stephen: is it safe to assume that I will always get notified
> with POST_RATE_CHANGE or ABORT_RATE_CHANGE, after I got notified with
> PRE_RATE_CHANGE?
>
I think one or the other will happen. Of course, the notifiers are sort
of shunned so if you can avoid using notifiers entirely it would be
better.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm/i915/jsl: Split EHL/JSL platform info and PCI ids
On Wed, Oct 14, 2020 at 12:59:48AM +0530, Tejas Upadhyay wrote:
> Recently we came across requirement to identify EHL and JSL
> platform to program them differently. Thus Split the basic
> platform definition, macros, and PCI IDs to differentiate
> between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
> with IS_JSL_EHL everywhere.
>
> Changes since V1 :
> - Rebased to avoid merge conflicts
> - Added missed check for jasperlake in intel_uc_fw.c
>
> Cc : Matt Roper
> Cc : Ville Syrjälä
> Signed-off-by: Tejas Upadhyay
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 8
> drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16
> drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c| 4 ++--
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h| 7 ---
> drivers/gpu/drm/i915/i915_pci.c| 9 +
> drivers/gpu/drm/i915/intel_device_info.c | 1 +
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> drivers/gpu/drm/i915/intel_pch.c | 6 +++---
> include/drm/i915_pciids.h | 9 ++---
> 16 files changed, 54 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 4400e83f783f..096652921453 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -455,7 +455,7 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
> intel_encoder *encoder)
> intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), tmp);
>
> /* For EHL, TGL, set latency optimization for PCS_DW1 lanes */
> - if (IS_ELKHARTLAKE(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
> + if (IS_JSL_EHL(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
> tmp = intel_de_read(dev_priv,
> ICL_PORT_PCS_DW1_AUX(phy));
> tmp &= ~LATENCY_OPTIM_MASK;
> @@ -612,7 +612,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder
> *encoder,
> }
> }
>
> - if (IS_ELKHARTLAKE(dev_priv)) {
> + if (IS_JSL_EHL(dev_priv)) {
> for_each_dsi_phy(phy, intel_dsi->phys) {
> tmp = intel_de_read(dev_priv, ICL_DPHY_CHKN(phy));
> tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 7dbf153279fb..7b46330fa69c 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2588,7 +2588,7 @@ static int intel_compute_max_dotclk(struct
> drm_i915_private *dev_priv)
> */
> void intel_update_max_cdclk(struct drm_i915_private *dev_priv)
> {
> - if (IS_ELKHARTLAKE(dev_priv)) {
> + if (IS_JSL_EHL(dev_priv)) {
> if (dev_priv->cdclk.hw.ref == 24000)
> dev_priv->max_cdclk_freq = 552000;
> else
> @@ -2829,7 +2829,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
> *dev_priv)
> dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
> dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
> dev_priv->cdclk.table = icl_cdclk_table;
> - } else if (IS_ELKHARTLAKE(dev_priv)) {
> + } else if (IS_JSL_EHL(dev_priv)) {
> dev_priv->display.set_cdclk = bxt_set_cdclk;
> dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
> dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 932265f1ac90..d5ad61e4083e 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -188,7 +188,7 @@ static bool has_phy_misc(struct drm_i915_private *i915,
> enum phy phy)
>* PHY-B and may not even have instances of the register for the
>* other combo PHY's.
>*/
> - if (IS_ELKHARTLAKE(i915) ||
> + if (IS_JSL_EHL(i915) ||
> IS_ROCKETLAKE(i915) ||
> IS_DG1(i915))
> return phy < PHY_C;
> @@ -283,7 +283,7 @@ static bool icl_combo_phy_verify_state(struct
> drm_i915_private *dev_priv,
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
>IREFGEN, IREFGEN);
>
> - if
Re: [PATCH RFC PKS/PMEM 24/58] fs/freevxfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 12:25:44PM +0100, Christoph Hellwig wrote: > > - kaddr = kmap(pp); > > + kaddr = kmap_thread(pp); > > memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE); > > - kunmap(pp); > > + kunmap_thread(pp); > > You only Cced me on this particular patch, which means I have absolutely > no idea what kmap_thread and kunmap_thread actually do, and thus can't > provide an informed review. Sorry the list was so big I struggled with who to CC and on which patches. > > That being said I think your life would be a lot easier if you add > helpers for the above code sequence and its counterpart that copies > to a potential hughmem page first, as that hides the implementation > details from most users. Matthew Wilcox and Al Viro have suggested similar ideas. https://lore.kernel.org/lkml/20201013205012.gi2046...@iweiny-desk2.sc.intel.com/ Ira ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 09:01:49PM +0100, Al Viro wrote:
> On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
>
> > static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> > int size)
> > {
> > char *vto = kmap_atomic(to);
> >
> > memcpy(vto, vfrom, size);
> > kunmap_atomic(vto);
> > }
> >
> > in linux/highmem.h ?
>
> You mean, like
> static void memcpy_from_page(char *to, struct page *page, size_t offset,
> size_t len)
> {
> char *from = kmap_atomic(page);
> memcpy(to, from + offset, len);
> kunmap_atomic(from);
> }
>
> static void memcpy_to_page(struct page *page, size_t offset, const char
> *from, size_t len)
> {
> char *to = kmap_atomic(page);
> memcpy(to + offset, from, len);
> kunmap_atomic(to);
> }
>
> static void memzero_page(struct page *page, size_t offset, size_t len)
> {
> char *addr = kmap_atomic(page);
> memset(addr + offset, 0, len);
> kunmap_atomic(addr);
> }
>
> in lib/iov_iter.c? FWIW, I don't like that "highpage" in the name and
> highmem.h as location - these make perfect sense regardless of highmem;
> they are normal memory operations with page + offset used instead of
> a pointer...
I was thinking along those lines as well especially because of the direction
this patch set takes kmap().
Thanks for pointing these out to me. How about I lift them to a common header?
But if not highmem.h where?
Ira
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the over head of global PKRS updates use the new kmap_thread() call.
> > >
> > > Cc: Nicolas Pitre
> > > Signed-off-by: Ira Weiny
> > > ---
> > > fs/cramfs/inode.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> > > index 912308600d39..003c014a42ed 100644
> > > --- a/fs/cramfs/inode.c
> > > +++ b/fs/cramfs/inode.c
> > > @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block
> > > *sb, unsigned int offset,
> > > struct page *page = pages[i];
> > >
> > > if (page) {
> > > - memcpy(data, kmap(page), PAGE_SIZE);
> > > - kunmap(page);
> > > + memcpy(data, kmap_thread(page), PAGE_SIZE);
> > > + kunmap_thread(page);
> >
> > Why does this need a sleepable kmap? This looks like a textbook
> > kmap_atomic() use case.
>
> There's a lot of code of this form. Could we perhaps have:
>
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
Christoph had the same idea. I'll work on it.
Ira
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/24] drm/dp: fix a kernel-doc issue at drm_edid.c
wait, I think there's some confusion here. these patches have already been
pushed
On Tue, 2020-10-13 at 14:14 +0200, Mauro Carvalho Chehab wrote:
> The name of the argument is different, causing those warnings:
>
> ./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member
> 'video_code' not described in 'drm_display_mode_from_cea_vic'
> ./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter
> 'vic' description in 'drm_display_mode_from_cea_vic'
>
> Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a82f37d44258..631125b46e04 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3741,7 +3741,7 @@ drm_add_cmdb_modes(struct drm_connector *connector, u8
> svd)
> /**
> * drm_display_mode_from_cea_vic() - return a mode for CEA VIC
> * @dev: DRM device
> - * @vic: CEA VIC of the mode
> + * @video_code: CEA VIC of the mode
> *
> * Creates a new mode matching the specified CEA VIC.
> *
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 12:37 PM Matthew Wilcox wrote:
>
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the over head of global PKRS updates use the new kmap_thread() call.
> > >
> > > Cc: Nicolas Pitre
> > > Signed-off-by: Ira Weiny
> > > ---
> > > fs/cramfs/inode.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> > > index 912308600d39..003c014a42ed 100644
> > > --- a/fs/cramfs/inode.c
> > > +++ b/fs/cramfs/inode.c
> > > @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block
> > > *sb, unsigned int offset,
> > > struct page *page = pages[i];
> > >
> > > if (page) {
> > > - memcpy(data, kmap(page), PAGE_SIZE);
> > > - kunmap(page);
> > > + memcpy(data, kmap_thread(page), PAGE_SIZE);
> > > + kunmap_thread(page);
> >
> > Why does this need a sleepable kmap? This looks like a textbook
> > kmap_atomic() use case.
>
> There's a lot of code of this form. Could we perhaps have:
>
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
Nice, yes, that could also replace the local ones in lib/iov_iter.c
(memcpy_{to,from}_page())
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/i915/jsl: Split EHL/JSL platform info and PCI ids
Recently we came across requirement to identify EHL and JSL
platform to program them differently. Thus Split the basic
platform definition, macros, and PCI IDs to differentiate
between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
with IS_JSL_EHL everywhere.
Changes since V1 :
- Rebased to avoid merge conflicts
- Added missed check for jasperlake in intel_uc_fw.c
Cc : Matt Roper
Cc : Ville Syrjälä
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 +++---
drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
drivers/gpu/drm/i915/display/intel_display.c | 8
drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c| 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
drivers/gpu/drm/i915/i915_drv.h| 7 ---
drivers/gpu/drm/i915/i915_pci.c| 9 +
drivers/gpu/drm/i915/intel_device_info.c | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_pch.c | 6 +++---
include/drm/i915_pciids.h | 9 ++---
16 files changed, 54 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 4400e83f783f..096652921453 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -455,7 +455,7 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
intel_encoder *encoder)
intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), tmp);
/* For EHL, TGL, set latency optimization for PCS_DW1 lanes */
- if (IS_ELKHARTLAKE(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
+ if (IS_JSL_EHL(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
tmp = intel_de_read(dev_priv,
ICL_PORT_PCS_DW1_AUX(phy));
tmp &= ~LATENCY_OPTIM_MASK;
@@ -612,7 +612,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder *encoder,
}
}
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
for_each_dsi_phy(phy, intel_dsi->phys) {
tmp = intel_de_read(dev_priv, ICL_DPHY_CHKN(phy));
tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 7dbf153279fb..7b46330fa69c 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2588,7 +2588,7 @@ static int intel_compute_max_dotclk(struct
drm_i915_private *dev_priv)
*/
void intel_update_max_cdclk(struct drm_i915_private *dev_priv)
{
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
if (dev_priv->cdclk.hw.ref == 24000)
dev_priv->max_cdclk_freq = 552000;
else
@@ -2829,7 +2829,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
*dev_priv)
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
dev_priv->cdclk.table = icl_cdclk_table;
- } else if (IS_ELKHARTLAKE(dev_priv)) {
+ } else if (IS_JSL_EHL(dev_priv)) {
dev_priv->display.set_cdclk = bxt_set_cdclk;
dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 932265f1ac90..d5ad61e4083e 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -188,7 +188,7 @@ static bool has_phy_misc(struct drm_i915_private *i915,
enum phy phy)
* PHY-B and may not even have instances of the register for the
* other combo PHY's.
*/
- if (IS_ELKHARTLAKE(i915) ||
+ if (IS_JSL_EHL(i915) ||
IS_ROCKETLAKE(i915) ||
IS_DG1(i915))
return phy < PHY_C;
@@ -283,7 +283,7 @@ static bool icl_combo_phy_verify_state(struct
drm_i915_private *dev_priv,
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
IREFGEN, IREFGEN);
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
if (ehl_vbt_ddi_d_present(dev_priv))
expected_val = ICL_PHY_MISC_MUX_DDID;
@@ -377,7 +377,7 @@
Re: [PATCH v2 12/24] drm/dp: fix a kernel-doc issue at drm_edid.c
Reviewed-by: Lyude Paul
Thanks for the fixes! I will go ahead and push 11 and 12 to drm-misc-next.
On Tue, 2020-10-13 at 14:14 +0200, Mauro Carvalho Chehab wrote:
> The name of the argument is different, causing those warnings:
>
> ./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member
> 'video_code' not described in 'drm_display_mode_from_cea_vic'
> ./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter
> 'vic' description in 'drm_display_mode_from_cea_vic'
>
> Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a82f37d44258..631125b46e04 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3741,7 +3741,7 @@ drm_add_cmdb_modes(struct drm_connector *connector, u8
> svd)
> /**
> * drm_display_mode_from_cea_vic() - return a mode for CEA VIC
> * @dev: DRM device
> - * @vic: CEA VIC of the mode
> + * @video_code: CEA VIC of the mode
> *
> * Creates a new mode matching the specified CEA VIC.
> *
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [2/2] drm/msm: Add support for GPU cooling
On 10/13/2020 11:10 PM, m...@chromium.org wrote:
On Tue, Oct 13, 2020 at 07:23:34PM +0530, Akhil P Oommen wrote:
On 10/12/2020 11:10 PM, m...@chromium.org wrote:
On Mon, Oct 12, 2020 at 07:03:51PM +0530, Akhil P Oommen wrote:
On 10/10/2020 12:06 AM, m...@chromium.org wrote:
Hi Akhil,
On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/msm_gpu.c | 13 -
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 55d1648..93ffd66 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -107,9 +108,18 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
if (IS_ERR(gpu->devfreq.devfreq)) {
DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
devfreq\n");
gpu->devfreq.devfreq = NULL;
+ return;
}
devfreq_suspend_device(gpu->devfreq.devfreq);
+
+ gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
+ gpu->devfreq.devfreq);
+ if (IS_ERR(gpu->cooling)) {
+ DRM_DEV_ERROR(>pdev->dev,
+ "Couldn't register GPU cooling device\n");
+ gpu->cooling = NULL;
+ }
}
static int enable_pwrrail(struct msm_gpu *gpu)
@@ -926,7 +936,6 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
msm_devfreq_init(gpu);
-
Will remove this unintended change.
gpu->aspace = gpu->funcs->create_address_space(gpu, pdev);
if (gpu->aspace == NULL)
@@ -1005,4 +1014,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu);
msm_gem_address_space_put(gpu->aspace);
}
+
+ devfreq_cooling_unregister(gpu->cooling);
Resources should be released in reverse order, otherwise the cooling device
could use resources that have already been freed.
Why do you think this is not the correct order? If you are thinking
about devfreq struct, it is managed device resource.
I did not check specifically if changing the frequency really uses any of the
resources that are released previously, In any case it's not a good idea to
allow other parts of the kernel to use a half initialized/torn down device.
Even if it isn't a problem today someone could change the driver to use any
of these resources (or add a new one) in a frequency change, without even
thinking about the cooling device, just (rightfully) asuming that things are
set up and torn down in a sane order.
'sane order' relative to what specifically here? Should we worry about freq
change at this point because we have already disabled gpu runtime pm and
devfreq?
GPU runtime PM and the devfreq being disabled is not evident from the context
of the function. You are probably right that it's not a problem in practice,
but why give reason for doubts in the first place if this could be avoided
by following a common practice?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Other option I see is to create a managed device resource (devm) version
of the devfreq_cooling_register API and use that. Is that what you are
trying to suggest?
-Akhil.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/24] drm/dp: fix kernel-doc warnings at drm_dp_helper.c
Reviewed-by: Lyude Paul
On Tue, 2020-10-13 at 14:14 +0200, Mauro Carvalho Chehab wrote:
> As warned by kernel-doc:
>
> ./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or
> member 'type' not described in 'drm_dp_downstream_is_type'
> ./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or
> member 'dev' not described in 'drm_dp_downstream_mode'
>
> Some function parameters weren't documented.
>
> Fixes: 38784f6f8805 ("drm/dp: Add helpers to identify downstream facing port
> types")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/gpu/drm/drm_dp_helper.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index b1c71af88579..deeed73f4ed6 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -374,6 +374,10 @@ static bool is_edid_digital_input_dp(const struct edid
> *edid)
> * drm_dp_downstream_is_type() - is the downstream facing port of certain
> type?
> * @dpcd: DisplayPort configuration data
> * @port_cap: port capabilities
> + * @type: port type to be checked. Can be:
> + * %DP_DS_PORT_TYPE_DP, %DP_DS_PORT_TYPE_VGA, %DP_DS_PORT_TYPE_DVI,
> + * %DP_DS_PORT_TYPE_HDMI, %DP_DS_PORT_TYPE_NON_EDID,
> + * %DP_DS_PORT_TYPE_DP_DUALMODE or %DP_DS_PORT_TYPE_WIRELESS.
> *
> * Caveat: Only works with DPCD 1.1+ port caps.
> *
> @@ -870,6 +874,7 @@ EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
>
> /**
> * drm_dp_downstream_mode() - return a mode for downstream facing port
> + * @dev: DRM device
> * @dpcd: DisplayPort configuration data
> * @port_cap: port capabilities
> *
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Fri, Oct 9, 2020 at 12:52 PM wrote:
>
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
> ---
> fs/cramfs/inode.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 912308600d39..003c014a42ed 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> unsigned int offset,
> struct page *page = pages[i];
>
> if (page) {
> - memcpy(data, kmap(page), PAGE_SIZE);
> - kunmap(page);
> + memcpy(data, kmap_thread(page), PAGE_SIZE);
> + kunmap_thread(page);
Why does this need a sleepable kmap? This looks like a textbook
kmap_atomic() use case.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [2/2] drm/msm: Add support for GPU cooling
On Tue, Oct 13, 2020 at 07:23:34PM +0530, Akhil P Oommen wrote:
> On 10/12/2020 11:10 PM, m...@chromium.org wrote:
> > On Mon, Oct 12, 2020 at 07:03:51PM +0530, Akhil P Oommen wrote:
> > > On 10/10/2020 12:06 AM, m...@chromium.org wrote:
> > > > Hi Akhil,
> > > >
> > > > On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
> > > > > Register GPU as a devfreq cooling device so that it can be passively
> > > > > cooled by the thermal framework.
> > > > >
> > > > > Signed-off-by: Akhil P Oommen
> > > > > ---
> > > > >drivers/gpu/drm/msm/msm_gpu.c | 13 -
> > > > >drivers/gpu/drm/msm/msm_gpu.h | 2 ++
> > > > >2 files changed, 14 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/msm_gpu.c
> > > > > b/drivers/gpu/drm/msm/msm_gpu.c
> > > > > index 55d1648..93ffd66 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > > > > @@ -14,6 +14,7 @@
> > > > >#include
> > > > >#include
> > > > >#include
> > > > > +#include
> > > > >#include
> > > > >#include
> > > > > @@ -107,9 +108,18 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
> > > > > if (IS_ERR(gpu->devfreq.devfreq)) {
> > > > > DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
> > > > > devfreq\n");
> > > > > gpu->devfreq.devfreq = NULL;
> > > > > + return;
> > > > > }
> > > > > devfreq_suspend_device(gpu->devfreq.devfreq);
> > > > > +
> > > > > + gpu->cooling =
> > > > > of_devfreq_cooling_register(gpu->pdev->dev.of_node,
> > > > > + gpu->devfreq.devfreq);
> > > > > + if (IS_ERR(gpu->cooling)) {
> > > > > + DRM_DEV_ERROR(>pdev->dev,
> > > > > + "Couldn't register GPU cooling
> > > > > device\n");
> > > > > + gpu->cooling = NULL;
> > > > > + }
> > > > >}
> > > > >static int enable_pwrrail(struct msm_gpu *gpu)
> > > > > @@ -926,7 +936,6 @@ int msm_gpu_init(struct drm_device *drm, struct
> > > > > platform_device *pdev,
> > > > > msm_devfreq_init(gpu);
> > > > > -
> Will remove this unintended change.
> > > > > gpu->aspace = gpu->funcs->create_address_space(gpu, pdev);
> > > > > if (gpu->aspace == NULL)
> > > > > @@ -1005,4 +1014,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
> > > > > gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu);
> > > > > msm_gem_address_space_put(gpu->aspace);
> > > > > }
> > > > > +
> > > > > + devfreq_cooling_unregister(gpu->cooling);
> > > >
> > > > Resources should be released in reverse order, otherwise the cooling
> > > > device
> > > > could use resources that have already been freed.
> > > > Why do you think this is not the correct order? If you are thinking
> > > about devfreq struct, it is managed device resource.
> >
> > I did not check specifically if changing the frequency really uses any of
> > the
> > resources that are released previously, In any case it's not a good idea to
> > allow other parts of the kernel to use a half initialized/torn down device.
> > Even if it isn't a problem today someone could change the driver to use any
> > of these resources (or add a new one) in a frequency change, without even
> > thinking about the cooling device, just (rightfully) asuming that things are
> > set up and torn down in a sane order.
> 'sane order' relative to what specifically here? Should we worry about freq
> change at this point because we have already disabled gpu runtime pm and
> devfreq?
GPU runtime PM and the devfreq being disabled is not evident from the context
of the function. You are probably right that it's not a problem in practice,
but why give reason for doubts in the first place if this could be avoided
by following a common practice?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v2 22/22] drm/msm: Don't implicit-sync if only a single ring
On Tue, Oct 13, 2020 at 4:08 AM Daniel Vetter wrote:
>
> On Mon, Oct 12, 2020 at 08:07:38AM -0700, Rob Clark wrote:
> > On Mon, Oct 12, 2020 at 7:40 AM Daniel Vetter wrote:
> > >
> > > On Sun, Oct 11, 2020 at 07:09:49PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > Any cross-device sync use-cases *must* use explicit sync. And if there
> > > > is only a single ring (no-preemption), everything is FIFO order and
> > > > there is no need to implicit-sync.
> > > >
> > > > Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
> > > > is undefined when fences are not used to synchronize buffer usage across
> > > > contexts (which is the only case where multiple different priority rings
> > > > could come into play).
> > >
> > > Uh does this mean msm is broken on dri2/3 and wayland? Or I'm I just
> > > confused by your commit message?
> >
> > No, I don't think so. If there is only a single priority level
> > ringbuffer (ie. no preemption to higher priority ring) then everything
> > is inherently FIFO order.
>
> Well eventually you get a scheduler I guess/hope :-)
we do have one currently for some gens, but not others.. hence the
check for # of rings. (Ie. there is a ring per priority level, if
only one ring, that means no preemption/scheduler)
> > For cases where we are sharing buffers with something external to drm,
> > explicit sync will be used. And we don't implicit sync with display,
> > otherwise x11 (frontbuffer rendering) would not work
>
> Uh now I'm even more confused. The implicit sync fences in dma_resv are
> kinda for everyone. That's also why dma_resv with the common locking
> approach is a useful idea.
>
> So display should definitely support implicit sync, and iirc msm does have
> the helper hooked up.
yup
> Wrt other subsystems, I guess passing dma_fence around somehow doesn't fit
> into v4l (the patches never landed), so v4l doesn't do any kind of sync
> right now. But this could be fixed. Not sure what else is going on.
>
> So I guess I still have no idea why you put that into the commit message.
>
> btw for what you're trying to do yourself, the way to do this is to
> allocate a fence timeline for your engine, compare fences, and no-op them
> all out if their own the same timeline.
we do that already (with a fence timeline per-ring, in the case of
gens which support multiple rings / preemption).. this patch just
short-circuits that in the case where we already knows the fences will
of the same timeline
BR,
-R
> -Daniel
>
> >
> > BR,
> > -R
> >
> > > Since for these protocols we do expect implicit sync accross processes to
> > > work. Even across devices (and nvidia have actually provided quite a bunch
> > > of patches to make this work in i915 - ttm based drivers get this right,
> > > plus dumb scanout drivers using the right helpers also get this all
> > > right).
> > > -Daniel
> > >
> > > >
> > > > Signed-off-by: Rob Clark
> > > > ---
> > > > drivers/gpu/drm/msm/msm_gem_submit.c | 7 ---
> > > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > index 3151a0ca8904..c69803ea53c8 100644
> > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > @@ -277,7 +277,7 @@ static int submit_lock_objects(struct
> > > > msm_gem_submit *submit)
> > > > return ret;
> > > > }
> > > >
> > > > -static int submit_fence_sync(struct msm_gem_submit *submit, bool
> > > > no_implicit)
> > > > +static int submit_fence_sync(struct msm_gem_submit *submit, bool
> > > > implicit_sync)
> > > > {
> > > > int i, ret = 0;
> > > >
> > > > @@ -297,7 +297,7 @@ static int submit_fence_sync(struct msm_gem_submit
> > > > *submit, bool no_implicit)
> > > > return ret;
> > > > }
> > > >
> > > > - if (no_implicit)
> > > > + if (!implicit_sync)
> > > > continue;
> > > >
> > > > ret = msm_gem_sync_object(_obj->base,
> > > > submit->ring->fctx,
> > > > @@ -768,7 +768,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev,
> > > > void *data,
> > > > if (ret)
> > > > goto out;
> > > >
> > > > - ret = submit_fence_sync(submit, !!(args->flags &
> > > > MSM_SUBMIT_NO_IMPLICIT));
> > > > + ret = submit_fence_sync(submit, (gpu->nr_rings > 1) &&
> > > > + !(args->flags & MSM_SUBMIT_NO_IMPLICIT));
> > > > if (ret)
> > > > goto out;
> > > >
> > > > --
> > > > 2.26.2
> > > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On Tue, Oct 13, 2020 at 6:42 AM Robin Murphy wrote: > > On 2020-10-07 07:25, Christoph Hellwig wrote: > > On Tue, Oct 06, 2020 at 09:19:32AM -0400, Jonathan Marek wrote: > >> One example why drm/msm can't use DMA API is multiple page table support > >> (that is landing in 5.10), which is something that definitely couldn't work > >> with DMA API. > >> > >> Another one is being able to choose the address for mappings, which AFAIK > >> DMA API can't do (somewhat related to this: qcom hardware often has ranges > >> of allowed addresses, which the dma_mask mechanism fails to represent, what > >> I see is drivers using dma_mask as a "maximum address", and since addresses > >> are allocated from the top it generally works) > > > > That sounds like a good enough rason to use the IOMMU API. I just > > wanted to make sure this really makes sense. > > I still think this situation would be best handled with a variant of > dma_ops_bypass that also guarantees to bypass SWIOTLB, and can be set > automatically when attaching to an unmanaged IOMMU domain. That way the > device driver can make DMA API calls in the appropriate places that do > the right thing either way, and only needs logic to decide whether to > use the returned DMA addresses directly or ignore them if it knows > they're overridden by its own IOMMU mapping. > That would be pretty ideal from my PoV BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/5] dt-bindings: display: Add support for Intel KeemBay Display
On Tue, Oct 13, 2020 at 12:24:38AM +, Chrisanthus, Anitha wrote: > Hi Neil, > > Thanks for your review, please see my reply inline. > > > -Original Message- > > From: Neil Armstrong > > Sent: Friday, October 9, 2020 2:10 AM > > To: Chrisanthus, Anitha ; dri- > > de...@lists.freedesktop.org; devicet...@vger.kernel.org; Vetter, Daniel > > > > Cc: Dea, Edmund J ; s...@ravnborg.org > > Subject: Re: [PATCH v9 1/5] dt-bindings: display: Add support for Intel > > KeemBay Display > > > > Hi, > > > > On 09/10/2020 03:03, Anitha Chrisanthus wrote: > > > This patch adds bindings for Intel KeemBay Display > > > > > > v2: review changes from Rob Herring > > > > > > Signed-off-by: Anitha Chrisanthus > > > --- > > > .../bindings/display/intel,keembay-display.yaml| 99 > > ++ > > > 1 file changed, 99 insertions(+) > > > create mode 100644 > > Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/display/intel,keembay- > > display.yaml b/Documentation/devicetree/bindings/display/intel,keembay- > > display.yaml > > > new file mode 100644 > > > index 000..a38493d > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/intel,keembay- > > display.yaml > > > @@ -0,0 +1,99 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/display/intel,keembay- > > display.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Devicetree bindings for Intel Keem Bay display controller > > > + > > > +maintainers: > > > + - Anitha Chrisanthus > > > + - Edmond J Dea > > > + > > > +properties: > > > + compatible: > > > +const: intel,kmb_display > > > + > > > + reg: > > > +items: > > > + - description: Lcd registers range > > > + - description: Mipi registers range > > > > Looking at the registers, the MIPI transceiver seems to be a separate IP, > > same for D-PHY which should have a proper PHY driver instead of beeing > > handled > > here. > > > The LCD, MIPI DSI, DPHY and MSSCAM as a group, are considered the > display subsystem for Keem Bay. As such, there are several > interdependencies that make splitting them up next to impossible and Please detail what those inter-dependencies are. It's doubtful that you have anything we have not had to deal with in other SoCs. > currently we do not have the resources available for that effort. That is certainly not justification for accepting this. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/5] Introduce drm scaling filter property
On Monday, October 12, 2020 8:41 PM, Pankaj Bharadiya wrote: > Now, Sameer has implemented Integer scaling in Kodi Retro gaming > framework which demonstrate how Integer scaling gives distinctive > look to pixel art games when played on higher resolution monitors. > > Kodi patches are reviewed and accepted for merge now. > > Here is the userspace patch series link: > https://github.com/xbmc/xbmc/pull/18194 As a side note, these user-space patches hard-code the kernel enum values [1]. This is something which we discussed some time ago [2], the result of the discussion is that user-space shouldn't do that. [1]: https://github.com/xbmc/xbmc/pull/18194/files#diff-94967b31726326769b31635c3dd7fc9b50d003057b49306a136b6b702795dd96R30 [2]: https://lists.freedesktop.org/archives/dri-devel/2020-April/261055.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: shmobile: Reduce include dependencies
On Wed, Feb 26, 2020 at 03:44:06AM +0200, Laurent Pinchart wrote:
> Hi Andy,
>
> Thank you for the patch, and sorry for the delay.
>
> On Mon, Feb 24, 2020 at 11:04:30AM +0200, Andy Shevchenko wrote:
> > On Thu, Feb 06, 2020 at 01:12:32PM +0200, Andy Shevchenko wrote:
> > > This file doesn't need everything provided by .
>
> s/everything/anything/
>
> > > All it needs are some types, which are provided by .
> > >
> > > Drop unneeded completely.
> >
> > Any comments on this?
>
> Reviewed-by: Laurent Pinchart
>
> Feel free to push :-)
Pushed to drm-misc-next, thanks for the patch and review.
>
> > > Signed-off-by: Andy Shevchenko
> > > ---
> > > v3: Drop header completely (Laurent)
> > > include/linux/platform_data/shmob_drm.h | 2 --
> > > 1 file changed, 2 deletions(-)
> > >
> > > diff --git a/include/linux/platform_data/shmob_drm.h
> > > b/include/linux/platform_data/shmob_drm.h
> > > index fe815d7d9f58..d661399b217d 100644
> > > --- a/include/linux/platform_data/shmob_drm.h
> > > +++ b/include/linux/platform_data/shmob_drm.h
> > > @@ -10,8 +10,6 @@
> > > #ifndef __SHMOB_DRM_H__
> > > #define __SHMOB_DRM_H__
> > >
> > > -#include
> > > -
> > > #include
> > >
> > > enum shmob_drm_clk_source {
>
> --
> Regards,
>
> Laurent Pinchart
> ___
> 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: [2/2] drm/msm: Add support for GPU cooling
On 10/12/2020 11:10 PM, m...@chromium.org wrote:
On Mon, Oct 12, 2020 at 07:03:51PM +0530, Akhil P Oommen wrote:
On 10/10/2020 12:06 AM, m...@chromium.org wrote:
Hi Akhil,
On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/msm_gpu.c | 13 -
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 55d1648..93ffd66 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -107,9 +108,18 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
if (IS_ERR(gpu->devfreq.devfreq)) {
DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
devfreq\n");
gpu->devfreq.devfreq = NULL;
+ return;
}
devfreq_suspend_device(gpu->devfreq.devfreq);
+
+ gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
+ gpu->devfreq.devfreq);
+ if (IS_ERR(gpu->cooling)) {
+ DRM_DEV_ERROR(>pdev->dev,
+ "Couldn't register GPU cooling device\n");
+ gpu->cooling = NULL;
+ }
}
static int enable_pwrrail(struct msm_gpu *gpu)
@@ -926,7 +936,6 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
msm_devfreq_init(gpu);
-
Will remove this unintended change.
gpu->aspace = gpu->funcs->create_address_space(gpu, pdev);
if (gpu->aspace == NULL)
@@ -1005,4 +1014,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu);
msm_gem_address_space_put(gpu->aspace);
}
+
+ devfreq_cooling_unregister(gpu->cooling);
Resources should be released in reverse order, otherwise the cooling device
could use resources that have already been freed.
Why do you think this is not the correct order? If you are thinking
about devfreq struct, it is managed device resource.
I did not check specifically if changing the frequency really uses any of the
resources that are released previously, In any case it's not a good idea to
allow other parts of the kernel to use a half initialized/torn down device.
Even if it isn't a problem today someone could change the driver to use any
of these resources (or add a new one) in a frequency change, without even
thinking about the cooling device, just (rightfully) asuming that things are
set up and torn down in a sane order.
'sane order' relative to what specifically here? Should we worry about
freq change at this point because we have already disabled gpu runtime
pm and devfreq?
-Akhil.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
-Akhil.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On 2020-10-07 07:25, Christoph Hellwig wrote: On Tue, Oct 06, 2020 at 09:19:32AM -0400, Jonathan Marek wrote: One example why drm/msm can't use DMA API is multiple page table support (that is landing in 5.10), which is something that definitely couldn't work with DMA API. Another one is being able to choose the address for mappings, which AFAIK DMA API can't do (somewhat related to this: qcom hardware often has ranges of allowed addresses, which the dma_mask mechanism fails to represent, what I see is drivers using dma_mask as a "maximum address", and since addresses are allocated from the top it generally works) That sounds like a good enough rason to use the IOMMU API. I just wanted to make sure this really makes sense. I still think this situation would be best handled with a variant of dma_ops_bypass that also guarantees to bypass SWIOTLB, and can be set automatically when attaching to an unmanaged IOMMU domain. That way the device driver can make DMA API calls in the appropriate places that do the right thing either way, and only needs logic to decide whether to use the returned DMA addresses directly or ignore them if it knows they're overridden by its own IOMMU mapping. Robin. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 65/80] docs: amdgpu: fix a warning when building the documentation
Applied. Thanks! Alex On Tue, Oct 13, 2020 at 7:54 AM Mauro Carvalho Chehab wrote: > > As reported by Sphinx: > > Documentation/gpu/amdgpu.rst:200: WARNING: Inline emphasis > start-string without end-string. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/gpu/amdgpu.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst > index 17112352f605..4ed8ecf1cd86 100644 > --- a/Documentation/gpu/amdgpu.rst > +++ b/Documentation/gpu/amdgpu.rst > @@ -197,8 +197,8 @@ pp_power_profile_mode > .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c > :doc: pp_power_profile_mode > > -*_busy_percent > -~~ > +\*_busy_percent > +~~~ > > .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c > :doc: gpu_busy_percent > -- > 2.26.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
Re: [PATCH v6 72/80] drm/amd/display: kernel-doc: document force_timing_sync
Applied. Thanks!
Alex
On Tue, Oct 13, 2020 at 7:54 AM Mauro Carvalho Chehab
wrote:
>
> As warned when running "make htmldocs":
>
> ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:345: warning:
> Function parameter or member 'force_timing_sync' not described in
> 'amdgpu_display_manager'
>
> This new struct member was not documented at kernel-doc markup.
>
> Fixes: 3d4e52d0cf24 ("drm/amd/display: Add debugfs for forcing stream timing
> sync")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index dd1559c743c2..fc7e3e9fd719 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -149,6 +149,8 @@ struct amdgpu_dm_backlight_caps {
> * @cached_state: Caches device atomic state for suspend/resume
> * @cached_dc_state: Cached state of content streams
> * @compressor: Frame buffer compression buffer. See
> dm_comressor_info
> + * @force_timing_sync: set via debugfs. When set, indicates that all
> connected
> + *displays will be forced to synchronize.
> */
> struct amdgpu_display_manager {
>
> --
> 2.26.2
>
> ___
> 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/display: remove no need return value
Applied. Thanks!
Alex
On Mon, Oct 12, 2020 at 9:44 AM Bernard Zhao wrote:
>
> Functions (disable_all_writeback_pipes_for_stream &
> dc_enable_stereo & dc_post_update_surfaces_to_stream)
> always return true, there is no need to keep the return value.
> This change is to make the code a bit more readable.
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 17 +
> drivers/gpu/drm/amd/display/dc/dc.h| 2 +-
> drivers/gpu/drm/amd/display/dc/dc_stream.h | 2 +-
> 3 files changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 92eb1ca1634f..8dc598a632b5 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -761,7 +761,7 @@ static bool dc_construct(struct dc *dc,
> return false;
> }
>
> -static bool disable_all_writeback_pipes_for_stream(
> +static void disable_all_writeback_pipes_for_stream(
> const struct dc *dc,
> struct dc_stream_state *stream,
> struct dc_state *context)
> @@ -770,8 +770,6 @@ static bool disable_all_writeback_pipes_for_stream(
>
> for (i = 0; i < stream->num_wb_info; i++)
> stream->writeback_info[i].wb_enabled = false;
> -
> - return true;
> }
>
> void apply_ctx_interdependent_lock(struct dc *dc, struct dc_state *context,
> struct dc_stream_state *stream, bool lock)
> @@ -1213,13 +1211,12 @@ bool dc_validate_seamless_boot_timing(const struct dc
> *dc,
> return true;
> }
>
> -bool dc_enable_stereo(
> +void dc_enable_stereo(
> struct dc *dc,
> struct dc_state *context,
> struct dc_stream_state *streams[],
> uint8_t stream_count)
> {
> - bool ret = true;
> int i, j;
> struct pipe_ctx *pipe;
>
> @@ -1234,8 +1231,6 @@ bool dc_enable_stereo(
> dc->hwss.setup_stereo(pipe, dc);
> }
> }
> -
> - return ret;
> }
>
> /*
> @@ -1448,18 +1443,18 @@ static bool is_flip_pending_in_pipes(struct dc *dc,
> struct dc_state *context)
> return false;
> }
>
> -bool dc_post_update_surfaces_to_stream(struct dc *dc)
> +void dc_post_update_surfaces_to_stream(struct dc *dc)
> {
> int i;
> struct dc_state *context = dc->current_state;
>
> if ((!dc->optimized_required) || dc->optimize_seamless_boot_streams >
> 0)
> - return true;
> + return;
>
> post_surface_trace(dc);
>
> if (is_flip_pending_in_pipes(dc, context))
> - return true;
> + return;
>
> for (i = 0; i < dc->res_pool->pipe_count; i++)
> if (context->res_ctx.pipe_ctx[i].stream == NULL ||
> @@ -1472,8 +1467,6 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
>
> dc->optimized_required = false;
> dc->wm_optimized_required = false;
> -
> - return true;
> }
>
> struct dc_state *dc_create_state(struct dc *dc)
> diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
> b/drivers/gpu/drm/amd/display/dc/dc.h
> index f50ef4255020..f79a3c318757 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc.h
> @@ -962,7 +962,7 @@ struct dc_flip_addrs {
> bool triplebuffer_flips;
> };
>
> -bool dc_post_update_surfaces_to_stream(
> +void dc_post_update_surfaces_to_stream(
> struct dc *dc);
>
> #include "dc_stream.h"
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_stream.h
> b/drivers/gpu/drm/amd/display/dc/dc_stream.h
> index d9888f316da6..0047ab33f88e 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_stream.h
> +++ b/drivers/gpu/drm/amd/display/dc/dc_stream.h
> @@ -391,7 +391,7 @@ enum dc_status dc_validate_stream(struct dc *dc, struct
> dc_stream_state *stream)
> * Enable stereo when commit_streams is not required,
> * for example, frame alternate.
> */
> -bool dc_enable_stereo(
> +void dc_enable_stereo(
> struct dc *dc,
> struct dc_state *context,
> struct dc_stream_state *streams[],
> --
> 2.28.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/amdgpu: fix semicolon.cocci warnings
Applied. Thanks!
Alex
On Mon, Oct 12, 2020 at 5:21 PM kernel test robot wrote:
>
> From: kernel test robot
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:608:2-3: Unneeded semicolon
>
>
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> Fixes: b4a7db71ea06 ("drm/amdgpu: add per device user friendly xgmi events
> for vega20")
> CC: Jonathan Kim
> Signed-off-by: kernel test robot
> ---
>
> tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
> head: 02c3d98ce25b3e4f0b8e830be054c8f4f7f944c1
> commit: b4a7db71ea060218529e6a4c660c37687ecb5669 [286/376] drm/amdgpu: add
> per device user friendly xgmi events for vega20
>
> amdgpu_pmu.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c
> @@ -605,7 +605,7 @@ int amdgpu_pmu_init(struct amdgpu_device
> break;
> default:
> return 0;
> - };
> + }
>
> return ret;
> }
> ___
> 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 7/8] dt-bindings: usb: convert mediatek,mtu3.txt to YAML schema
On Tue, 13 Oct 2020 16:52:06 +0800, Chunfeng Yun wrote: > Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml > > Signed-off-by: Chunfeng Yun > --- > v2: new patch > --- > .../devicetree/bindings/usb/mediatek,mtu3.txt | 108 - > .../bindings/usb/mediatek,mtu3.yaml | 227 ++ > 2 files changed, 227 insertions(+), 108 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.example.dt.yaml: usb@11271000: compatible: ['mediatek,mt8173-mtu3'] is too short From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.example.dt.yaml: usb@11271000: 'clocks' is a required property From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.example.dt.yaml: usb@11271000: 'clock-names' is a required property From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml See https://patchwork.ozlabs.org/patch/1381414 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/24] drm: amdgpu: kernel-doc: update some adev parameters
Am 13.10.20 um 14:14 schrieb Mauro Carvalho Chehab: Running "make htmldocs: produce lots of warnings on those files: ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'p_size' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:134: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'p_size' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:134: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' They're related to the repacement of some parameters by adev, and due to a few renamed parameters. Update the kernel-doc documentation accordingly. Signed-off-by: Mauro Carvalho Chehab --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 ++--- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index f8f298b34805..fb375752feb1 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -817,7 +817,7 @@ static void amdgpu_block_invalid_wreg(struct amdgpu_device *adev, /** * amdgpu_device_asic_init - Wrapper for atom asic_init * - * @dev: drm_device pointer + * @adev: drm_device pointer This should probably read amdgpu device pointer, but apart from that looks good to me. Christian. * * Does any asic specific work and then calls atom asic init. */ diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c index f203e4a6a3f2..5f3a04cd0fba 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c @@ -81,8 +81,8 @@ static const struct ttm_resource_manager_func amdgpu_gtt_mgr_func; /** * amdgpu_gtt_mgr_init - init GTT manager and DRM MM * - * @man: TTM memory type manager - * @p_size: maximum size of GTT + * @adev: amdgpu device structure + * @gtt_size: maximum size of GTT * * Allocate and initialize the GTT manager. */ @@ -123,7 +123,7 @@ int amdgpu_gtt_mgr_init(struct amdgpu_device *adev, uint64_t gtt_size) /** * amdgpu_gtt_mgr_fini - free and destroy GTT manager
[PATCH v2 11/24] drm/dp: fix kernel-doc warnings at drm_dp_helper.c
As warned by kernel-doc:
./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or
member 'type' not described in 'drm_dp_downstream_is_type'
./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or
member 'dev' not described in 'drm_dp_downstream_mode'
Some function parameters weren't documented.
Fixes: 38784f6f8805 ("drm/dp: Add helpers to identify downstream facing port
types")
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/drm_dp_helper.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index b1c71af88579..deeed73f4ed6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -374,6 +374,10 @@ static bool is_edid_digital_input_dp(const struct edid
*edid)
* drm_dp_downstream_is_type() - is the downstream facing port of certain type?
* @dpcd: DisplayPort configuration data
* @port_cap: port capabilities
+ * @type: port type to be checked. Can be:
+ * %DP_DS_PORT_TYPE_DP, %DP_DS_PORT_TYPE_VGA, %DP_DS_PORT_TYPE_DVI,
+ * %DP_DS_PORT_TYPE_HDMI, %DP_DS_PORT_TYPE_NON_EDID,
+ * %DP_DS_PORT_TYPE_DP_DUALMODE or %DP_DS_PORT_TYPE_WIRELESS.
*
* Caveat: Only works with DPCD 1.1+ port caps.
*
@@ -870,6 +874,7 @@ EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
/**
* drm_dp_downstream_mode() - return a mode for downstream facing port
+ * @dev: DRM device
* @dpcd: DisplayPort configuration data
* @port_cap: port capabilities
*
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/24] drm/dp: fix a kernel-doc issue at drm_edid.c
The name of the argument is different, causing those warnings:
./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or
member 'video_code' not described in 'drm_display_mode_from_cea_vic'
./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter
'vic' description in 'drm_display_mode_from_cea_vic'
Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()")
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a82f37d44258..631125b46e04 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3741,7 +3741,7 @@ drm_add_cmdb_modes(struct drm_connector *connector, u8
svd)
/**
* drm_display_mode_from_cea_vic() - return a mode for CEA VIC
* @dev: DRM device
- * @vic: CEA VIC of the mode
+ * @video_code: CEA VIC of the mode
*
* Creates a new mode matching the specified CEA VIC.
*
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/24] drm: amdgpu: kernel-doc: update some adev parameters
Running "make htmldocs: produce lots of warnings on those files: ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess function parameter 'p_size' description in 'amdgpu_vram_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:211: warning: Excess function parameter 'man' description in 'amdgpu_vram_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'p_size' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:134: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:90: warning: Excess function parameter 'p_size' description in 'amdgpu_gtt_mgr_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:134: warning: Excess function parameter 'man' description in 'amdgpu_gtt_mgr_fini' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:675: warning: Excess function parameter 'dev' description in 'amdgpu_device_asic_init' They're related to the repacement of some parameters by adev, and due to a few renamed parameters. Update the kernel-doc documentation accordingly. Signed-off-by: Mauro Carvalho Chehab --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 ++--- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index f8f298b34805..fb375752feb1 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -817,7 +817,7 @@ static void amdgpu_block_invalid_wreg(struct amdgpu_device *adev, /** * amdgpu_device_asic_init - Wrapper for atom asic_init * - * @dev: drm_device pointer + * @adev: drm_device pointer * * Does any asic specific work and then calls atom asic init. */ diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c index f203e4a6a3f2..5f3a04cd0fba 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c @@ -81,8 +81,8 @@ static const struct ttm_resource_manager_func amdgpu_gtt_mgr_func; /** * amdgpu_gtt_mgr_init - init GTT manager and DRM MM * - * @man: TTM memory type manager - * @p_size: maximum size of GTT + * @adev: amdgpu device structure + * @gtt_size: maximum size of GTT * * Allocate and initialize the GTT manager. */ @@ -123,7 +123,7 @@ int amdgpu_gtt_mgr_init(struct amdgpu_device *adev, uint64_t gtt_size) /** * amdgpu_gtt_mgr_fini - free and destroy GTT manager * - * @man: TTM memory type manager + * @adev: amdgpu device structure * * Destroy and free the GTT manager, returns -EBUSY if ranges are still * allocated inside it.
[PATCH v2 08/24] drm: kernel-doc: document drm_dp_set_subconnector_property() params
Changeset e5b92773287c ("drm: report dp downstream port type as a subconnector
property")
added a new function to the kAPI, but didn't add any documentation
for the parameters for drm_dp_set_subconnector_property().
Fixes: e5b92773287c ("drm: report dp downstream port type as a subconnector
property")
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/drm_dp_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 90807a6b415c..b1c71af88579 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1028,7 +1028,8 @@ EXPORT_SYMBOL(drm_dp_downstream_debug);
/**
* drm_dp_subconnector_type() - get DP branch device type
- *
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
*/
enum drm_mode_subconnector
drm_dp_subconnector_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
@@ -1079,6 +1080,10 @@ EXPORT_SYMBOL(drm_dp_subconnector_type);
/**
* drm_mode_set_dp_subconnector_property - set subconnector for DP connector
+ * @connector: connector to set property on
+ * @status: connector status
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
*
* Called by a driver on every detect event.
*/
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/5] drm: Introduce plane and CRTC scaling filter properties
> +/** > + * DOC: Plane scaling filter property > + * > + * SCALING_FILTER: > + * > + * Indicates scaling filter to be used for plane scaler > + * > + * The value of this property can be one of the following: > + * Default: > + * Driver's default scaling filter > + * Nearest Neighbor: > + * Nearest Neighbor scaling filter > + * > + * Drivers can set up this property for a plane by calling > + * drm_plane_create_scaling_filter_property > + */ Similarily, this can be moved in "Plane Composition Properties". ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/5] drm: Introduce plane and CRTC scaling filter properties
On Monday, October 12, 2020 8:41 PM, Pankaj Bharadiya wrote: > +/** > + * DOC: CRTC scaling filter property > + * > + * SCALING_FILTER: > + * > + * Indicates scaling filter to be used for CRTC scaler > + * > + * The value of this property can be one of the following: > + * Default: > + * Driver's default scaling filter > + * Nearest Neighbor: > + * Nearest Neighbor scaling filter > + * > + * Drivers can set up this property for a CRTC by calling > + * drm_crtc_create_scaling_filter_property > + */ Can we put this under the existing "Standard CRTC Properties" doc comment instead? I'd prefer to avoid having a lot of different headings for properties. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 79/80] drm: drm_edid: remove a duplicated kernel-doc declaration
It is not possible to create cross-references for duplicated symbols. While Sphinx always detected it, on Sphinx 3 it generates warnings like this: .../Documentation/gpu/drm-kms-helpers:326: ../drivers/gpu/drm/drm_edid.c:1626: WARNING: Duplicate C declaration, also defined in 'gpu/drm-kms-helpers'. Declaration is 'bool drm_edid_are_equal (const struct edid *edid1, const struct edid *edid2)'. So, get rid of the duplicated kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab --- include/drm/drm_edid.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index cfa4f5af49af..6586c9104ec1 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -359,13 +359,6 @@ drm_load_edid_firmware(struct drm_connector *connector) } #endif -/** - * drm_edid_are_equal - compare two edid blobs. - * @edid1: pointer to first blob - * @edid2: pointer to second blob - * This helper can be used during probing to determine if - * edid had changed. - */ bool drm_edid_are_equal(const struct edid *edid1, const struct edid *edid2); int -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 56/80] dt-bindings: fix references to files converted to yaml
There were several files converted to yaml, but the .txt file is still referenced somewhere else. Update the references for them to point to the right file. Signed-off-by: Mauro Carvalho Chehab --- .../bindings/display/tilcdc/tilcdc.txt | 2 +- .../devicetree/bindings/mailbox/omap-mailbox.txt | 2 +- .../devicetree/bindings/media/i2c/tvp5150.txt| 2 +- .../bindings/pwm/google,cros-ec-pwm.yaml | 2 +- .../bindings/soc/qcom/qcom,smd-rpm.yaml | 2 +- .../bindings/sound/google,cros-ec-codec.yaml | 2 +- MAINTAINERS | 16 7 files changed, 14 insertions(+), 14 deletions(-) diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt index 8b2a71395647..3e64075ac7ec 100644 --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt @@ -37,7 +37,7 @@ Optional nodes: supports a single port with a single endpoint. - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and - Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt for connecting + Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml for connecting tfp410 DVI encoder or lcd panel to lcdc [1] There is an errata about AM335x color wiring. For 16-bit color mode diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt index 35c3f56b7f7b..5fe80c1c19fc 100644 --- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt +++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt @@ -69,7 +69,7 @@ The following are mandatory properties for the K3 AM65x and J721E SoCs only: the interrupt routes between the IP and the main GIC controllers. See the following binding for additional details, - Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt + Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml Child Nodes: diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt index 6c88ce858d08..719b2995dc17 100644 --- a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt +++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt @@ -56,7 +56,7 @@ Optional Connector Properties: instead of using the autodetection mechnism. Please look at [1] for more information. -[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt. +[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml. Example - three input sources: #include diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml index 41ece1d85315..4cfbffd8414a 100644 --- a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml @@ -14,7 +14,7 @@ description: | Google's ChromeOS EC PWM is a simple PWM attached to the Embedded Controller (EC) and controlled via a host-command interface. An EC PWM node should be only found as a sub-node of the EC node (see - Documentation/devicetree/bindings/mfd/cros-ec.txt). + Documentation/devicetree/bindings/mfd/google,cros-ec.yaml). properties: compatible: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index 468d658ce3e7..2684f22a1d85 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -20,7 +20,7 @@ description: | present and this subnode may contain children that designate regulator resources. - Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt + Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml for information on the regulator subnodes that can exist under the rpm_requests. diff --git a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml index c84e656afb0a..3b9143af2c7c 100644 --- a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml +++ b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml @@ -13,7 +13,7 @@ description: | Google's ChromeOS EC codec is a digital mic codec provided by the Embedded Controller (EC) and is controlled via a host-command interface. An EC codec node should only be found as a sub-node of the EC node (see - Documentation/devicetree/bindings/mfd/cros-ec.txt). +
[PATCH v6 73/80] drm: kernel-doc: drm_dp_helper.h: fix a typo
Right now, kernel-doc generates a warning: ./include/drm/drm_dp_helper.h:1786: warning: Function parameter or member 'hbr2_reset' not described in 'drm_dp_phy_test_params' This is due to a typo: @hb2_reset -> @hbr2_reset Signed-off-by: Mauro Carvalho Chehab --- include/drm/drm_dp_helper.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index e47dc22ebf50..69f7863ee99a 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -1760,7 +1760,7 @@ static inline void drm_dp_cec_unset_edid(struct drm_dp_aux *aux) * @link_rate: Requested Link rate from DPCD 0x219 * @num_lanes: Number of lanes requested by sing through DPCD 0x220 * @phy_pattern: DP Phy test pattern from DPCD 0x248 - * @hb2_reset: DP HBR2_COMPLIANCE_SCRAMBLER_RESET from DCPD 0x24A and 0x24B + * @hbr2_reset: DP HBR2_COMPLIANCE_SCRAMBLER_RESET from DCPD 0x24A and 0x24B * @custom80: DP Test_80BIT_CUSTOM_PATTERN from DPCDs 0x250 through 0x259 * @enhanced_frame_cap: flag for enhanced frame capability. */ -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 72/80] drm/amd/display: kernel-doc: document force_timing_sync
As warned when running "make htmldocs":
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:345: warning:
Function parameter or member 'force_timing_sync' not described in
'amdgpu_display_manager'
This new struct member was not documented at kernel-doc markup.
Fixes: 3d4e52d0cf24 ("drm/amd/display: Add debugfs for forcing stream timing
sync")
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index dd1559c743c2..fc7e3e9fd719 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -149,6 +149,8 @@ struct amdgpu_dm_backlight_caps {
* @cached_state: Caches device atomic state for suspend/resume
* @cached_dc_state: Cached state of content streams
* @compressor: Frame buffer compression buffer. See dm_comressor_info
+ * @force_timing_sync: set via debugfs. When set, indicates that all connected
+ *displays will be forced to synchronize.
*/
struct amdgpu_display_manager {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 65/80] docs: amdgpu: fix a warning when building the documentation
As reported by Sphinx: Documentation/gpu/amdgpu.rst:200: WARNING: Inline emphasis start-string without end-string. Signed-off-by: Mauro Carvalho Chehab --- Documentation/gpu/amdgpu.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst index 17112352f605..4ed8ecf1cd86 100644 --- a/Documentation/gpu/amdgpu.rst +++ b/Documentation/gpu/amdgpu.rst @@ -197,8 +197,8 @@ pp_power_profile_mode .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c :doc: pp_power_profile_mode -*_busy_percent -~~ +\*_busy_percent +~~~ .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c :doc: gpu_busy_percent -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings
As reported by Sphinx: ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_wait_unlocked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_poll_wait'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1189: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2669: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_enable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2734: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_disable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2820: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_init'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3010: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3098: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3129: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3152: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_enable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3181: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_disable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3273: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3296: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_destroy_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3321: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_release'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3379: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_open_ioctl_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3534: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'read_properties_unlocked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3717: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_open_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3760: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_register'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3789: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_unregister'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4009: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_add_config_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4162: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_remove_config_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4260: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_init'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4423: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_fini'. With Sphinx 3, C declarations can't be duplicated anymore, so let's exclude those from the other internals found on i915_perf.c file. Signed-off-by: Mauro Carvalho Chehab --- Documentation/gpu/i915.rst | 29 + 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 33cc6ddf8f64..cff1f154b473 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -636,15 +636,36 @@ i915 Perf Observation Architecture Stream .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :functions: i915_oa_poll_wait -All i915 Perf
[PATCH v6 75/80] drm: kernel-doc: add description for a new function parameter
As reported by "make htmldocs":
./drivers/gpu/drm/drm_prime.c:808: warning: Function parameter or
member 'dev' not described in 'drm_prime_pages_to_sg'
Add a description for the new parameter.
Fixes: 707d561f77b5 ("drm: allow limiting the scatter list size.")
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/drm_prime.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1693aa7c14b5..1395688930f8 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -793,6 +793,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
/**
* drm_prime_pages_to_sg - converts a page array into an sg list
+ * @dev: DRM device
* @pages: pointer to the array of page pointers to convert
* @nr_pages: length of the page vector
*
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 74/80] gpu: docs: amdgpu.rst: get rid of wrong kernel-doc markups
As reported by kernel-doc: ./drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c:1: warning: no structured comments found ./drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1: warning: no structured comments found Those files only contain /** * DOC: */ markups, but they're included twice there: one to parse such markup, and another one to parse internal functions. In the case of amdgpu_xgmi.c, as it has just one such markup, we can simply include the file once, and let it parse the entire file without passing arguments to kernel-doc. This should place everything altogether. For amdgpu_ras.c, however, we need to remove the kernel-doc with just internal. This should be re-introduced if this file ever gets new non-DOC markups. Signed-off-by: Mauro Carvalho Chehab --- Documentation/gpu/amdgpu.rst | 7 --- 1 file changed, 7 deletions(-) diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst index 4ed8ecf1cd86..aba8df189a74 100644 --- a/Documentation/gpu/amdgpu.rst +++ b/Documentation/gpu/amdgpu.rst @@ -74,10 +74,6 @@ AMDGPU XGMI Support === .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c - :doc: AMDGPU XGMI Support - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c - :internal: AMDGPU RAS Support == @@ -115,9 +111,6 @@ RAS VRAM Bad Pages sysfs Interface .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c :doc: AMDGPU RAS sysfs gpu_vram_bad_pages Interface -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c - :internal: - Sample Code --- Sample code for testing error injection can be found here: -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: Switch to shmem helpers
Inspired by a patch by Chris Wilson for vgem. Plus this gives us vmap
at the gem bo level, which we need for generic fbdev emulation.
Luckily shmem also tracks ->vaddr, so we just need to adjust the code
all over a bit to make this fit.
Also wire up handle_to_fd, dunno why that was missing.
v2:
- Drop now unused container_of #define (Melissa)
- Make sure we keep creating cached objects, this is for testing
(Thomas)
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Melissa Wen
Cc: Haneen Mohammed
Acked-by: Thomas Zimmermann
Reviewed-by: Melissa Wen
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/vkms/Makefile | 1 -
drivers/gpu/drm/vkms/vkms_composer.c | 17 +-
drivers/gpu/drm/vkms/vkms_drv.c | 18 +-
drivers/gpu/drm/vkms/vkms_drv.h | 29 ---
drivers/gpu/drm/vkms/vkms_gem.c | 261 --
drivers/gpu/drm/vkms/vkms_plane.c | 13 +-
drivers/gpu/drm/vkms/vkms_writeback.c | 17 +-
8 files changed, 30 insertions(+), 327 deletions(-)
delete mode 100644 drivers/gpu/drm/vkms/vkms_gem.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 9efb82caaa87..b796c118fc3b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -287,6 +287,7 @@ config DRM_VKMS
tristate "Virtual KMS (EXPERIMENTAL)"
depends on DRM
select DRM_KMS_HELPER
+ select DRM_GEM_SHMEM_HELPER
select CRC32
default n
help
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 333d3cead0e3..72f779cbfedd 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -4,7 +4,6 @@ vkms-y := \
vkms_plane.o \
vkms_output.o \
vkms_crtc.o \
- vkms_gem.o \
vkms_composer.o \
vkms_writeback.o
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 33c031f27c2c..66c6842d70db 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include "vkms_drv.h"
@@ -129,15 +130,15 @@ static void compose_cursor(struct vkms_composer
*cursor_composer,
void *vaddr_out)
{
struct drm_gem_object *cursor_obj;
- struct vkms_gem_object *cursor_vkms_obj;
+ struct drm_gem_shmem_object *cursor_shmem_obj;
cursor_obj = drm_gem_fb_get_obj(_composer->fb, 0);
- cursor_vkms_obj = drm_gem_to_vkms_gem(cursor_obj);
+ cursor_shmem_obj = to_drm_gem_shmem_obj(cursor_obj);
- if (WARN_ON(!cursor_vkms_obj->vaddr))
+ if (WARN_ON(!cursor_shmem_obj->vaddr))
return;
- blend(vaddr_out, cursor_vkms_obj->vaddr,
+ blend(vaddr_out, cursor_shmem_obj->vaddr,
primary_composer, cursor_composer);
}
@@ -147,20 +148,20 @@ static int compose_planes(void **vaddr_out,
{
struct drm_framebuffer *fb = _composer->fb;
struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
- struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(gem_obj);
+ struct drm_gem_shmem_object *shmem_obj = to_drm_gem_shmem_obj(gem_obj);
if (!*vaddr_out) {
- *vaddr_out = kzalloc(vkms_obj->gem.size, GFP_KERNEL);
+ *vaddr_out = kzalloc(shmem_obj->base.size, GFP_KERNEL);
if (!*vaddr_out) {
DRM_ERROR("Cannot allocate memory for output frame.");
return -ENOMEM;
}
}
- if (WARN_ON(!vkms_obj->vaddr))
+ if (WARN_ON(!shmem_obj->vaddr))
return -EINVAL;
- memcpy(*vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
+ memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
if (cursor_composer)
compose_cursor(cursor_composer, primary_composer, *vaddr_out);
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index eb4007443706..198a8941d6ea 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include "vkms_drv.h"
@@ -39,17 +40,7 @@ bool enable_cursor = true;
module_param_named(enable_cursor, enable_cursor, bool, 0444);
MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
-static const struct file_operations vkms_driver_fops = {
- .owner = THIS_MODULE,
- .open = drm_open,
- .mmap = drm_gem_mmap,
- .unlocked_ioctl = drm_ioctl,
- .compat_ioctl = drm_compat_ioctl,
- .poll = drm_poll,
- .read = drm_read,
- .llseek = no_llseek,
- .release= drm_release,
-};
+DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
static void
Re: [PATCH v2 22/22] drm/msm: Don't implicit-sync if only a single ring
On Mon, Oct 12, 2020 at 08:07:38AM -0700, Rob Clark wrote:
> On Mon, Oct 12, 2020 at 7:40 AM Daniel Vetter wrote:
> >
> > On Sun, Oct 11, 2020 at 07:09:49PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Any cross-device sync use-cases *must* use explicit sync. And if there
> > > is only a single ring (no-preemption), everything is FIFO order and
> > > there is no need to implicit-sync.
> > >
> > > Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
> > > is undefined when fences are not used to synchronize buffer usage across
> > > contexts (which is the only case where multiple different priority rings
> > > could come into play).
> >
> > Uh does this mean msm is broken on dri2/3 and wayland? Or I'm I just
> > confused by your commit message?
>
> No, I don't think so. If there is only a single priority level
> ringbuffer (ie. no preemption to higher priority ring) then everything
> is inherently FIFO order.
Well eventually you get a scheduler I guess/hope :-)
> For cases where we are sharing buffers with something external to drm,
> explicit sync will be used. And we don't implicit sync with display,
> otherwise x11 (frontbuffer rendering) would not work
Uh now I'm even more confused. The implicit sync fences in dma_resv are
kinda for everyone. That's also why dma_resv with the common locking
approach is a useful idea.
So display should definitely support implicit sync, and iirc msm does have
the helper hooked up.
Wrt other subsystems, I guess passing dma_fence around somehow doesn't fit
into v4l (the patches never landed), so v4l doesn't do any kind of sync
right now. But this could be fixed. Not sure what else is going on.
So I guess I still have no idea why you put that into the commit message.
btw for what you're trying to do yourself, the way to do this is to
allocate a fence timeline for your engine, compare fences, and no-op them
all out if their own the same timeline.
-Daniel
>
> BR,
> -R
>
> > Since for these protocols we do expect implicit sync accross processes to
> > work. Even across devices (and nvidia have actually provided quite a bunch
> > of patches to make this work in i915 - ttm based drivers get this right,
> > plus dumb scanout drivers using the right helpers also get this all
> > right).
> > -Daniel
> >
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/msm/msm_gem_submit.c | 7 ---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > index 3151a0ca8904..c69803ea53c8 100644
> > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > @@ -277,7 +277,7 @@ static int submit_lock_objects(struct msm_gem_submit
> > > *submit)
> > > return ret;
> > > }
> > >
> > > -static int submit_fence_sync(struct msm_gem_submit *submit, bool
> > > no_implicit)
> > > +static int submit_fence_sync(struct msm_gem_submit *submit, bool
> > > implicit_sync)
> > > {
> > > int i, ret = 0;
> > >
> > > @@ -297,7 +297,7 @@ static int submit_fence_sync(struct msm_gem_submit
> > > *submit, bool no_implicit)
> > > return ret;
> > > }
> > >
> > > - if (no_implicit)
> > > + if (!implicit_sync)
> > > continue;
> > >
> > > ret = msm_gem_sync_object(_obj->base,
> > > submit->ring->fctx,
> > > @@ -768,7 +768,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> > > *data,
> > > if (ret)
> > > goto out;
> > >
> > > - ret = submit_fence_sync(submit, !!(args->flags &
> > > MSM_SUBMIT_NO_IMPLICIT));
> > > + ret = submit_fence_sync(submit, (gpu->nr_rings > 1) &&
> > > + !(args->flags & MSM_SUBMIT_NO_IMPLICIT));
> > > if (ret)
> > > goto out;
> > >
> > > --
> > > 2.26.2
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vkms: fbdev emulation support
On Tue, Oct 13, 2020 at 01:19:38PM +0300, Pekka Paalanen wrote: > On Tue, 13 Oct 2020 09:53:44 +0200 > Daniel Vetter wrote: > > > On Tue, Oct 13, 2020 at 8:14 AM Pekka Paalanen wrote: > > > > > > On Mon, 12 Oct 2020 16:23:35 +0200 > > > Daniel Vetter wrote: > > > > > > > On Mon, Oct 12, 2020 at 02:40:58PM +0200, Neil Armstrong wrote: > > > > > Hi, > > > > > > > > > > > ... > > > > > > > > It's weird because it the kernel is misconfigured and no console is > > > > > specified on the cmdline > > > > > this console could become the main console... > > > > > > > > > > It's a great feature, but couldn't this be a module parameter ? > > > > > > > > If you have vkms enabled in a distro, you're doing it wrong. > > > > > > That's really not a great position to take. I would prefer that > > > if a random contributor writes a Weston patch and runs 'meson test', it > > > will use VKMS to run Weston's DRM-backend tests on his machine > > > automatically, maybe save for some seat and device node access > > > permissions bits which distributions could be delivering as well. > > > > > > Just put the VKMS device node into a non-default seat, and Xorg etc. > > > will happily ignore it. > > > > > > For the fbdev device node, I don't know. Maybe a module parameter > > > really is a good choice there, defaulting to off. I have no interest in > > > testing anything against fbdev, but other people might disagree of > > > course. > > > > > > Why? Gitlab CI is still not running tests for every commit, just per > > > MR, and it might even be infeasible too. > > > > > > I am also hoping for a future where I don't have to build my own kernel > > > just to be able to run Weston DRM tests with VKMS. That means I want to > > > be able to run my machine with VKMS loaded and active at all times, > > > without affecting the normal desktop. I already have such a setup with > > > an extra AMD card, but you can't run most KMS tests against real > > > hardware drivers. > > > > I just realized that building vkms is no problem, since it doesn't > > auto-load. And if our Grand Plans with configurability come true, then > > your test-harness will want to do that loading and setup itself > > anyway. With that there also shouldn't be any problems with fbcon, > > since presumably you already have that bound to the real gpu. > > > > So I think we're all fine here, for everyone. > > > > Now if you built-in vkms, that's a different thing. And for that I > > really think a "don't do that" is the right choice. > > Very good. > > My remaining wish is that VKMS would be fully configurable and usable > by an ordinary user, but I suppose that should be solved with a > privileged userspace daemon somewhat similar to logind that hands out > VKMS "sessions" somehow. > > Not sure configfs is the best choice for VKMS configuration, unless > maybe unprivileged userspace could ask for a VKMS instance with its own > configfs tree it can access without CAP_ADMIN... My idea for testing would be to build a gitlab docker image and run that under usermode linux, with vkms built-in. Given how few people work on this, I don't think you get a fancy logind configuration session thing for it anytime soon. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/1] drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp
On Tue, Oct 13, 2020 at 6:06 PM Jitao Shi wrote:
>
> Replace horizontal_backporch_byte with vm->hback_porch * bpp to aovid
> flowing judgement negative number.
>
> if ((vm->hfront_porch * dsi_tmp_buf_bpp + horizontal_backporch_byte) >
> data_phy_cycles * dsi->lanes + delta)
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 65
> +++---
> 1 file changed, 25 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 80b7a082e874..f69ebeaf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -445,6 +445,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> u32 horizontal_backporch_byte;
> u32 horizontal_frontporch_byte;
> u32 dsi_tmp_buf_bpp, data_phy_cycles;
> + u32 delta;
> struct mtk_phy_timing *timing = >phy_timing;
>
> struct videomode *vm = >vm;
> @@ -466,50 +467,34 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi
> *dsi)
> horizontal_sync_active_byte = (vm->hsync_len * dsi_tmp_buf_bpp - 10);
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> - horizontal_backporch_byte = vm->hback_porch * dsi_tmp_buf_bpp;
> + horizontal_backporch_byte =
> + (vm->hback_porch * dsi_tmp_buf_bpp - 10);
These parentheses are not required, but it might be a little clearer to write:
(vm->hback_porch * dsi_tmp_buf_bpp) - 10;
> else
> - horizontal_backporch_byte = (vm->hback_porch + vm->hsync_len)
> *
> - dsi_tmp_buf_bpp;
> + horizontal_backporch_byte = ((vm->hback_porch +
> vm->hsync_len) *
> + dsi_tmp_buf_bpp - 10);
ditto:
((vm->hback_porch + vm->hsync_len) * dsi_tmp_buf_bpp) - 10;
But then, _maybe_ it's clearer to drop this hunk and just add this
below the if/else:
horizontal_backporch_byte -= 10;
>
> data_phy_cycles = timing->lpx + timing->da_hs_prepare +
> - timing->da_hs_zero + timing->da_hs_exit;
> -
> - if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> - if ((vm->hfront_porch + vm->hback_porch) * dsi_tmp_buf_bpp >
> - data_phy_cycles * dsi->lanes + 18) {
> - horizontal_frontporch_byte =
> - vm->hfront_porch * dsi_tmp_buf_bpp -
> - (data_phy_cycles * dsi->lanes + 18) *
> - vm->hfront_porch /
> - (vm->hfront_porch + vm->hback_porch);
> -
> - horizontal_backporch_byte =
> - horizontal_backporch_byte -
> - (data_phy_cycles * dsi->lanes + 18) *
> - vm->hback_porch /
> - (vm->hfront_porch + vm->hback_porch);
> - } else {
> - DRM_WARN("HFP less than d-phy, FPS will under
> 60Hz\n");
> - horizontal_frontporch_byte = vm->hfront_porch *
> -dsi_tmp_buf_bpp;
> - }
> + timing->da_hs_zero + timing->da_hs_exit + 3;
(for reference, apart from this `+ 3`, there is no functional change
in this hunk: this just moves delta outside of the if/else block,
which is a good idea for readability)
> +
> + delta = (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) ? 18 : 12;
> +
> + if ((vm->hfront_porch * dsi_tmp_buf_bpp + horizontal_backporch_byte) >
> + data_phy_cycles * dsi->lanes + delta) {
> + horizontal_frontporch_byte =
> + vm->hfront_porch * dsi_tmp_buf_bpp -
> + (data_phy_cycles * dsi->lanes + delta) *
> + vm->hfront_porch /
> + (vm->hfront_porch + vm->hback_porch);
> +
> + horizontal_backporch_byte =
> + horizontal_backporch_byte -
> + (data_phy_cycles * dsi->lanes + delta) *
> + vm->hback_porch /
> + (vm->hfront_porch + vm->hback_porch);
> } else {
> - if ((vm->hfront_porch + vm->hback_porch) * dsi_tmp_buf_bpp >
> - data_phy_cycles * dsi->lanes + 12) {
> - horizontal_frontporch_byte =
> - vm->hfront_porch * dsi_tmp_buf_bpp -
> - (data_phy_cycles * dsi->lanes + 12) *
> - vm->hfront_porch /
> - (vm->hfront_porch + vm->hback_porch);
> - horizontal_backporch_byte = horizontal_backporch_byte
> -
> - (data_phy_cycles * dsi->lanes + 12) *
> -
[PATCH v2 3/3] dt-binding: display: Require two resets on mantix panel
We need to reset both for the panel to show an image. Signed-off-by: Guido Günther --- .../bindings/display/panel/mantix,mlaf057we51-x.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml index 937323cc9aaa..51f423297ec8 100644 --- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml +++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml @@ -37,6 +37,9 @@ properties: reset-gpios: true + 'mantix,tp-rstn-gpios': +description: second reset line that triggers DSI config load + backlight: true required: @@ -63,6 +66,7 @@ examples: avee-supply = <_avee>; vddi-supply = <_1v8_p>; reset-gpios = < 29 GPIO_ACTIVE_LOW>; +mantix,tp-rstn-gpios = < 24 GPIO_ACTIVE_LOW>; backlight = <>; }; }; -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/panel: mantix: Don't dereference NULL mode
Don't dereference mode which was just NULL checked.
Signed-off-by: Guido Günther
Reported-by: Dan Carpenter
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 3482e28e30fc..4a7fbf64bb7a 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -204,7 +204,7 @@ static int mantix_get_modes(struct drm_panel *panel,
if (!mode) {
dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
default_mode.hdisplay, default_mode.vdisplay,
- drm_mode_vrefresh(mode));
+ drm_mode_vrefresh(_mode));
return -ENOMEM;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/panel: mantix: Fix panel reset
The mantix panel needs two reset lines (RESX and TP_RSTN) deasserted to
output an image. Only deasserting RESX is not enough and the display
will stay blank. Deassert in prepare() and assert in unprepare() to keep
device held in reset when off.
Signed-off-by: Guido Günther
---
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 23 +--
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 4a7fbf64bb7a..0c5f22e95c2d 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -26,7 +26,9 @@
struct mantix {
struct device *dev;
struct drm_panel panel;
+
struct gpio_desc *reset_gpio;
+ struct gpio_desc *tp_rstn_gpio;
struct regulator *avdd;
struct regulator *avee;
@@ -124,6 +126,10 @@ static int mantix_unprepare(struct drm_panel *panel)
{
struct mantix *ctx = panel_to_mantix(panel);
+ gpiod_set_value_cansleep(ctx->tp_rstn_gpio, 1);
+ usleep_range(5000, 6000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
regulator_disable(ctx->avee);
regulator_disable(ctx->avdd);
/* T11 */
@@ -165,13 +171,10 @@ static int mantix_prepare(struct drm_panel *panel)
return ret;
}
- /* T3+T5 */
- usleep_range(1, 12000);
-
- gpiod_set_value_cansleep(ctx->reset_gpio, 1);
- usleep_range(5150, 7000);
-
+ /* T3 + T4 + time for voltage to become stable: */
+ usleep_range(6000, 7000);
gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ gpiod_set_value_cansleep(ctx->tp_rstn_gpio, 0);
/* T6 */
msleep(50);
@@ -236,12 +239,18 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
if (!ctx)
return -ENOMEM;
- ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
dev_err(dev, "cannot get reset gpio\n");
return PTR_ERR(ctx->reset_gpio);
}
+ ctx->tp_rstn_gpio = devm_gpiod_get(dev, "mantix,tp-rstn",
GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->tp_rstn_gpio)) {
+ dev_err(dev, "cannot get tp-rstn gpio\n");
+ return PTR_ERR(ctx->tp_rstn_gpio);
+ }
+
mipi_dsi_set_drvdata(dsi, ctx);
ctx->dev = dev;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm/panel: mantix panel reset fixes
The first patch in this series fixes dereferencing a NULL mode in the error path. The second one extends the resets to not only reset RESX but also TP_RSTN since otherwise the display will stay completely blank. I didn't spot that before initial submission since the reset line was bound to the touch controller and although that failed to probe it came far enough to deassert the reset line (at an arbitrary point in time during boot) and hence we got a picture. Since touch and panel are on the same IC they're not completely independent and i might have to turn the whole thing into an MFD at some point but this series gets the panel to a reliably working state on boot and on fb blank/unblank. Since the reset-gpios are active low we can deassert in prepare and assert in unprepare simplifying the code making sure lines are kept low when the panel is off. The binding were not part of a stable kernel so I hope it's okay to not worry about backward compatibility. Changes from v1: - As per review comments by Fabio Estevam https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ - Fix typo in commit messages - As per review comments by Rob Herring https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ - Don't use an array of reset lines Guido Günther (3): drm/panel: mantix: Don't dereference NULL mode drm/panel: mantix: Fix panel reset dt-binding: display: Require two resets on mantix panel .../display/panel/mantix,mlaf057we51-x.yaml | 4 +++ .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 25 +-- 2 files changed, 21 insertions(+), 8 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vkms: fbdev emulation support
On Tue, 13 Oct 2020 09:53:44 +0200 Daniel Vetter wrote: > On Tue, Oct 13, 2020 at 8:14 AM Pekka Paalanen wrote: > > > > On Mon, 12 Oct 2020 16:23:35 +0200 > > Daniel Vetter wrote: > > > > > On Mon, Oct 12, 2020 at 02:40:58PM +0200, Neil Armstrong wrote: > > > > Hi, > > > > > > > > ... > > > > > > It's weird because it the kernel is misconfigured and no console is > > > > specified on the cmdline > > > > this console could become the main console... > > > > > > > > It's a great feature, but couldn't this be a module parameter ? > > > > > > If you have vkms enabled in a distro, you're doing it wrong. > > > > That's really not a great position to take. I would prefer that > > if a random contributor writes a Weston patch and runs 'meson test', it > > will use VKMS to run Weston's DRM-backend tests on his machine > > automatically, maybe save for some seat and device node access > > permissions bits which distributions could be delivering as well. > > > > Just put the VKMS device node into a non-default seat, and Xorg etc. > > will happily ignore it. > > > > For the fbdev device node, I don't know. Maybe a module parameter > > really is a good choice there, defaulting to off. I have no interest in > > testing anything against fbdev, but other people might disagree of > > course. > > > > Why? Gitlab CI is still not running tests for every commit, just per > > MR, and it might even be infeasible too. > > > > I am also hoping for a future where I don't have to build my own kernel > > just to be able to run Weston DRM tests with VKMS. That means I want to > > be able to run my machine with VKMS loaded and active at all times, > > without affecting the normal desktop. I already have such a setup with > > an extra AMD card, but you can't run most KMS tests against real > > hardware drivers. > > I just realized that building vkms is no problem, since it doesn't > auto-load. And if our Grand Plans with configurability come true, then > your test-harness will want to do that loading and setup itself > anyway. With that there also shouldn't be any problems with fbcon, > since presumably you already have that bound to the real gpu. > > So I think we're all fine here, for everyone. > > Now if you built-in vkms, that's a different thing. And for that I > really think a "don't do that" is the right choice. Very good. My remaining wish is that VKMS would be fully configurable and usable by an ordinary user, but I suppose that should be solved with a privileged userspace daemon somewhat similar to logind that hands out VKMS "sessions" somehow. Not sure configfs is the best choice for VKMS configuration, unless maybe unprivileged userspace could ask for a VKMS instance with its own configfs tree it can access without CAP_ADMIN... Thanks, pq pgpZipFhBdzTA.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/1] fix scrolling of panel with small hfp or hbp
Changes since v4: - Merge revert path and fixup patch to on patch Changes since v3: - Revert v2, for v2 will cause some bridge ic no output. the cause the video linetime doesn't match display mode from get mode. - Make sure the horizontal_frontporch_byte and horizontal_backporch_byte are > 0. Jitao Shi (1): drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp drivers/gpu/drm/mediatek/mtk_dsi.c | 65 +++--- 1 file changed, 25 insertions(+), 40 deletions(-) -- 2.12.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/1] drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp
Replace horizontal_backporch_byte with vm->hback_porch * bpp to aovid
flowing judgement negative number.
if ((vm->hfront_porch * dsi_tmp_buf_bpp + horizontal_backporch_byte) >
data_phy_cycles * dsi->lanes + delta)
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 65 +++---
1 file changed, 25 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 80b7a082e874..f69ebeaf 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -445,6 +445,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
u32 horizontal_backporch_byte;
u32 horizontal_frontporch_byte;
u32 dsi_tmp_buf_bpp, data_phy_cycles;
+ u32 delta;
struct mtk_phy_timing *timing = >phy_timing;
struct videomode *vm = >vm;
@@ -466,50 +467,34 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
horizontal_sync_active_byte = (vm->hsync_len * dsi_tmp_buf_bpp - 10);
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
- horizontal_backporch_byte = vm->hback_porch * dsi_tmp_buf_bpp;
+ horizontal_backporch_byte =
+ (vm->hback_porch * dsi_tmp_buf_bpp - 10);
else
- horizontal_backporch_byte = (vm->hback_porch + vm->hsync_len) *
- dsi_tmp_buf_bpp;
+ horizontal_backporch_byte = ((vm->hback_porch + vm->hsync_len) *
+ dsi_tmp_buf_bpp - 10);
data_phy_cycles = timing->lpx + timing->da_hs_prepare +
- timing->da_hs_zero + timing->da_hs_exit;
-
- if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
- if ((vm->hfront_porch + vm->hback_porch) * dsi_tmp_buf_bpp >
- data_phy_cycles * dsi->lanes + 18) {
- horizontal_frontporch_byte =
- vm->hfront_porch * dsi_tmp_buf_bpp -
- (data_phy_cycles * dsi->lanes + 18) *
- vm->hfront_porch /
- (vm->hfront_porch + vm->hback_porch);
-
- horizontal_backporch_byte =
- horizontal_backporch_byte -
- (data_phy_cycles * dsi->lanes + 18) *
- vm->hback_porch /
- (vm->hfront_porch + vm->hback_porch);
- } else {
- DRM_WARN("HFP less than d-phy, FPS will under 60Hz\n");
- horizontal_frontporch_byte = vm->hfront_porch *
-dsi_tmp_buf_bpp;
- }
+ timing->da_hs_zero + timing->da_hs_exit + 3;
+
+ delta = (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) ? 18 : 12;
+
+ if ((vm->hfront_porch * dsi_tmp_buf_bpp + horizontal_backporch_byte) >
+ data_phy_cycles * dsi->lanes + delta) {
+ horizontal_frontporch_byte =
+ vm->hfront_porch * dsi_tmp_buf_bpp -
+ (data_phy_cycles * dsi->lanes + delta) *
+ vm->hfront_porch /
+ (vm->hfront_porch + vm->hback_porch);
+
+ horizontal_backporch_byte =
+ horizontal_backporch_byte -
+ (data_phy_cycles * dsi->lanes + delta) *
+ vm->hback_porch /
+ (vm->hfront_porch + vm->hback_porch);
} else {
- if ((vm->hfront_porch + vm->hback_porch) * dsi_tmp_buf_bpp >
- data_phy_cycles * dsi->lanes + 12) {
- horizontal_frontporch_byte =
- vm->hfront_porch * dsi_tmp_buf_bpp -
- (data_phy_cycles * dsi->lanes + 12) *
- vm->hfront_porch /
- (vm->hfront_porch + vm->hback_porch);
- horizontal_backporch_byte = horizontal_backporch_byte -
- (data_phy_cycles * dsi->lanes + 12) *
- vm->hback_porch /
- (vm->hfront_porch + vm->hback_porch);
- } else {
- DRM_WARN("HFP less than d-phy, FPS will under 60Hz\n");
- horizontal_frontporch_byte = vm->hfront_porch *
-dsi_tmp_buf_bpp;
- }
+ DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
+ horizontal_frontporch_byte = vm->hfront_porch *
+dsi_tmp_buf_bpp;
}
writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
--
2.12.5
___
dri-devel mailing
Re: [v4 PATCH 0/2] fix scrolling of panel with small hfp or hbp
On Mon, 2020-10-12 at 23:22 +0800, Chun-Kuang Hu wrote: > Hi, Jitao: > > Jitao Shi 於 2020年10月10日 週六 下午3:09寫道： > > > > Changes since v3: > > - Revert v2, for v2 will cause some bridge ic no output. the cause > >the video linetime doesn't match display mode from get mode. > > - Make sure the horizontal_frontporch_byte and horizontal_backporch_byte > >are > 0. > > Because v2 is merged into mainline, I think you should merge 1/2 and > 2/2 to one patch which fix the problem caused by v2. > > Regards, > Chun-Kuang. > Thanks for your reviewing. I'll update next version. Best Regards Jitao > > > > Jitao Shi (2): > > Revert "drm/mediatek: dsi: Fix scrolling of panel with small hfp or > > hbp" > > drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp > > > > drivers/gpu/drm/mediatek/mtk_dsi.c | 65 > > +++--- > > 1 file changed, 25 insertions(+), 40 deletions(-) > > > > -- > > 2.12.5 > > ___ > > 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
[PATCH] drm/tegra: sor: Ensure regulators are disabled on teardown
The Tegra SOR driver uses the devm infrastructure to request regulators,
but enables them without registering them with the infrastructure.
This results in the following splat if probing fails for any odd resaon
(such as dependencies not being available):
[8.974187] tegra-sor 1558.sor: cannot get HDMI supply: -517
[9.414403] tegra-sor 1558.sor: failed to probe HDMI: -517
[9.421240] [ cut here ]
[9.425879] WARNING: CPU: 1 PID: 164 at drivers/regulator/core.c:2089
_regulator_put.part.0+0x16c/0x174
[9.435259] Modules linked in: tegra_drm(E+) cec(E) ahci_tegra(E)
drm_kms_helper(E) drm(E) libahci_platform(E) libahci(E) max77620_regulator(E)
xhci_tegra(E+) sdhci_tegra(E) xhci_hcd(E) libata(E) sdhci_pltfm(E) cqhci(E)
fixed(E) usbcore(E) scsi_mod(E) sdhci(E) host1x(E)
[9.459211] CPU: 1 PID: 164 Comm: systemd-udevd Tainted: G SD W E
5.9.0-rc7-00298-gf6337624c4fe #1980
[9.469285] Hardware name: NVIDIA Jetson TX2 Developer Kit (DT)
[9.475202] pstate: 8005 (Nzcv daif -PAN -UAO BTYPE=--)
[9.480784] pc : _regulator_put.part.0+0x16c/0x174
[9.485581] lr : regulator_put+0x44/0x60
[9.489501] sp : ffc011d837b0
[9.492814] x29: ffc011d837b0 x28: ff81dd085900
[9.498141] x27: ff81de1c8ec0 x26: ff81de1c8c10
[9.503464] x25: ff81dd085800 x24: ffc008f2c6b0
[9.508790] x23: ffc0117373f0 x22: 0005
[9.514101] x21: ff81dd085900 x20: ffc01172b098
[9.515822] ata1: SATA link down (SStatus 0 SControl 300)
[9.519426] x19: ff81dd085100 x18: 0030
[9.530122] x17: x16:
[9.535453] x15: x14: 038f
[9.540777] x13: 0003 x12: 0040
[9.546105] x11: ff81eb80 x10: 0ae0
[9.551417] x9 : ffc0106fea24 x8 : ff81de83e6c0
[9.556728] x7 : 0018 x6 : 03c3
[9.562064] x5 : 5660 x4 :
[9.567392] x3 : ffc01172b388 x2 : ff81de83db80
[9.572702] x1 : x0 : 0001
[9.578034] Call trace:
[9.580494] _regulator_put.part.0+0x16c/0x174
[9.584940] regulator_put+0x44/0x60
[9.588522] devm_regulator_release+0x20/0x2c
[9.592885] release_nodes+0x1c8/0x2c0
[9.596636] devres_release_all+0x44/0x6c
[9.600649] really_probe+0x1ec/0x504
[9.604316] driver_probe_device+0x100/0x170
[9.608589] device_driver_attach+0xcc/0xd4
[9.612774] __driver_attach+0xb0/0x17c
[9.616614] bus_for_each_dev+0x7c/0xd4
[9.620450] driver_attach+0x30/0x3c
[9.624027] bus_add_driver+0x154/0x250
[9.627867] driver_register+0x84/0x140
[9.631719] __platform_register_drivers+0xa0/0x180
[9.636660] host1x_drm_init+0x60/0x1000 [tegra_drm]
[9.641629] do_one_initcall+0x54/0x2d0
[9.645490] do_init_module+0x68/0x29c
[9.649244] load_module+0x2178/0x26c0
[9.652997] __do_sys_finit_module+0xb0/0x120
[9.657356] __arm64_sys_finit_module+0x2c/0x40
[9.661902] el0_svc_common.constprop.0+0x80/0x240
[9.666701] do_el0_svc+0x30/0xa0
[9.670022] el0_svc+0x18/0x50
[9.673081] el0_sync_handler+0x90/0x318
[9.677006] el0_sync+0x158/0x180
[9.680324] ---[ end trace 90f6c89d62d85ff6 ]---
Instead, let's register a callback that will disable the regulators
on teardown. This allows for the removal of the .remove callbacks,
which are not needed anymore.
Signed-off-by: Marc Zyngier
---
drivers/gpu/drm/tegra/sor.c | 59 +++--
1 file changed, 24 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 45b5258c77a2..39e6b32f6c10 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -397,7 +397,6 @@ struct tegra_sor;
struct tegra_sor_ops {
const char *name;
int (*probe)(struct tegra_sor *sor);
- int (*remove)(struct tegra_sor *sor);
void (*audio_enable)(struct tegra_sor *sor);
void (*audio_disable)(struct tegra_sor *sor);
};
@@ -2942,6 +2941,24 @@ static const struct drm_encoder_helper_funcs
tegra_sor_dp_helpers = {
.atomic_check = tegra_sor_encoder_atomic_check,
};
+static void tegra_sor_disable_regulator(void *data)
+{
+ struct regulator *reg = data;
+
+ regulator_disable(reg);
+}
+
+static int tegra_sor_enable_regulator(struct tegra_sor *sor, struct regulator
*reg)
+{
+ int err;
+
+ err = regulator_enable(reg);
+ if (err)
+ return err;
+
+ return devm_add_action_or_reset(sor->dev, tegra_sor_disable_regulator,
reg);
+}
+
static int tegra_sor_hdmi_probe(struct tegra_sor *sor)
{
int err;
@@ -2953,7 +2970,7 @@ static int tegra_sor_hdmi_probe(struct tegra_sor *sor)
return PTR_ERR(sor->avdd_io_supply);
}
- err = regulator_enable(sor->avdd_io_supply);
+
Re: [PATCH v1] drm/virtio: Use UUID API for importing the UUID
On Mon, Oct 12, 2020 at 08:18:26PM +0300, Andy Shevchenko wrote: > There is import_uuid() function which imports u8 array to the uuid_t. > Use it instead of open coding variant. > > This allows to hide the uuid_t internals. Doesn't apply to drm-misc-next, please rebase. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/stm: dsi: Use dev_ based logging
Standardize on the dev_ based logging.
Signed-off-by: Yannick Fertre
---
Changes in v2:
- restore function dsi_color_from_mipi.
- reword commit.
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 55 ++-
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 164f79ef6269..a5a87c89aa07 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -76,6 +76,7 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
+ struct device *dev;
struct clk *pllref_clk;
struct dw_mipi_dsi *dsi;
u32 hw_version;
@@ -110,7 +111,8 @@ static inline void dsi_update_bits(struct dw_mipi_dsi_stm
*dsi, u32 reg,
dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val);
}
-static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt)
+static enum dsi_color dsi_color_from_mipi(struct dw_mipi_dsi_stm *dsi,
+ enum mipi_dsi_pixel_format fmt)
{
switch (fmt) {
case MIPI_DSI_FMT_RGB888:
@@ -122,7 +124,7 @@ static enum dsi_color dsi_color_from_mipi(enum
mipi_dsi_pixel_format fmt)
case MIPI_DSI_FMT_RGB565:
return DSI_RGB565_CONF1;
default:
- DRM_DEBUG_DRIVER("MIPI color invalid, so we use rgb888\n");
+ dev_dbg(dsi->dev, "MIPI color invalid, so we use rgb888\n");
}
return DSI_RGB888;
}
@@ -205,14 +207,14 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
SLEEP_US, TIMEOUT_US);
if (ret)
- DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
+ dev_dbg(dsi->dev, "!TIMEOUT! waiting REGU, let's continue\n");
/* Enable the DSI PLL & wait for its lock */
dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
SLEEP_US, TIMEOUT_US);
if (ret)
- DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
+ dev_dbg(dsi->dev, "!TIMEOUT! waiting PLL, let's continue\n");
return 0;
}
@@ -221,7 +223,7 @@ static void dw_mipi_dsi_phy_power_on(void *priv_data)
{
struct dw_mipi_dsi_stm *dsi = priv_data;
- DRM_DEBUG_DRIVER("\n");
+ dev_dbg(dsi->dev, "\n");
/* Enable the DSI wrapper */
dsi_set(dsi, DSI_WCR, WCR_DSIEN);
@@ -231,7 +233,7 @@ static void dw_mipi_dsi_phy_power_off(void *priv_data)
{
struct dw_mipi_dsi_stm *dsi = priv_data;
- DRM_DEBUG_DRIVER("\n");
+ dev_dbg(dsi->dev, "\n");
/* Disable the DSI wrapper */
dsi_clear(dsi, DSI_WCR, WCR_DSIEN);
@@ -267,11 +269,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
if (pll_out_khz > dsi->lane_max_kbps) {
pll_out_khz = dsi->lane_max_kbps;
- DRM_WARN("Warning max phy mbps is used\n");
+ dev_warn(dsi->dev, "Warning max phy mbps is used\n");
}
if (pll_out_khz < dsi->lane_min_kbps) {
pll_out_khz = dsi->lane_min_kbps;
- DRM_WARN("Warning min phy mbps is used\n");
+ dev_warn(dsi->dev, "Warning min phy mbps is used\n");
}
/* Compute best pll parameters */
@@ -281,7 +283,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
ret = dsi_pll_get_params(dsi, pll_in_khz, pll_out_khz,
, , );
if (ret)
- DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
+ dev_warn(dsi->dev, "Warning dsi_pll_get_params(): bad
params\n");
/* Get the adjusted pll out value */
pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
@@ -299,12 +301,12 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
/* Select the color coding */
dsi_update_bits(dsi, DSI_WCFGR, WCFGR_COLMUX,
- dsi_color_from_mipi(format) << 1);
+ dsi_color_from_mipi(dsi, format) << 1);
*lane_mbps = pll_out_khz / 1000;
- DRM_DEBUG_DRIVER("pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
-pll_in_khz, pll_out_khz, *lane_mbps);
+ dev_dbg(dsi->dev, "pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
pll_in_khz, pll_out_khz,
+ *lane_mbps);
return 0;
}
@@ -352,11 +354,13 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
if (!dsi)
return -ENOMEM;
+ dsi->dev = dev;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dsi->base = devm_ioremap_resource(dev, res);
if (IS_ERR(dsi->base)) {
Re: [PATCH 3/3] drm/vkms: fbdev emulation support
On Tue, Oct 13, 2020 at 8:14 AM Pekka Paalanen wrote: > > On Mon, 12 Oct 2020 16:23:35 +0200 > Daniel Vetter wrote: > > > On Mon, Oct 12, 2020 at 02:40:58PM +0200, Neil Armstrong wrote: > > > Hi, > > > > > ... > > > > It's weird because it the kernel is misconfigured and no console is > > > specified on the cmdline > > > this console could become the main console... > > > > > > It's a great feature, but couldn't this be a module parameter ? > > > > If you have vkms enabled in a distro, you're doing it wrong. > > That's really not a great position to take. I would prefer that > if a random contributor writes a Weston patch and runs 'meson test', it > will use VKMS to run Weston's DRM-backend tests on his machine > automatically, maybe save for some seat and device node access > permissions bits which distributions could be delivering as well. > > Just put the VKMS device node into a non-default seat, and Xorg etc. > will happily ignore it. > > For the fbdev device node, I don't know. Maybe a module parameter > really is a good choice there, defaulting to off. I have no interest in > testing anything against fbdev, but other people might disagree of > course. > > Why? Gitlab CI is still not running tests for every commit, just per > MR, and it might even be infeasible too. > > I am also hoping for a future where I don't have to build my own kernel > just to be able to run Weston DRM tests with VKMS. That means I want to > be able to run my machine with VKMS loaded and active at all times, > without affecting the normal desktop. I already have such a setup with > an extra AMD card, but you can't run most KMS tests against real > hardware drivers. I just realized that building vkms is no problem, since it doesn't auto-load. And if our Grand Plans with configurability come true, then your test-harness will want to do that loading and setup itself anyway. With that there also shouldn't be any problems with fbcon, since presumably you already have that bound to the real gpu. So I think we're all fine here, for everyone. Now if you built-in vkms, that's a different thing. And for that I really think a "don't do that" is the right choice. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the iommu tree
Hi all,
On Mon, 21 Sep 2020 14:09:01 +1000 Stephen Rothwell
wrote:
>
> After merging the iommu tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/drm/msm/msm_iommu.c: In function 'msm_iommu_pagetable_unmap':
> drivers/gpu/drm/msm/msm_iommu.c:46:2: error: implicit declaration of function
> 'iommu_flush_tlb_all'; did you mean 'iommu_flush_iotlb_all'?
> [-Werror=implicit-function-declaration]
>46 | iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> | ^~~
> | iommu_flush_iotlb_all
>
> Caused by commit
>
> aae4c8e27bd7 ("iommu: Rename iommu_tlb_* functions to iommu_iotlb_*")
>
> interacting with commit
>
> b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
>
> from the drm-msm tree.
>
> I have applied the following merge fix patch. Someone will need to tell
> Linus about this fix up when the trees get merged.
>
> From: Stephen Rothwell
> Date: Mon, 21 Sep 2020 14:04:14 +1000
> Subject: [PATCH] merge fix upt for iommu_flush_iotlb_all() rename
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/msm/msm_iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 3a83ffdb3b90..22ac7c692a81 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -43,7 +43,7 @@ static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu,
> u64 iova,
> size -= 4096;
> }
>
> - iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> + iommu_flush_iotlb_all(to_msm_iommu(pagetable->parent)->domain);
>
> return (unmapped == size) ? 0 : -EINVAL;
> }
> @@ -199,7 +199,7 @@ struct msm_mmu *msm_iommu_pagetable_create(struct msm_mmu
> *parent)
>
> /*
>* TODO we would like each set of page tables to have a unique ASID
> - * to optimize TLB invalidation. But iommu_flush_tlb_all() will
> + * to optimize TLB invalidation. But iommu_flush_iotlb_all() will
>* end up flushing the ASID used for TTBR1 pagetables, which is not
>* what we want. So for now just use the same ASID as TTBR1.
>*/
> --
> 2.28.0
This merge fix up is now needed when the iommu tree and the drm tree are merged.
--
Cheers,
Stephen Rothwell
pgpFZ0pg1chNY.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
Hi Stephen,
Le lun. 12 oct. 2020 à 15:24, Stephen Rothwell
a écrit :
Hi all,
On Thu, 8 Oct 2020 15:42:02 +1100 Stephen Rothwell
wrote:
On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
In file included from include/linux/clk.h:13,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:10:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c: In function
'ingenic_drm_update_palette':
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct
ingenic_drm' has no member named 'dma_hwdescs'; did you mean
'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~~
include/linux/kernel.h:47:33: note: in definition of macro
'ARRAY_SIZE'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
| ^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct
ingenic_drm' has no member named 'dma_hwdescs'; did you mean
'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~~
include/linux/kernel.h:47:48: note: in definition of macro
'ARRAY_SIZE'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|^~~
In file included from include/linux/bits.h:22,
from include/linux/bitops.h:5,
from drivers/gpu/drm/ingenic/ingenic-drm.h:10,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:7:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct
ingenic_drm' has no member named 'dma_hwdescs'; did you mean
'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~~
include/linux/build_bug.h:16:62: note: in definition of macro
'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct {
int:(-!!(e)); })))
|
^
include/linux/compiler.h:224:46: note: in expansion of macro
'__same_type'
224 | #define __must_be_array(a)
BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
| ^~~
include/linux/kernel.h:47:59: note: in expansion of macro
'__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in
expansion of macro 'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:35: error: 'struct
ingenic_drm' has no member named 'dma_hwdescs'; did you mean
'dma_hwdesc_f0'?
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~~
include/linux/build_bug.h:16:62: note: in definition of macro
'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct {
int:(-!!(e)); })))
|
^
include/linux/compiler.h:224:46: note: in expansion of macro
'__same_type'
224 | #define __must_be_array(a)
BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
| ^~~
include/linux/kernel.h:47:59: note: in expansion of macro
'__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in
expansion of macro 'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
| ^~
include/linux/build_bug.h:16:51: error: bit-field ''
width not an integer constant
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct {
int:(-!!(e)); })))
| ^
include/linux/compiler.h:224:28: note: in expansion of macro
'BUILD_BUG_ON_ZERO'
224 | #define __must_be_array(a)
BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
|^
include/linux/kernel.h:47:59: note: in expansion of macro
'__must_be_array'
47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
|
^~~
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:448:18: note: in
expansion of macro 'ARRAY_SIZE'
448 | for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette);
i++) {
Re: [PATCH v2 08/17] s390/pci: Remove races against pte updates
Hi Daniel,
freshly back from my vacation I've just taken a look at your patch.
First thanks for this fix and the detailed commit description.
Definitely makes sense to fix this and you can add my
Acked-by: Niklas Schnelle
Content wise it all looks sane and clear and since Gerald did the testing,
I would have applied it to our tree already, but I got some trivial
checkpatch violations that probably apply to the whole series.
I've commented them inline below.
If you confirm there I can do the fixups when applying or you can resend.
On 10/9/20 9:59 AM, Daniel Vetter wrote:
> Way back it was a reasonable assumptions that iomem mappings never
> change the pfn range they point at. But this has changed:
>
> - gpu drivers dynamically manage their memory nowadays, invalidating
> ptes with unmap_mapping_range when buffers get moved
>
> - contiguous dma allocations have moved from dedicated carvetouts to
> cma regions. This means if we miss the unmap the pfn might contain
> pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
>
> - even /dev/mem now invalidates mappings when the kernel requests that
> iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
The above commit mention should use the format
'commit 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region")'
otherwise this results in a checkpatch ERROR.
> ("/dev/mem: Revoke mappings when a driver claims the region")
>
> Accessing pfns obtained from ptes without holding all the locks is
> therefore no longer a good idea. Fix this.
>
> Since zpci_memcpy_from|toio seems to not do anything nefarious with
> locks we just need to open code get_pfn and follow_pfn and make sure
> we drop the locks only after we've done. The write function also needs
just a typo but just saw it "we're" instead of "we've"
> the copy_from_user move, since we can't take userspace faults while
> holding the mmap sem.
>
> Reviewed-by: Gerald Schaefer
>
No empty line after the Revied-by tag.
> Signed-off-by: Daniel Vetter
Your Signed-off-by mail address does not match the one you're sending from,
this yields a checkpatch warning when using git am with your mail.
This is probably just a silly misconfiguration but since Signed-offs
are signatures should I change this to
"Daniel Vetter " which is the one you're
sending from and also in the MAINTAINERS file?
> Cc: Jason Gunthorpe
> Cc: Dan Williams
> Cc: Kees Cook
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
The above Cc: line for Dan Williams is a duplicate
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Niklas Schnelle
> Cc: Gerald Schaefer
> Cc: linux-s...@vger.kernel.org
> --
> v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL
> like before (Gerard)
I think the above should go before the CC/Signed-off/Reviewev block.
> ---
> arch/s390/pci/pci_mmio.c | 98 +++-
> 1 file changed, 57 insertions(+), 41 deletions(-)
>
> diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c
> index 401cf670a243..1a6adbc68ee8 100644
> --- a/arch/s390/pci/pci_mmio.c
> +++ b/arch/s390/pci/pci_mmio.c
> @@ -119,33 +119,15 @@ static inline int __memcpy_toio_inuser(void __iomem
> *dst,
> return rc;
> }
>
> -static long get_pfn(unsigned long user_addr, unsigned long access,
> - unsigned long *pfn)
> -{
> - struct vm_area_struct *vma;
> - long ret;
> -
> - mmap_read_lock(current->mm);
> - ret = -EINVAL;
> - vma = find_vma(current->mm, user_addr);
> - if (!vma)
> - goto out;
> - ret = -EACCES;
> - if (!(vma->vm_flags & access))
> - goto out;
> - ret = follow_pfn(vma, user_addr, pfn);
> -out:
> - mmap_read_unlock(current->mm);
> - return ret;
> -}
> -
> SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr,
> const void __user *, user_buffer, size_t, length)
> {
> u8 local_buf[64];
> void __iomem *io_addr;
> void *buf;
> - unsigned long pfn;
> + struct vm_area_struct *vma;
> + pte_t *ptep;
> + spinlock_t *ptl;
With checkpatch.pl --strict the above yields a complained
"CHECK: spinlock_t definition without comment" but I think
that's really okay since your commit description is very clear.
Same oin line 277.
... snip ...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm/armada: fix unused parameter warning
Functions armada_drm_crtc_atomic_flush &
armada_drm_crtc_atomic_enable don`t use the second parameter.
So we may get warning like :
warning: unused parameter ‘***’ [-Wunused-parameter].
This change is to fix the compile warning with -Wunused-parameter.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/armada/armada_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 38dfaa46d306..fc8b922c3e44 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -427,7 +427,7 @@ static int armada_drm_crtc_atomic_check(struct drm_crtc
*crtc,
}
static void armada_drm_crtc_atomic_begin(struct drm_crtc *crtc,
-struct drm_crtc_state *old_crtc_state)
+ struct drm_crtc_state __attribute__((unused))
*old_crtc_state)
{
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
@@ -441,7 +441,7 @@ static void armada_drm_crtc_atomic_begin(struct drm_crtc
*crtc,
}
static void armada_drm_crtc_atomic_flush(struct drm_crtc *crtc,
-struct drm_crtc_state *old_crtc_state)
+ struct drm_crtc_state __attribute__((unused))
*old_crtc_state)
{
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Introduce devm_pm_opp_set_* API
Hi, this patchset introduce devm_pm_opp_set_prop_name() and devm_pm_opp_set_supported_hw(). Yangtao Li (3): opp: Add devres wrapper for dev_pm_opp_set_supported_hw opp: Add devres wrapper for dev_pm_opp_set_prop_name drm/msm: Convert to devm_pm_opp_set_supported_hw drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +- drivers/opp/core.c| 80 +++ include/linux/pm_opp.h| 14 + 3 files changed, 95 insertions(+), 1 deletion(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next-fixes
Hi Dave, Here's the remaining patches we have in drm-misc-next-fixes Maxime drm-misc-next-fixes-2020-10-13: One fix for a bad revert in ingenic-drm, and one fix for panfrost to increase a timeout at power up. The following changes since commit 8ba0b6d196315f68c271f549e8585129caefce97: drm/vc4: crtc: Keep the previously assigned HVS FIFO (2020-09-25 16:56:21 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-10-13 for you to fetch changes up to d3c8f2784d3266d27956659c78835ee1d1925ad2: drm/ingenic: Fix bad revert (2020-10-12 20:26:14 +0200) One fix for a bad revert in ingenic-drm, and one fix for panfrost to increase a timeout at power up. Christian Hewitt (1): drm/panfrost: increase readl_relaxed_poll_timeout values Ondrej Jirman (1): MAINTAINERS: Update entry for st7703 driver after the rename Paul Cercueil (2): Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached" drm/ingenic: Fix bad revert MAINTAINERS | 7 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 114 +- drivers/gpu/drm/ingenic/ingenic-drm.h | 4 -- drivers/gpu/drm/ingenic/ingenic-ipu.c | 12 +--- drivers/gpu/drm/panfrost/panfrost_gpu.c | 4 +- 5 files changed, 10 insertions(+), 131 deletions(-) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ingenic: Fix bad revert
Le lun. 12 oct. 2020 à 16:10, Daniel Vetter a écrit
:
On Mon, Oct 12, 2020 at 12:25:09PM +0200, Paul Cercueil wrote:
Fix a badly reverted commit. The revert commit was cherry-picked
from
drm-misc-next to drm-misc-next-fixes, and in the process some
unrelated
code was added.
Fixes: a3fb64c00d44 "Revert "gpu/drm: ingenic: Add option to mmap
GEM buffers cached""
Signed-off-by: Paul Cercueil
Acked-by: Daniel Vetter
I applied the patch to drm-misc-next-fixes.
Thanks,
-Paul
And yes if you use git cherry-pick it'll do a 3 way merge, and
occasionally it's very tricky to resolve that properly. Especially
when
you're not used to it.
What I tend to do to double check cerry-picks is git show both
commits,
and compare the entire diff line-by-line to make sure I didn't
misplace
anything.
Another trick is to use the raw patch instead of cherry-pick, since
that
won't do a 3 way merge where you might get confused with other
context and
fun stuff like that.
Cheers, Daniel
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 1be1235bd546..a3d1617d7c67 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -440,20 +440,6 @@ void ingenic_drm_plane_config(struct device
*dev,
}
}
-static void ingenic_drm_update_palette(struct ingenic_drm *priv,
- const struct drm_color_lut *lut)
-{
- unsigned int i;
-
- for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
- u16 color = drm_color_lut_extract(lut[i].red, 5) << 11
- | drm_color_lut_extract(lut[i].green, 6) << 5
- | drm_color_lut_extract(lut[i].blue, 5);
-
- priv->dma_hwdescs->palette[i] = color;
- }
-}
-
static void ingenic_drm_plane_atomic_update(struct drm_plane
*plane,
struct drm_plane_state *oldstate)
{
@@ -464,8 +450,6 @@ static void
ingenic_drm_plane_atomic_update(struct drm_plane *plane,
dma_addr_t addr;
if (state && state->fb) {
- crtc_state = state->crtc->state;
-
addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
width = state->src_w >> 16;
height = state->src_h >> 16;
--
2.28.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] Revert "drm/mediatek: dsi: Fix scrolling of panel with small hfp or hbp"
Hi Jitao,
On Sat, 10 Oct 2020 15:09:09 +0800
Jitao Shi wrote:
> This reverts commit 35bf948f1edbf507f6e57e0879fa6ea36d2d2930.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c index 80b7a082e874..16fd99dcdacf
> 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -466,13 +466,14 @@ static void mtk_dsi_config_vdo_timing(struct
> mtk_dsi *dsi) horizontal_sync_active_byte = (vm->hsync_len *
> dsi_tmp_buf_bpp - 10);
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> - horizontal_backporch_byte = vm->hback_porch *
> dsi_tmp_buf_bpp;
> + horizontal_backporch_byte =
> + (vm->hback_porch * dsi_tmp_buf_bpp - 10);
> else
> - horizontal_backporch_byte = (vm->hback_porch +
> vm->hsync_len) *
> - dsi_tmp_buf_bpp;
> + horizontal_backporch_byte = ((vm->hback_porch +
> vm->hsync_len) *
> + dsi_tmp_buf_bpp - 10);
>
> data_phy_cycles = timing->lpx + timing->da_hs_prepare +
> - timing->da_hs_zero + timing->da_hs_exit;
> + timing->da_hs_zero + timing->da_hs_exit +
> 3;
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> if ((vm->hfront_porch + vm->hback_porch) *
> dsi_tmp_buf_bpp >
Reviewed-by: Bilal Wasim
Tested-by: Bilal Wasim
Thanks,
Bilal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/dp check aux_dev before use in drm_dp_aux_dev_get_by_minor()
I observed this when unplugging a DP monitor whilst a computer is asleep
and then waking it up. This left DP chardev nodes still being present on
the filesystem and accessing these device nodes caused an oops because
drm_dp_aux_dev_get_by_minor() assumes a device exists if it is opened.
This can also be reproduced by creating a device node with mknod(1) and
issuing an open(2)
[166164.933198] BUG: kernel NULL pointer dereference, address: 0018
[166164.933202] #PF: supervisor read access in kernel mode
[166164.933204] #PF: error_code(0x) - not-present page
[166164.933205] PGD 0 P4D 0
[166164.933208] Oops: [#1] PREEMPT SMP NOPTI
[166164.933211] CPU: 4 PID: 99071 Comm: fwupd Tainted: GW
5.8.0-rc6+ #1
[166164.933213] Hardware name: LENOVO 20RD002VUS/20RD002VUS, BIOS R16ET25W
(1.11 ) 04/21/2020
[166164.933232] RIP: 0010:drm_dp_aux_dev_get_by_minor+0x29/0x70
[drm_kms_helper]
[166164.933234] Code: 00 0f 1f 44 00 00 55 48 89 e5 41 54 41 89 fc 48 c7
c7 60 01 a4 c0 e8 26 ab 30 d7 44 89 e6 48 c7 c7 80 01 a4 c0 e8 47 94 d6 d6
<8b> 50 18 49 89 c4 48 8d 78 18 85 d2 74 33 8d 4a 01 89 d0 f0 0f b1
[166164.933236] RSP: 0018:b7d7c41cbbf0 EFLAGS: 00010246
[166164.933237] RAX: RBX: 8a90001fe900 RCX:
[166164.933238] RDX: RSI: 0003 RDI:
c0a40180
[166164.933239] RBP: b7d7c41cbbf8 R08: R09:
8a93e157d6d0
[166164.933240] R10: R11: c0a40188 R12:
0003
[166164.933241] R13: 8a9402200e80 R14: 8a90001fe900 R15:
[166164.933244] FS: 7f7fb041eb00() GS:8a941150()
knlGS:
[166164.933245] CS: 0010 DS: ES: CR0: 80050033
[166164.933246] CR2: 0018 CR3: 352c2003 CR4:
003606e0
[166164.933247] Call Trace:
[166164.933264] auxdev_open+0x1b/0x40 [drm_kms_helper]
[166164.933278] chrdev_open+0xa7/0x1c0
[166164.933282] ? cdev_put.part.0+0x20/0x20
[166164.933287] do_dentry_open+0x161/0x3c0
[166164.933291] vfs_open+0x2d/0x30
[166164.933297] path_openat+0xb27/0x10e0
[166164.933306] ? atime_needs_update+0x73/0xd0
[166164.933309] do_filp_open+0x91/0x100
[166164.933313] ? __alloc_fd+0xb2/0x150
[166164.933316] do_sys_openat2+0x210/0x2d0
[166164.933318] do_sys_open+0x46/0x80
[166164.933320] __x64_sys_openat+0x20/0x30
[166164.933328] do_syscall_64+0x52/0xc0
[166164.96] entry_SYSCALL_64_after_hwframe+0x44/0xa9
(gdb) disassemble drm_dp_aux_dev_get_by_minor+0x29
Dump of assembler code for function drm_dp_aux_dev_get_by_minor:
0x00017b10 <+0>: callq 0x17b15
0x00017b15 <+5>: push %rbp
0x00017b16 <+6>: mov%rsp,%rbp
0x00017b19 <+9>: push %r12
0x00017b1b <+11>:mov%edi,%r12d
0x00017b1e <+14>:mov$0x0,%rdi
0x00017b25 <+21>:callq 0x17b2a
0x00017b2a <+26>:mov%r12d,%esi
0x00017b2d <+29>:mov$0x0,%rdi
0x00017b34 <+36>:callq 0x17b39
0x00017b39 <+41>:mov0x18(%rax),%edx <=
0x00017b3c <+44>:mov%rax,%r12
0x00017b3f <+47>:lea0x18(%rax),%rdi
0x00017b43 <+51>:test %edx,%edx
0x00017b45 <+53>:je 0x17b7a
0x00017b47 <+55>:lea0x1(%rdx),%ecx
0x00017b4a <+58>:mov%edx,%eax
0x00017b4c <+60>:lock cmpxchg %ecx,(%rdi)
0x00017b50 <+64>:jne0x17b76
0x00017b52 <+66>:test %edx,%edx
0x00017b54 <+68>:js 0x17b6d
0x00017b56 <+70>:test %ecx,%ecx
0x00017b58 <+72>:js 0x17b6d
0x00017b5a <+74>:mov$0x0,%rdi
0x00017b61 <+81>:callq 0x17b66
0x00017b66 <+86>:mov%r12,%rax
0x00017b69 <+89>:pop%r12
0x00017b6b <+91>:pop%rbp
0x00017b6c <+92>:retq
0x00017b6d <+93>:xor%esi,%esi
0x00017b6f <+95>:callq 0x17b74
0x00017b74 <+100>: jmp0x17b5a
0x00017b76 <+102>: mov%eax,%edx
0x00017b78 <+104>: jmp0x17b43
0x00017b7a <+106>: xor%r12d,%r12d
0x00017b7d <+109>: jmp0x17b5a
End of assembler dump.
(gdb) list *drm_dp_aux_dev_get_by_minor+0x29
0x17b39 is in drm_dp_aux_dev_get_by_minor (drivers/gpu/drm/drm_dp_aux_dev.c:65).
60 static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned
index)
61 {
62 struct drm_dp_aux_dev *aux_dev = NULL;
63
64 mutex_lock(_idr_mutex);
65 aux_dev = idr_find(_idr, index);
66 if (!kref_get_unless_zero(_dev->refcount))
67 aux_dev = NULL;
68 mutex_unlock(_idr_mutex);
69
(gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount
$8 = 0x18
Looking
Re: [PATCH v1] drm/virtio: Use UUID API for importing the UUID
Reviewed-by: David Stevens
On Tue, Oct 13, 2020 at 2:18 AM Andy Shevchenko
wrote:
>
> There is import_uuid() function which imports u8 array to the uuid_t.
> Use it instead of open coding variant.
>
> This allows to hide the uuid_t internals.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 07945ca238e2..8944cc0bf8eb 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -1129,7 +1129,7 @@ static void virtio_gpu_cmd_resource_uuid_cb(struct
> virtio_gpu_device *vgdev,
>
> if (resp_type == VIRTIO_GPU_RESP_OK_RESOURCE_UUID &&
> obj->uuid_state == UUID_INITIALIZING) {
> - memcpy(>uuid.b, resp->uuid, sizeof(obj->uuid.b));
> + import_uuid(>uuid, resp->uuid);
> obj->uuid_state = UUID_INITIALIZED;
> } else {
> obj->uuid_state = UUID_INITIALIZATION_FAILED;
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] opp: Add devres wrapper for dev_pm_opp_set_supported_hw
From: Yangtao Li
Add devres wrapper for dev_pm_opp_set_supported_hw() to simplify driver
code.
Signed-off-by: Yangtao Li
Signed-off-by: Yangtao Li
---
drivers/opp/core.c | 41 +
include/linux/pm_opp.h | 8
2 files changed, 49 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 3ca7543142bf..b38852dde578 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1625,6 +1625,47 @@ void dev_pm_opp_put_supported_hw(struct opp_table
*opp_table)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_put_supported_hw);
+static void devm_pm_opp_put_supported_hw(struct device *dev, void *res)
+{
+ dev_pm_opp_put_supported_hw(*(struct opp_table **)res);
+}
+
+/**
+ * devm_pm_opp_set_supported_hw() - Set supported platforms
+ * @dev: Device for which supported-hw has to be set.
+ * @versions: Array of hierarchy of versions to match.
+ * @count: Number of elements in the array.
+ *
+ * This is required only for the V2 bindings, and it enables a platform to
+ * specify the hierarchy of versions it supports. OPP layer will then enable
+ * OPPs, which are available for those versions, based on its
'opp-supported-hw'
+ * property.
+ *
+ * The opp_table structure will be freed after the device is destroyed.
+ */
+struct opp_table *devm_pm_opp_set_supported_hw(struct device *dev,
+ const u32 *versions,
+ unsigned int count)
+{
+ struct opp_table **ptr, *opp_table;
+
+ ptr = devres_alloc(devm_pm_opp_put_supported_hw,
+ sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ opp_table = dev_pm_opp_set_supported_hw(dev, versions, count);
+ if (!IS_ERR(opp_table)) {
+ *ptr = opp_table;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return opp_table;
+}
+EXPORT_SYMBOL(devm_pm_opp_set_supported_hw);
+
/**
* dev_pm_opp_set_prop_name() - Set prop-extn name
* @dev: Device for which the prop-name has to be set.
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index dbb484524f82..901920e29c54 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -140,6 +140,7 @@ int dev_pm_opp_unregister_notifier(struct device *dev,
struct notifier_block *nb
struct opp_table *dev_pm_opp_set_supported_hw(struct device *dev, const u32
*versions, unsigned int count);
void dev_pm_opp_put_supported_hw(struct opp_table *opp_table);
+struct opp_table *devm_pm_opp_set_supported_hw(struct device *dev, const u32
*versions, unsigned int count);
struct opp_table *dev_pm_opp_set_prop_name(struct device *dev, const char
*name);
void dev_pm_opp_put_prop_name(struct opp_table *opp_table);
struct opp_table *dev_pm_opp_set_regulators(struct device *dev, const char *
const names[], unsigned int count);
@@ -298,6 +299,13 @@ static inline struct opp_table
*dev_pm_opp_set_supported_hw(struct device *dev,
static inline void dev_pm_opp_put_supported_hw(struct opp_table *opp_table) {}
+static inline struct opp_table *devm_pm_opp_set_supported_hw(struct device
*dev,
+const u32
*versions,
+unsigned int count)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
+
static inline struct opp_table *dev_pm_opp_register_set_opp_helper(struct
device *dev,
int (*set_opp)(struct dev_pm_set_opp_data *data))
{
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/17] s390/pci: Remove races against pte updates
... snip ...
>>> Cc: linux-me...@vger.kernel.org
>>> Cc: Niklas Schnelle
>>> Cc: Gerald Schaefer
>>> Cc: linux-s...@vger.kernel.org
>>> --
>>> v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL
>>> like before (Gerard)
>>
>> I think the above should go before the CC/Signed-off/Reviewev block.
>
> This is a per-subsystem bikeshed :-) drivers/gpu definitely wants it
> above, but most core subsystems want it below. I'll move it.
Today I learned, thanks! That said I think most of the time I've
actually not seen version change information in the commit message itself
only in the cover letters. I really don't care just looked odd to me.
>
>>> ---
>>> arch/s390/pci/pci_mmio.c | 98 +++-
>>> 1 file changed, 57 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c
>>> index 401cf670a243..1a6adbc68ee8 100644
>>> --- a/arch/s390/pci/pci_mmio.c
>>> +++ b/arch/s390/pci/pci_mmio.c
>>> @@ -119,33 +119,15 @@ static inline int __memcpy_toio_inuser(void __iomem
>>> *dst,
>>> return rc;
>>> }
>>>
>>> -static long get_pfn(unsigned long user_addr, unsigned long access,
>>> - unsigned long *pfn)
>>> -{
>>> - struct vm_area_struct *vma;
>>> - long ret;
>>> -
>>> - mmap_read_lock(current->mm);
>>> - ret = -EINVAL;
>>> - vma = find_vma(current->mm, user_addr);
>>> - if (!vma)
>>> - goto out;
>>> - ret = -EACCES;
>>> - if (!(vma->vm_flags & access))
>>> - goto out;
>>> - ret = follow_pfn(vma, user_addr, pfn);
>>> -out:
>>> - mmap_read_unlock(current->mm);
>>> - return ret;
>>> -}
>>> -
>>> SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr,
>>> const void __user *, user_buffer, size_t, length)
>>> {
>>> u8 local_buf[64];
>>> void __iomem *io_addr;
>>> void *buf;
>>> - unsigned long pfn;
>>> + struct vm_area_struct *vma;
>>> + pte_t *ptep;
>>> + spinlock_t *ptl;
>>
>> With checkpatch.pl --strict the above yields a complained
>> "CHECK: spinlock_t definition without comment" but I think
>> that's really okay since your commit description is very clear.
>> Same oin line 277.
>
> I think this is a falls positive, checkpatch doesn't realize that
> SYSCALL_DEFINE3 is a function, not a structure. And in a structure I'd
> have added the kerneldoc or comment.
Interesting, your theory sounds convincing, I too thought this
was a bit too pedantic.
>
> I'll fix up all the nits you've found for the next round. Thanks for
> taking a look.
You're welcome hope I didn't sound pedantic. I think you've a lot
more experience actually and this can indeed turn into bikeshedding
but since I was answering anyway and most of this was checkpatch…
> -Daniel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
On Mon, Oct 12, 2020 at 12:53:54PM -0700, Ira Weiny wrote: > On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote: > > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote: > > > kmap_atomic() is always preferred over kmap()/kmap_thread(). > > > kmap_atomic() is _much_ more lightweight since its TLB invalidation is > > > always CPU-local and never broadcast. > > > > > > So, basically, unless you *must* sleep while the mapping is in place, > > > kmap_atomic() is preferred. > > > > But kmap_atomic() disables preemption, so the _ideal_ interface would map > > it only locally, then on preemption make it global. I don't even know > > if that _can_ be done. But this email makes it seem like kmap_atomic() > > has no downsides. > > And that is IIUC what Thomas was trying to solve. > > Also, Linus brought up that kmap_atomic() has quirks in nesting.[1] > > >From what I can see all of these discussions support the need to have > >something > between kmap() and kmap_atomic(). > > However, the reason behind converting call sites to kmap_thread() are > different > between Thomas' patch set and mine. Both require more kmap granularity. > However, they do so with different reasons and underlying implementations but > with the _same_ resulting semantics; a thread local mapping which is > preemptable.[2] Therefore they each focus on changing different call sites. > > While this patch set is huge I think it serves a valuable purpose to identify > a > large number of call sites which are candidates for this new semantic. Yes, I agree. My problem with this patch-set is that it ties it to some Intel feature that almost nobody cares about. Maybe we should care about it, but you didn't try very hard to make anyone care about it in the cover letter. For a future patch-set, I'd like to see you just introduce the new API. Then you can optimise the Intel implementation of it afterwards. Those patch-sets have entirely different reviewers. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
Hi all, would you please help to review my latest patch v17, thanks very much! Best Regards, Xin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] drm/virtio: Use UUID API for importing the UUID
There is import_uuid() function which imports u8 array to the uuid_t.
Use it instead of open coding variant.
This allows to hide the uuid_t internals.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 07945ca238e2..8944cc0bf8eb 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -1129,7 +1129,7 @@ static void virtio_gpu_cmd_resource_uuid_cb(struct
virtio_gpu_device *vgdev,
if (resp_type == VIRTIO_GPU_RESP_OK_RESOURCE_UUID &&
obj->uuid_state == UUID_INITIALIZING) {
- memcpy(>uuid.b, resp->uuid, sizeof(obj->uuid.b));
+ import_uuid(>uuid, resp->uuid);
obj->uuid_state = UUID_INITIALIZED;
} else {
obj->uuid_state = UUID_INITIALIZATION_FAILED;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] opp: Add devres wrapper for dev_pm_opp_set_prop_name
From: Yangtao Li
Add devres wrapper for dev_pm_opp_set_prop_name() to simplify driver
code.
Signed-off-by: Yangtao Li
Signed-off-by: Yangtao Li
---
drivers/opp/core.c | 39 +++
include/linux/pm_opp.h | 6 ++
2 files changed, 45 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index b38852dde578..3263fa8302c9 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1721,6 +1721,45 @@ void dev_pm_opp_put_prop_name(struct opp_table
*opp_table)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_put_prop_name);
+static void devm_pm_opp_put_prop_name(struct device *dev, void *res)
+{
+ dev_pm_opp_put_prop_name(*(struct opp_table **)res);
+}
+
+/**
+ * devm_pm_opp_set_prop_name() - Set prop-extn name
+ * @dev: Device for which the prop-name has to be set.
+ * @name: name to postfix to properties.
+ *
+ * This is required only for the V2 bindings, and it enables a platform to
+ * specify the extn to be used for certain property names. The properties to
+ * which the extension will apply are opp-microvolt and opp-microamp. OPP core
+ * should postfix the property name with - while looking for them.
+ *
+ * The opp_table structure will be freed after the device is destroyed.
+ */
+struct opp_table *devm_pm_opp_set_prop_name(struct device *dev,
+ const char *name)
+{
+ struct opp_table **ptr, *opp_table;
+
+ ptr = devres_alloc(devm_pm_opp_put_prop_name,
+ sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ opp_table = dev_pm_opp_set_prop_name(dev, name);
+ if (!IS_ERR(opp_table)) {
+ *ptr = opp_table;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return opp_table;
+}
+EXPORT_SYMBOL(devm_pm_opp_set_prop_name);
+
static int _allocate_set_opp_data(struct opp_table *opp_table)
{
struct dev_pm_set_opp_data *data;
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 901920e29c54..1708485200dd 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -143,6 +143,7 @@ void dev_pm_opp_put_supported_hw(struct opp_table
*opp_table);
struct opp_table *devm_pm_opp_set_supported_hw(struct device *dev, const u32
*versions, unsigned int count);
struct opp_table *dev_pm_opp_set_prop_name(struct device *dev, const char
*name);
void dev_pm_opp_put_prop_name(struct opp_table *opp_table);
+struct opp_table *devm_pm_opp_set_prop_name(struct device *dev, const char
*name);
struct opp_table *dev_pm_opp_set_regulators(struct device *dev, const char *
const names[], unsigned int count);
void dev_pm_opp_put_regulators(struct opp_table *opp_table);
struct opp_table *dev_pm_opp_set_clkname(struct device *dev, const char *
name);
@@ -321,6 +322,11 @@ static inline struct opp_table
*dev_pm_opp_set_prop_name(struct device *dev, con
static inline void dev_pm_opp_put_prop_name(struct opp_table *opp_table) {}
+static inline struct opp_table *devm_pm_opp_set_prop_name(struct device *dev,
const char *name)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
+
static inline struct opp_table *dev_pm_opp_set_regulators(struct device *dev,
const char * const names[], unsigned int count)
{
return ERR_PTR(-ENOTSUPP);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/msm: Convert to devm_pm_opp_set_supported_hw
From: Yangtao Li Use the devm_pm_opp_set_supported_hw() to avoid memory leaks in some cases. Signed-off-by: Yangtao Li Signed-off-by: Yangtao Li --- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c index 91726da82ed6..8d88f119a59f 100644 --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c @@ -1487,7 +1487,7 @@ static void check_speed_bin(struct device *dev) nvmem_cell_put(cell); } - dev_pm_opp_set_supported_hw(dev, , 1); + devm_pm_opp_set_supported_hw(dev, , 1); } struct msm_gpu *a5xx_gpu_init(struct drm_device *dev) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: remove no need return value
Functions (disable_all_writeback_pipes_for_stream &
dc_enable_stereo & dc_post_update_surfaces_to_stream)
always return true, there is no need to keep the return value.
This change is to make the code a bit more readable.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 17 +
drivers/gpu/drm/amd/display/dc/dc.h| 2 +-
drivers/gpu/drm/amd/display/dc/dc_stream.h | 2 +-
3 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 92eb1ca1634f..8dc598a632b5 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -761,7 +761,7 @@ static bool dc_construct(struct dc *dc,
return false;
}
-static bool disable_all_writeback_pipes_for_stream(
+static void disable_all_writeback_pipes_for_stream(
const struct dc *dc,
struct dc_stream_state *stream,
struct dc_state *context)
@@ -770,8 +770,6 @@ static bool disable_all_writeback_pipes_for_stream(
for (i = 0; i < stream->num_wb_info; i++)
stream->writeback_info[i].wb_enabled = false;
-
- return true;
}
void apply_ctx_interdependent_lock(struct dc *dc, struct dc_state *context,
struct dc_stream_state *stream, bool lock)
@@ -1213,13 +1211,12 @@ bool dc_validate_seamless_boot_timing(const struct dc
*dc,
return true;
}
-bool dc_enable_stereo(
+void dc_enable_stereo(
struct dc *dc,
struct dc_state *context,
struct dc_stream_state *streams[],
uint8_t stream_count)
{
- bool ret = true;
int i, j;
struct pipe_ctx *pipe;
@@ -1234,8 +1231,6 @@ bool dc_enable_stereo(
dc->hwss.setup_stereo(pipe, dc);
}
}
-
- return ret;
}
/*
@@ -1448,18 +1443,18 @@ static bool is_flip_pending_in_pipes(struct dc *dc,
struct dc_state *context)
return false;
}
-bool dc_post_update_surfaces_to_stream(struct dc *dc)
+void dc_post_update_surfaces_to_stream(struct dc *dc)
{
int i;
struct dc_state *context = dc->current_state;
if ((!dc->optimized_required) || dc->optimize_seamless_boot_streams > 0)
- return true;
+ return;
post_surface_trace(dc);
if (is_flip_pending_in_pipes(dc, context))
- return true;
+ return;
for (i = 0; i < dc->res_pool->pipe_count; i++)
if (context->res_ctx.pipe_ctx[i].stream == NULL ||
@@ -1472,8 +1467,6 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
dc->optimized_required = false;
dc->wm_optimized_required = false;
-
- return true;
}
struct dc_state *dc_create_state(struct dc *dc)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index f50ef4255020..f79a3c318757 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -962,7 +962,7 @@ struct dc_flip_addrs {
bool triplebuffer_flips;
};
-bool dc_post_update_surfaces_to_stream(
+void dc_post_update_surfaces_to_stream(
struct dc *dc);
#include "dc_stream.h"
diff --git a/drivers/gpu/drm/amd/display/dc/dc_stream.h
b/drivers/gpu/drm/amd/display/dc/dc_stream.h
index d9888f316da6..0047ab33f88e 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_stream.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_stream.h
@@ -391,7 +391,7 @@ enum dc_status dc_validate_stream(struct dc *dc, struct
dc_stream_state *stream)
* Enable stereo when commit_streams is not required,
* for example, frame alternate.
*/
-bool dc_enable_stereo(
+void dc_enable_stereo(
struct dc *dc,
struct dc_state *context,
struct dc_stream_state *streams[],
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote: > kmap_atomic() is always preferred over kmap()/kmap_thread(). > kmap_atomic() is _much_ more lightweight since its TLB invalidation is > always CPU-local and never broadcast. > > So, basically, unless you *must* sleep while the mapping is in place, > kmap_atomic() is preferred. But kmap_atomic() disables preemption, so the _ideal_ interface would map it only locally, then on preemption make it global. I don't even know if that _can_ be done. But this email makes it seem like kmap_atomic() has no downsides. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ingenic: Fix bad revert
Fix a badly reverted commit. The revert commit was cherry-picked from
drm-misc-next to drm-misc-next-fixes, and in the process some unrelated
code was added.
Fixes: a3fb64c00d44 "Revert "gpu/drm: ingenic: Add option to mmap GEM buffers
cached""
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 1be1235bd546..a3d1617d7c67 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -440,20 +440,6 @@ void ingenic_drm_plane_config(struct device *dev,
}
}
-static void ingenic_drm_update_palette(struct ingenic_drm *priv,
- const struct drm_color_lut *lut)
-{
- unsigned int i;
-
- for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
- u16 color = drm_color_lut_extract(lut[i].red, 5) << 11
- | drm_color_lut_extract(lut[i].green, 6) << 5
- | drm_color_lut_extract(lut[i].blue, 5);
-
- priv->dma_hwdescs->palette[i] = color;
- }
-}
-
static void ingenic_drm_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *oldstate)
{
@@ -464,8 +450,6 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
dma_addr_t addr;
if (state && state->fb) {
- crtc_state = state->crtc->state;
-
addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
width = state->src_w >> 16;
height = state->src_h >> 16;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm/mediatek: fix unused parameter warning
Functions mtk_drm_crtc_atomic_flush & mtk_drm_crtc_atomic_enable
& mtk_drm_crtc_atomic_disable don`t use the second parameter.
So we may get warning like : warning: unused parameter '***'
[-Wunused-parameter].
This change is to fix the compile warning with -Wunused-parameter.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 4d29568be3f5..6e55ec0e80bb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -542,7 +542,7 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
}
static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_crtc_state
__attribute__((unused)) *old_state)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
@@ -575,7 +575,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
}
static void mtk_drm_crtc_atomic_begin(struct drm_crtc *crtc,
- struct drm_crtc_state *old_crtc_state)
+ struct drm_crtc_state
__attribute__((unused)) *old_crtc_state)
{
struct mtk_crtc_state *state = to_mtk_crtc_state(crtc->state);
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
@@ -592,7 +592,7 @@ static void mtk_drm_crtc_atomic_begin(struct drm_crtc *crtc,
}
static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
- struct drm_crtc_state *old_crtc_state)
+ struct drm_crtc_state
__attribute__((unused)) *old_crtc_state)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
int i;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: dsi: Use dev_ based logging
Hi Sam,
thanks for the review. I'll send a new patch with the revert of function
dsi_color_from_mipi.
Best regards
Yannick
On 9/25/20 4:51 PM, Sam Ravnborg wrote:
> Hi Yannick.
>
> On Fri, Sep 25, 2020 at 12:22:33PM +0200, Yannick Fertre wrote:
>> Standardize on the dev_ based logging and drop the include of drm_print.h.
> The patchs filas to drop the include mentioned here.
>
>> Remove useless dsi_color_from_mipi function.
> IMO the dsi_color_from_mipi() was nice, and inlining the helper
> is no gain for readability.
>
> Sam
>
>>
>> Signed-off-by: Yannick Fertre
>> ---
>> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 87 ++-
>> 1 file changed, 45 insertions(+), 42 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> index 164f79ef6269..93fa8bfd3127 100644
>> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> @@ -76,6 +76,7 @@ enum dsi_color {
>>
>> struct dw_mipi_dsi_stm {
>> void __iomem *base;
>> +struct device *dev;
>> struct clk *pllref_clk;
>> struct dw_mipi_dsi *dsi;
>> u32 hw_version;
>> @@ -110,23 +111,6 @@ static inline void dsi_update_bits(struct
>> dw_mipi_dsi_stm *dsi, u32 reg,
>> dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val);
>> }
>>
>> -static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt)
>> -{
>> -switch (fmt) {
>> -case MIPI_DSI_FMT_RGB888:
>> -return DSI_RGB888;
>> -case MIPI_DSI_FMT_RGB666:
>> -return DSI_RGB666_CONF2;
>> -case MIPI_DSI_FMT_RGB666_PACKED:
>> -return DSI_RGB666_CONF1;
>> -case MIPI_DSI_FMT_RGB565:
>> -return DSI_RGB565_CONF1;
>> -default:
>> -DRM_DEBUG_DRIVER("MIPI color invalid, so we use rgb888\n");
>> -}
>> -return DSI_RGB888;
>> -}
>> -
>> static int dsi_pll_get_clkout_khz(int clkin_khz, int idf, int ndiv, int
>> odf)
>> {
>> int divisor = idf * odf;
>> @@ -205,14 +189,14 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
>> ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
>> SLEEP_US, TIMEOUT_US);
>> if (ret)
>> -DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
>> +dev_dbg(dsi->dev, "!TIMEOUT! waiting REGU, let's continue\n");
>>
>> /* Enable the DSI PLL & wait for its lock */
>> dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
>> ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
>> SLEEP_US, TIMEOUT_US);
>> if (ret)
>> -DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
>> +dev_dbg(dsi->dev, "!TIMEOUT! waiting PLL, let's continue\n");
>>
>> return 0;
>> }
>> @@ -221,7 +205,7 @@ static void dw_mipi_dsi_phy_power_on(void *priv_data)
>> {
>> struct dw_mipi_dsi_stm *dsi = priv_data;
>>
>> -DRM_DEBUG_DRIVER("\n");
>> +dev_dbg(dsi->dev, "\n");
>>
>> /* Enable the DSI wrapper */
>> dsi_set(dsi, DSI_WCR, WCR_DSIEN);
>> @@ -231,7 +215,7 @@ static void dw_mipi_dsi_phy_power_off(void *priv_data)
>> {
>> struct dw_mipi_dsi_stm *dsi = priv_data;
>>
>> -DRM_DEBUG_DRIVER("\n");
>> +dev_dbg(dsi->dev, "\n");
>>
>> /* Disable the DSI wrapper */
>> dsi_clear(dsi, DSI_WCR, WCR_DSIEN);
>> @@ -244,6 +228,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
>> drm_display_mode *mode,
>> {
>> struct dw_mipi_dsi_stm *dsi = priv_data;
>> unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
>> +enum mipi_dsi_pixel_format fmt;
>> int ret, bpp;
>> u32 val;
>>
>> @@ -267,11 +252,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const
>> struct drm_display_mode *mode,
>>
>> if (pll_out_khz > dsi->lane_max_kbps) {
>> pll_out_khz = dsi->lane_max_kbps;
>> -DRM_WARN("Warning max phy mbps is used\n");
>> +dev_warn(dsi->dev, "Warning max phy mbps is used\n");
>> }
>> if (pll_out_khz < dsi->lane_min_kbps) {
>> pll_out_khz = dsi->lane_min_kbps;
>> -DRM_WARN("Warning min phy mbps is used\n");
>> +dev_warn(dsi->dev, "Warning min phy mbps is used\n");
>> }
>>
>> /* Compute best pll parameters */
>> @@ -281,7 +266,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
>> drm_display_mode *mode,
>> ret = dsi_pll_get_params(dsi, pll_in_khz, pll_out_khz,
>> , , );
>> if (ret)
>> -DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
>> +dev_warn(dsi->dev, "Warning dsi_pll_get_params(): bad
>> params\n");
>>
>> /* Get the adjusted pll out value */
>> pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
>> @@ -297,14 +282,31 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const
>> struct drm_display_mode
Re: [PATCH 3/3] drm/vkms: fbdev emulation support
On Mon, 12 Oct 2020 16:23:35 +0200 Daniel Vetter wrote: > On Mon, Oct 12, 2020 at 02:40:58PM +0200, Neil Armstrong wrote: > > Hi, > > ... > > It's weird because it the kernel is misconfigured and no console is > > specified on the cmdline > > this console could become the main console... > > > > It's a great feature, but couldn't this be a module parameter ? > > If you have vkms enabled in a distro, you're doing it wrong. That's really not a great position to take. I would prefer that if a random contributor writes a Weston patch and runs 'meson test', it will use VKMS to run Weston's DRM-backend tests on his machine automatically, maybe save for some seat and device node access permissions bits which distributions could be delivering as well. Just put the VKMS device node into a non-default seat, and Xorg etc. will happily ignore it. For the fbdev device node, I don't know. Maybe a module parameter really is a good choice there, defaulting to off. I have no interest in testing anything against fbdev, but other people might disagree of course. Why? Gitlab CI is still not running tests for every commit, just per MR, and it might even be infeasible too. I am also hoping for a future where I don't have to build my own kernel just to be able to run Weston DRM tests with VKMS. That means I want to be able to run my machine with VKMS loaded and active at all times, without affecting the normal desktop. I already have such a setup with an extra AMD card, but you can't run most KMS tests against real hardware drivers. Thanks, pq pgpJCZtJtXcEb.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
