[PATCH V3] dt-bindings: gpu: Convert v3d to json-schema
This converts the v3d bindings to yaml format.
Signed-off-by: Stefan Wahren
---
Changes in V3:
- drop redundant maxItems in case we already have items defined
- fix order of reg-names enum
- tag required items in description
- add reg-names to required properties
- drop clock-names
.../devicetree/bindings/gpu/brcm,bcm-v3d.txt | 33 --
.../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 72 ++
2 files changed, 72 insertions(+), 33 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
deleted file mode 100644
index b2df82b..000
--- a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Broadcom V3D GPU
-
-Only the Broadcom V3D 3.x and newer GPUs are covered by this binding.
-For V3D 2.x, see brcm,bcm-vc4.txt.
-
-Required properties:
-- compatible: Should be "brcm,7268-v3d" or "brcm,7278-v3d"
-- reg: Physical base addresses and lengths of the register areas
-- reg-names: Names for the register areas. The "hub" and "core0"
- register areas are always required. The "gca" register area
- is required if the GCA cache controller is present. The
- "bridge" register area is required if an external reset
- controller is not present.
-- interrupts: The interrupt numbers. The first interrupt is for the hub,
- while the following interrupts are separate interrupt lines
- for the cores (if they don't share the hub's interrupt).
- See bindings/interrupt-controller/interrupts.txt
-
-Optional properties:
-- clocks: The core clock the unit runs on
-- resets: The reset line for v3d, if not using a mapping of the bridge
- See bindings/reset/reset.txt
-
-v3d {
- compatible = "brcm,7268-v3d";
- reg = <0xf1204000 0x100>,
- <0xf120 0x4000>,
- <0xf1208000 0x4000>,
- <0xf1204100 0x100>;
- reg-names = "bridge", "hub", "core0", "gca";
- interrupts = <0 78 4>,
-<0 77 4>;
-};
diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
new file mode 100644
index 000..3b543d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/brcm,bcm-v3d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom V3D GPU Bindings
+
+maintainers:
+ - Eric Anholt
+ - Nicolas Saenz Julienne
+
+properties:
+ $nodename:
+pattern: '^gpu@[a-f0-9]+$'
+
+ compatible:
+enum:
+ - brcm,7268-v3d
+ - brcm,7278-v3d
+
+ reg:
+items:
+ - description: hub register (required)
+ - description: core0 register (required)
+ - description: GCA cache controller register (if GCA controller present)
+ - description: bridge register (if no external reset controller)
+minItems: 2
+
+ reg-names:
+items:
+ enum: [ hub, core0, bridge, gca ]
+minItems: 2
+maxItems: 4
+
+ interrupts:
+items:
+ - description: hub interrupt (required)
+ - description: core interrupts (if it doesn't share the hub's interrupt)
+minItems: 1
+
+ clocks:
+maxItems: 1
+
+ resets:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+gpu@f120 {
+ compatible = "brcm,7268-v3d";
+ reg = <0xf1204000 0x100>,
+<0xf120 0x4000>,
+<0xf1208000 0x4000>,
+<0xf1204100 0x100>;
+ reg-names = "bridge", "hub", "core0", "gca";
+ interrupts = <0 78 4>,
+ <0 77 4>;
+};
+
+...
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: stop re-init the TTM page pool
On Tue, Jan 05, 2021 at 07:23:08PM +0100, Christian König wrote:
> Drivers are not supposed to init the page pool directly any more.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index d4328ff57757..35b715f82ed8 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -729,9 +729,6 @@ int radeon_ttm_init(struct radeon_device *rdev)
> }
> rdev->mman.initialized = true;
>
> - ttm_pool_init(&rdev->mman.bdev.pool, rdev->dev, rdev->need_swiotlb,
> - dma_addressing_limited(&rdev->pdev->dev));
> -
> r = radeon_ttm_init_vram(rdev);
> if (r) {
> DRM_ERROR("Failed initializing VRAM heap.\n");
> --
Was finally able to test those during workstation hw maintenance so I
was able to install a new kernel and reboot.
Reported-by: Borislav Petkov
Tested-by: Borislav Petkov
Thanks for the fixes!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC] drm/vc4: hdmi: Avoid ASoC error messages on startup
Hi Maxime, Am 29.12.20 um 16:36 schrieb Stefan Wahren: > During startup of Raspberry Pi 4 there seems to be a race between > VC4 probing and Pulseaudio trying to open its PCM device: > > ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19 > > Avoid these errors by returning EPROBE_DEFER in this situation. > > Signed-off-by: Stefan Wahren should i resend without RFC? Best regards Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Only enable A6xx LLCC code on A6xx
> Konrad, can you please test this below change without your change? This brings no difference, a BUG still happens. We're still calling to_a6xx_gpu on ANY device that's probed! Too bad it won't turn my A330 into an A640.. Also, relying on disabling LLCC in the config is out of question as it makes the arm32 kernel not compile with DRM/MSM and it just removes the functionality on devices with a6xx.. (unless somebody removes the dependency on it, which in my opinion is even worse and will cause more problems for developers!). The bigger question is how and why did that piece of code ever make it to adreno_gpu.c and not a6xx_gpu.c? To solve it in a cleaner way I propose to move it to an a6xx-specific file, or if it's going to be used with next-gen GPUs, perhaps manage calling of this code via an adreno quirk/feature in adreno_device.c. Now that I think about it, A5xx GPMU en/disable could probably managed like that, instead of using tons of if-statements for each GPU model that has it.. While we're at it, do ALL (and I truly do mean ALL, including the low-end ones, this will be important later on) A6xx GPUs make use of that feature? Konrad ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 -next] video: fbdev: pxa3xx_gcu: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/video/fbdev/pxa3xx-gcu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c index 4279e13a3b58..1d26be9d1f2d 100644 --- a/drivers/video/fbdev/pxa3xx-gcu.c +++ b/drivers/video/fbdev/pxa3xx-gcu.c @@ -594,8 +594,8 @@ static int pxa3xx_gcu_probe(struct platform_device *pdev) * container_of(). This isn't really necessary as we have a fixed minor * number anyway, but this is to avoid statics. */ - priv->misc_dev.minor= PXA3XX_GCU_MINOR, - priv->misc_dev.name = DRV_NAME, + priv->misc_dev.minor= PXA3XX_GCU_MINOR; + priv->misc_dev.name = DRV_NAME; priv->misc_dev.fops = &pxa3xx_gcu_miscdev_fops; /* handle IO resources */ -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/hisilicon: Delete the empty function mode_valid
Based on the drm_connector_mode_valid, if the hibmc implementation
of mode_valid only returns MODE_OK, then we can not implement the
mode_valid function.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index c76f996..c74a35b 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -43,12 +43,6 @@ static int hibmc_connector_get_modes(struct drm_connector
*connector)
return count;
}
-static enum drm_mode_status hibmc_connector_mode_valid(struct drm_connector
*connector,
- struct drm_display_mode
*mode)
-{
- return MODE_OK;
-}
-
static void hibmc_connector_destroy(struct drm_connector *connector)
{
struct hibmc_connector *hibmc_connector = to_hibmc_connector(connector);
@@ -60,7 +54,6 @@ static void hibmc_connector_destroy(struct drm_connector
*connector)
static const struct drm_connector_helper_funcs
hibmc_connector_helper_funcs = {
.get_modes = hibmc_connector_get_modes,
- .mode_valid = hibmc_connector_mode_valid,
};
static const struct drm_connector_funcs hibmc_connector_funcs = {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Only enable A6xx LLCC code on A6xx
On 2021-01-08 19:09, Konrad Dybcio wrote: Konrad, can you please test this below change without your change? This brings no difference, a BUG still happens. We're still calling to_a6xx_gpu on ANY device that's probed! Too bad it won't turn my A330 into an A640.. Also, relying on disabling LLCC in the config is out of question as it makes the arm32 kernel not compile with DRM/MSM and it just removes the functionality on devices with a6xx.. (unless somebody removes the dependency on it, which in my opinion is even worse and will cause more problems for developers!). Disabling LLCC is not the suggestion, I was under the impression that was the cause here for the smmu bug. Anyways, the check for llc slice in case llcc is disabled is not correct as well. I will send a patch for that as well. The bigger question is how and why did that piece of code ever make it to adreno_gpu.c and not a6xx_gpu.c? My mistake, I will move it. To solve it in a cleaner way I propose to move it to an a6xx-specific file, or if it's going to be used with next-gen GPUs, perhaps manage calling of this code via an adreno quirk/feature in adreno_device.c. Now that I think about it, A5xx GPMU en/disable could probably managed like that, instead of using tons of if-statements for each GPU model that has it.. While we're at it, do ALL (and I truly do mean ALL, including the low-end ones, this will be important later on) A6xx GPUs make use of that feature? I do not have a list of all A6XX GPUs with me currently, but from what I know, A618, A630, A640, A650 has the support. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/vc4: Streamline the vmap and mmap code
Hi! Thanks for the series On Fri, Jan 08, 2021 at 03:08:05PM +0100, Thomas Zimmermann wrote: > Daniel recently pointed out that vc4 has test in it's vmap code that > cannot really fail. [1] I took the opportunity to cleanup vc'4 vmap > and mmap implementations. > > The patches got smoke-tested by running fbdev and Xorg on an RPi3. > > [1] > https://lore.kernel.org/dri-devel/20201211094000.GK401619@phenom.ffwll.local/ Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling
Hi, Thanks for those patches On Thu, Jan 07, 2021 at 03:30:32AM +0100, Giulio Benetti wrote: > From: Giulio Benetti > > It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is > dedicated to invert DCLK polarity and this makes thing really easier than > before. So let's handle DCLK polarity by adding > SUN4I_TCON0_IO_POL_DCLK_POSITIVE as bit 26 and activating according to > bus_flags the same way is done for all the other signals. > > Cc: Maxime Ripard Suggested-by would be nice here :) > Signed-off-by: Giulio Benetti > --- > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +--- > drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + > 2 files changed, 2 insertions(+), 19 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c > b/drivers/gpu/drm/sun4i/sun4i_tcon.c > index 52598bb0fb0b..30171ccd87e5 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c > @@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon > *tcon, > if (info->bus_flags & DRM_BUS_FLAG_DE_LOW) > val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE; > > - /* > - * On A20 and similar SoCs, the only way to achieve Positive Edge > - * (Rising Edge), is setting dclk clock phase to 2/3(240°). > - * By default TCON works in Negative Edge(Falling Edge), > - * this is why phase is set to 0 in that case. > - * Unfortunately there's no way to logically invert dclk through > - * IO_POL register. > - * The only acceptable way to work, triple checked with scope, > - * is using clock phase set to 0° for Negative Edge and set to 240° > - * for Positive Edge. > - * On A33 and similar SoCs there would be a 90° phase option, > - * but it divides also dclk by 2. > - * Following code is a way to avoid quirks all around TCON > - * and DOTCLOCK drivers. > - */ > if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE) > - clk_set_phase(tcon->dclk, 0); > - > - if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE) > - clk_set_phase(tcon->dclk, 240); > + val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE; I'm not really sure why we need the first patch of this series here? That patch only seem to undo what you did in patch 1 Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling
Hi, Quote " I'm not really sure why we need the first patch of this series here? That patch only seem to undo what you did in patch 1 " And another question (probably could be a stupid one): in "/[PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling/" I see you deleted: - clk_set_phase(tcon->dclk, 0); Is safe to assume that phase register will be always set to 0? Or maybe will be safer manually set it to 0 in every condition to avoid surprises (dirt values due to previous condition)? Marjan Il 08/01/2021 10:23, Maxime Ripard ha scritto: Hi, Thanks for those patches On Thu, Jan 07, 2021 at 03:30:32AM +0100, Giulio Benetti wrote: From: Giulio Benetti It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to invert DCLK polarity and this makes thing really easier than before. So let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_POSITIVE as bit 26 and activating according to bus_flags the same way is done for all the other signals. Cc: Maxime Ripard Suggested-by would be nice here :) Signed-off-by: Giulio Benetti --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +--- drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + 2 files changed, 2 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 52598bb0fb0b..30171ccd87e5 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, if (info->bus_flags & DRM_BUS_FLAG_DE_LOW) val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE; - /* -* On A20 and similar SoCs, the only way to achieve Positive Edge -* (Rising Edge), is setting dclk clock phase to 2/3(240°). -* By default TCON works in Negative Edge(Falling Edge), -* this is why phase is set to 0 in that case. -* Unfortunately there's no way to logically invert dclk through -* IO_POL register. -* The only acceptable way to work, triple checked with scope, -* is using clock phase set to 0° for Negative Edge and set to 240° -* for Positive Edge. -* On A33 and similar SoCs there would be a 90° phase option, -* but it divides also dclk by 2. -* Following code is a way to avoid quirks all around TCON -* and DOTCLOCK drivers. -*/ if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE) - clk_set_phase(tcon->dclk, 0); - - if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE) - clk_set_phase(tcon->dclk, 240); + val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE; I'm not really sure why we need the first patch of this series here? That patch only seem to undo what you did in patch 1 Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling
Hi Marjan, On 1/8/21 10:32 AM, Marjan Pascolo wrote: Hi, please don't top post, answer in-line as we do, and please use plain-test instead of HTML. These are the standards in Mailing Lists(ML). Quote " I'm not really sure why we need the first patch of this series here? That patch only seem to undo what you did in patch 1 " Already answered to Maxime And another question (probably could be a stupid one): in "/[PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling/" I see you deleted: - clk_set_phase(tcon->dclk, 0); Is safe to assume that phase register will be always set to 0? We always assumed it is set to 0 by default. Or maybe will be safer manually set it to 0 in every condition to avoid surprises (dirt values due to previous condition)? That would be a good idea, so something like this: ''' int phase = 0; if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE) phase = 240; clk_set_phase(tcon->dclk, phase); ''' because now DRM_BUS_FLAG_PIXDATA_SAMPLE_ and DRM_BUS_FLAG_PIXDATA_DRIVE_ are exclusive, while before not. But then if bit 26 solution works everything gets easier. Best Regards Giulio Marjan Il 08/01/2021 10:23, Maxime Ripard ha scritto: Hi, Thanks for those patches On Thu, Jan 07, 2021 at 03:30:32AM +0100, Giulio Benetti wrote: From: Giulio Benetti It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to invert DCLK polarity and this makes thing really easier than before. So let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_POSITIVE as bit 26 and activating according to bus_flags the same way is done for all the other signals. Cc: Maxime Ripard Suggested-by would be nice here :) Signed-off-by: Giulio Benetti --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +--- drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + 2 files changed, 2 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 52598bb0fb0b..30171ccd87e5 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, if (info->bus_flags & DRM_BUS_FLAG_DE_LOW) val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE; - /* -* On A20 and similar SoCs, the only way to achieve Positive Edge -* (Rising Edge), is setting dclk clock phase to 2/3(240°). -* By default TCON works in Negative Edge(Falling Edge), -* this is why phase is set to 0 in that case. -* Unfortunately there's no way to logically invert dclk through -* IO_POL register. -* The only acceptable way to work, triple checked with scope, -* is using clock phase set to 0° for Negative Edge and set to 240° -* for Positive Edge. -* On A33 and similar SoCs there would be a 90° phase option, -* but it divides also dclk by 2. -* Following code is a way to avoid quirks all around TCON -* and DOTCLOCK drivers. -*/ if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE) - clk_set_phase(tcon->dclk, 0); - - if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE) - clk_set_phase(tcon->dclk, 240); + val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE; I'm not really sure why we need the first patch of this series here? That patch only seem to undo what you did in patch 1 Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
On 19/12/20, Oliver Graute wrote: > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD > to panel-simple. > > The panel spec from Variscite can be found at: > https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf some clue what bus_format and bus_flags I have to use? [ 42.505156] panel-simple panel-lcd: Specify missing bus_flags [ 42.511090] panel-simple panel-lcd: Specify missing bus_format [ 42.615131] mxsfb 21c8000.lcdif: Cannot connect bridge: -517 Best Regards, Oliver ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/sun4i: tcon: improve DCLK polarity handling
Hi, On 1/8/21 10:23 AM, Maxime Ripard wrote: Hi, Thanks for those patches On Thu, Jan 07, 2021 at 03:30:32AM +0100, Giulio Benetti wrote: From: Giulio Benetti It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to invert DCLK polarity and this makes thing really easier than before. So let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_POSITIVE as bit 26 and activating according to bus_flags the same way is done for all the other signals. Cc: Maxime Ripard Suggested-by would be nice here :) Ok, didn't know about this tag Signed-off-by: Giulio Benetti --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +--- drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + 2 files changed, 2 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 52598bb0fb0b..30171ccd87e5 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -569,26 +569,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, if (info->bus_flags & DRM_BUS_FLAG_DE_LOW) val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE; - /* -* On A20 and similar SoCs, the only way to achieve Positive Edge -* (Rising Edge), is setting dclk clock phase to 2/3(240°). -* By default TCON works in Negative Edge(Falling Edge), -* this is why phase is set to 0 in that case. -* Unfortunately there's no way to logically invert dclk through -* IO_POL register. -* The only acceptable way to work, triple checked with scope, -* is using clock phase set to 0° for Negative Edge and set to 240° -* for Positive Edge. -* On A33 and similar SoCs there would be a 90° phase option, -* but it divides also dclk by 2. -* Following code is a way to avoid quirks all around TCON -* and DOTCLOCK drivers. -*/ if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE) - clk_set_phase(tcon->dclk, 0); - - if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE) - clk_set_phase(tcon->dclk, 240); + val |= SUN4I_TCON0_IO_POL_DCLK_POSITIVE; I'm not really sure why we need the first patch of this series here? The idea was to have 2 for testing, 1st one is already applicable, while the other must be tested, but I can send only one with no problem. That patch only seem to undo what you did in patch 1 No, it doesn't, the 2nd one change the way it achieve the same thing, because the 1st swap DCLK phase, while the 2nd uses the IO_POL bit to set IO polarity according to bus_flags. Best Regards -- Giulio Benetti Benetti Engineering sas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 39/80] drm/panel: Move OMAP's DSI command mode panel driver
Hi,
On Fri, Jan 08, 2021 at 01:23:54PM -0800, Dixit, Ashutosh wrote:
> On Tue, 24 Nov 2020 04:44:57 -0800, Tomi Valkeinen wrote:
> >
> > From: Sebastian Reichel
> >
> > The panel driver is no longer using any OMAP specific APIs, so
> > let's move it into the generic panel directory.
> >
> > Signed-off-by: Sebastian Reichel
> > Signed-off-by: Tomi Valkeinen
> > Cc: Thierry Reding
> > Cc: Sam Ravnborg
> > Acked-by: Sam Ravnborg
> > Acked-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/omapdrm/Kconfig| 1 -
> > drivers/gpu/drm/omapdrm/Makefile | 1 -
> > drivers/gpu/drm/omapdrm/displays/Kconfig | 10 --
> > drivers/gpu/drm/omapdrm/displays/Makefile | 2 --
> > drivers/gpu/drm/panel/Kconfig | 9 +
> > drivers/gpu/drm/panel/Makefile | 1 +
> > .../gpu/drm/{omapdrm/displays => panel}/panel-dsi-cm.c | 0
>
> Not sure if it's a result of this commit but on drm-tip we see:
>
> $ make allmodconfig
> $ make modules_check
> DESCEND objtool
> CALLscripts/atomic/check-atomics.sh
> CALLscripts/checksyscalls.sh
> CHK include/generated/compile.h
> error: the following would cause module name conflict:
> drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> drivers/gpu/drm/panel/panel-dsi-cm.ko
> make: *** [Makefile:1400: modules_check] Error 1
It is a result of this commit and it has already been reported by
Stephen Rothwell. The thread also contains a patch to fixup the
problem:
https://lore.kernel.org/linux-next/20210108195839.ga1429...@ravnborg.org/T/#m0eee5e806cc93cf9982620b7b8b9f77df2c37498
Sorry for the inconvenience,
-- Sebastian
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive
Standard DRM panel driver for DSI command mode panel used by omapfb2 is also
available now. Just like the other panels its module name clashes with the
module from drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated
omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver
is disabled, and the DRM panel drivers are useless in that case, make the
omapfb2 panel depend on the standard DRM panels being disabled to fix
the name clash.
Fixes: cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
Reported-by: Stephen Rothwell
Signed-off-by: Sebastian Reichel
---
Laurent introduced and fixed the same issue for the other panels and
this simply replicates the same solution for DSI command mode panel.
---
drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
index 744416dc530e..384d74a126dc 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
+++ b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
@@ -43,6 +43,7 @@ config FB_OMAP2_PANEL_DPI
config FB_OMAP2_PANEL_DSI_CM
tristate "Generic DSI Command Mode Panel"
depends on BACKLIGHT_CLASS_DEVICE
+ depends on DRM_PANEL_DSI_CM = n
help
Driver for generic DSI command mode panels.
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Only enable A6xx LLCC code on A6xx
Hi Rob, Konrad,
On 2021-01-07 22:56, Rob Clark wrote:
> On Wed, Jan 6, 2021 at 8:50 PM Sai Prakash Ranjan
> wrote:
>>
>> On 2021-01-05 01:00, Konrad Dybcio wrote:
>> > Using this code on A5xx (and probably older too) causes a
>> > smmu bug.
>> >
>> > Fixes: 474dadb8b0d5 ("drm/msm/a6xx: Add support for using system
>> > cache(LLC)")
>> > Signed-off-by: Konrad Dybcio
>> > Tested-by: AngeloGioacchino Del Regno
>> >
>> > ---
>>
>> Reviewed-by: Sai Prakash Ranjan
>>
>> > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 21 -
>> > drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 +
>> > 2 files changed, 17 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>> > index 6cf9975e951e..f09175698827 100644
>> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>> > @@ -191,8 +191,6 @@ adreno_iommu_create_address_space(struct msm_gpu
>> > *gpu,
>> > struct platform_device *pdev)
>> > {
>> > struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
>> > - struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
>> > - struct io_pgtable_domain_attr pgtbl_cfg;
>> > struct iommu_domain *iommu;
>> > struct msm_mmu *mmu;
> > struct msm_gem_address_space *aspace;
>> > @@ -202,13 +200,18 @@ adreno_iommu_create_address_space(struct msm_gpu
>> > *gpu,
>> > if (!iommu)
>> > return NULL;
>> >
>> > - /*
>> > - * This allows GPU to set the bus attributes required to use system
>> > - * cache on behalf of the iommu page table walker.
>> > - */
>> > - if (!IS_ERR(a6xx_gpu->htw_llc_slice)) {
>> > - pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_ARM_OUTER_WBWA;
>> > - iommu_domain_set_attr(iommu, DOMAIN_ATTR_IO_PGTABLE_CFG,
>> > &pgtbl_cfg);
>> > +
>> > + if (adreno_is_a6xx(adreno_gpu)) {
>> > + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
>> > + struct io_pgtable_domain_attr pgtbl_cfg;
>> > + /*
>> > + * This allows GPU to set the bus attributes required to use
>> > system
>> > + * cache on behalf of the iommu page table walker.
>> > + */
>> > + if (!IS_ERR(a6xx_gpu->htw_llc_slice)) {
>> > + pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_ARM_OUTER_WBWA;
>> > + iommu_domain_set_attr(iommu,
>> > DOMAIN_ATTR_IO_PGTABLE_CFG,
>> > &pgtbl_cfg);
>> > + }
>
> I'm applying for -fixes as this is an obvious problem.. But kinda
> thinking that we should try to move it into an a6xx specific
> create_address_space() (or wrapper for the generic fxn)
>
> Sai/Jordan, could I talk one of you into trying to clean this up
> better for next cycle?
>
Looking more closely(sorry I should have before), the quirk setting
is already guarded by htw_llc_slice check but what is happening here is
that check is not proper when LLCC is disabled i.e., CONFIG_QCOM_LLCC=n.
When LLCC is disabled, htw_llc_slice is set to NULL and the !IS_ERR
check passes because it doesn't take care of NULL and quirk is
set causing bugs. So the proper fix would be to use IS_ERR_OR_NULL for
the check.
Konrad, can you please test this below change without your change?
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 130661898546..3b798e883f82 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1117,7 +1117,7 @@ static void a6xx_llc_slices_init(struct platform_device
*pdev,
a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
- if (IS_ERR(a6xx_gpu->llc_slice) && IS_ERR(a6xx_gpu->htw_llc_slice))
+ if (IS_ERR_OR_NULL(a6xx_gpu->llc_slice) &&
IS_ERR_OR_NULL(a6xx_gpu->htw_llc_slice))
a6xx_gpu->llc_mmio = ERR_PTR(-EINVAL);
}
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 6cf9975e951e..dbd5cacddb9c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -206,7 +206,7 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
* This allows GPU to set the bus attributes required to use system
* cache on behalf of the iommu page table walker.
*/
- if (!IS_ERR(a6xx_gpu->htw_llc_slice)) {
+ if (!IS_ERR_OR_NULL(a6xx_gpu->htw_llc_slice)) {
pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_ARM_OUTER_WBWA;
iommu_domain_set_attr(iommu, DOMAIN_ATTR_IO_PGTABLE_CFG,
&pgtbl_cfg);
}
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dr
Re: [PATCH] drm/msm: Fix MSM_INFO_GET_IOVA with carveout
On 1/8/21 12:36 AM, Rob Clark wrote:
> On Thu, Jan 7, 2021 at 9:20 AM Rob Clark wrote:
>>
>> On Sat, Jan 2, 2021 at 12:26 PM Iskren Chernev
>> wrote:
>>>
>>> The msm_gem_get_iova should be guarded with gpu != NULL and not aspace
>>> != NULL, because aspace is NULL when using vram carveout.
>>>
>>> Fixes: 933415e24bd0d ("drm/msm: Add support for private address space
>>> instances")
>>>
>>> Signed-off-by: Iskren Chernev
>>> ---
>>> drivers/gpu/drm/msm/msm_drv.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
>>> index c5e61cb3356df..c1953fb079133 100644
>>> --- a/drivers/gpu/drm/msm/msm_drv.c
>>> +++ b/drivers/gpu/drm/msm/msm_drv.c
>>> @@ -775,9 +775,10 @@ static int msm_ioctl_gem_info_iova(struct drm_device
>>> *dev,
>>> struct drm_file *file, struct drm_gem_object *obj,
>>> uint64_t *iova)
>>> {
>>> + struct msm_drm_private *priv = dev->dev_private;
>>> struct msm_file_private *ctx = file->driver_priv;
>>>
>>> - if (!ctx->aspace)
>>> + if (!priv->gpu)
>>> return -EINVAL;
>>
>> Does this actually work? It seems like you would hit a null ptr deref
>> in msm_gem_init_vma().. and in general I think a lot of code paths
>> would be surprised by a null address space, so this seems like a risky
>> idea.
>
> oh, actually, I suppose it is ok, since in the vram carveout case we
> create the vma up front when the gem obj is created..
>
> (still, it does seem a bit fragile.. and easy for folks testing on
> devices not using vram carvout to break.. hmm..)
In _msm_gem_new add_vma is called with NULL, so consequently lookup_vma
finds it when aspace is NULL.
Also, this is how the code was before the "breaking" change, so it should
not be worse.
I'll be happy to work on refactoring this a bit, but some some
documentation about the different gpu/mdp pieces and how they fit together
won't hurt.
Regards,
Iskren
> BR,
> -R
>
>> Maybe instead we should be creating an address space for the vram carveout?
>>
>> BR,
>> -R
>>
>>
>>> /*
>>> --
>>> 2.29.2
>>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 1/2] dma-fence: allow signaling drivers to set fence timestamp
On 2021-01-08 11:55, John Stultz wrote: On Thu, Jan 7, 2021 at 12:53 AM Veera Sundaram Sankaran wrote: Some drivers have hardware capability to get the precise timestamp of certain events based on which the fences are triggered. This allows it to set accurate timestamp factoring out any software and IRQ latencies. Add a timestamp variant of fence signal function, dma_fence_signal_timestamp to allow drivers to update the precise timestamp for fences. So, on quick review, this seems mostly sane. Though, it might be good to add some more detail about how the hardware timestamping fits into the kernel's CLOCK_MONOTONIC time domain. I just want to make sure this interface isn't abused to jam raw hardware-domain timestamps into the fence->timestamp, causing the meaning or time-domain of the fence->timestamp to be unclear or inconsistent. It may be useful to add an additional patch to the documentation around the dma_fence structure to make the timestamp field semantics more explicit and avoid confusion? Thanks for the comments. Sure, let me add more information in the commit-text about the HW timestamp conversion to kernel time-domain. Will explicitly mention the timestamp domain expected as part of the new dma_fence_signal_timestamp api documentation, since that would be the only place the timestamp would be set externally from drivers. On top of it, do suggest if still documentation on dma_fence struct would be required. Thanks, Veera thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/modes: add non-OF stub for of_get_drm_display_mode
On 1/8/21 2:13 AM, Philipp Zabel wrote:
> If CONFIG_OF is disabled, of_get_drm_display_mode is not compiled in,
> and drivers using it fail to build:
>
> ld: drivers/gpu/drm/imx/parallel-display.o: in function
> `imx_pd_connector_get_modes':
> parallel-display.c:(.text+0x8d): undefined reference to
> `of_get_drm_display_mode'
>
> Add an inline stub so they can be build-tested with non-OF
> configurations.
>
> Reported-by: Randy Dunlap
> Signed-off-by: Philipp Zabel
Acked-by: Randy Dunlap
Thanks.
> ---
> include/drm/drm_modes.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index a0d79d1c51e2..29ba4adf0c53 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -461,9 +461,19 @@ void drm_display_mode_from_videomode(const struct
> videomode *vm,
> void drm_display_mode_to_videomode(const struct drm_display_mode *dmode,
> struct videomode *vm);
> void drm_bus_flags_from_videomode(const struct videomode *vm, u32
> *bus_flags);
> +
> +#if defined(CONFIG_OF)
> int of_get_drm_display_mode(struct device_node *np,
> struct drm_display_mode *dmode, u32 *bus_flags,
> int index);
> +#else
> +static inline int of_get_drm_display_mode(struct device_node *np,
> + struct drm_display_mode *dmode,
> + u32 *bus_flags, int index)
> +{
> + return -EINVAL;
> +}
> +#endif
>
> void drm_mode_set_name(struct drm_display_mode *mode);
> int drm_mode_vrefresh(const struct drm_display_mode *mode);
>
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: panel-simple: add bus-format and connector-type to Innolux n116bge
From: Heiko Stuebner
The Innolux n116bge panel has an eDP connector and 3*6 bits bus format.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 41bbec72b2da..a0b65d263dce 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2265,6 +2265,8 @@ static const struct panel_desc innolux_n116bge = {
.width = 256,
.height = 144,
},
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_eDP,
};
static const struct drm_display_mode innolux_n125hce_gn1_mode = {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/msm/dpu1: Move DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks
Not all DPU versions that are supported in this driver are supposed to have a 8-Levels VIG QoS setting. Move this flag to SDM845 and SC7180 specific masks. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c index 60b304b72b7c..983ee5ac2c45 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -13,14 +13,14 @@ #define VIG_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) |\ - BIT(DPU_SSPP_CSC_10BIT) | BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_QOS_8LVL) |\ + BIT(DPU_SSPP_CSC_10BIT) | BIT(DPU_SSPP_CDP) |\ BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_EXCL_RECT)) #define VIG_SDM845_MASK \ - (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3)) #define VIG_SC7180_MASK \ - (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED4)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4)) #define DMA_SDM845_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\ -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/msm/dsi_pll_10nm: Fix variable usage for pll_lockdet_rate
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value directly, but the same value was also being specified in the dsi_pll_regs struct pll_lockdet_rate variable: let's use it! Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c index 5be562dfbf06..df3e4584dfd7 100644 --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c @@ -302,7 +302,8 @@ static void dsi_pll_commit(struct dsi_pll_10nm *pll) reg->frac_div_start_mid); pll_write(base + REG_DSI_10nm_PHY_PLL_FRAC_DIV_START_HIGH_1, reg->frac_div_start_high); - pll_write(base + REG_DSI_10nm_PHY_PLL_PLL_LOCKDET_RATE_1, 0x40); + pll_write(base + REG_DSI_10nm_PHY_PLL_PLL_LOCKDET_RATE_1, + reg->pll_lockdet_rate); pll_write(base + REG_DSI_10nm_PHY_PLL_PLL_LOCK_DELAY, 0x06); pll_write(base + REG_DSI_10nm_PHY_PLL_CMODE, 0x10); pll_write(base + REG_DSI_10nm_PHY_PLL_CLOCK_INVERTERS, -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Clock fixes for DSI 10nm PLL
The DSI 10nm PLL driver was apparently ported from downstream, but some of its "features" were not ported over, for a good reason. Pity is that the removal of the downstream dependencies broke the clock calculation logic for this driver and that made it impossible to use any DSI display on at least MSM8998. This patch series fixes the calculation issues and also solves some TODOs that I've found in this driver. Tested on: - Sony Xperia XZ Premium (MSM8998) dual-dsi command-mode LCD display - F(x)Tec Pro1 (MSM8998) single dsi, video-mode OLED display AngeloGioacchino Del Regno (5): drm/msm/dsi_pll_10nm: Fix dividing the same numbers twice drm/msm/dsi_pll_10nm: Solve TODO for multiplier frac_bits assignment drm/msm/dsi_pll_10nm: Fix bad VCO rate calculation and prescaler drm/msm/dsi_pll_10nm: Fix variable usage for pll_lockdet_rate drm/msm/dsi_pll_10nm: Convert pr_err prints to DRM_DEV_ERROR drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 43 ++ 1 file changed, 20 insertions(+), 23 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/msm/dpu1: Add prog_fetch_lines_worst_case to INTF_BLK macro
Not all DPU interface sub-block versions need the same value for
prog_fetch_lines_worst_case: add this to the INTF_BLK macro, so
that it becomes possible to vary it for other INTF versions.
For example, this is needed to implement support for older SoCs,
like MSM8998 and SDM630/660 and most probably will also be needed
for future SoCs.
Signed-off-by: AngeloGioacchino Del Regno
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 24 +--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 983ee5ac2c45..253075091409 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -520,33 +520,33 @@ static const struct dpu_pingpong_cfg sm8150_pp[] = {
/*
* INTF sub blocks config
*/
-#define INTF_BLK(_name, _id, _base, _type, _ctrl_id, _features) \
+#define INTF_BLK(_name, _id, _base, _type, _ctrl_id, _progfetch, _features) \
{\
.name = _name, .id = _id, \
.base = _base, .len = 0x280, \
.features = _features, \
.type = _type, \
.controller_id = _ctrl_id, \
- .prog_fetch_lines_worst_case = 24 \
+ .prog_fetch_lines_worst_case = _progfetch \
}
static const struct dpu_intf_cfg sdm845_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SDM845_MASK),
- INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SDM845_MASK),
- INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, INTF_SDM845_MASK),
- INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, INTF_SDM845_MASK),
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, 24, INTF_SDM845_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, 24, INTF_SDM845_MASK),
+ INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, 24, INTF_SDM845_MASK),
+ INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, 24, INTF_SDM845_MASK),
};
static const struct dpu_intf_cfg sc7180_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SC7180_MASK),
- INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SC7180_MASK),
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, 24, INTF_SC7180_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, 24, INTF_SC7180_MASK),
};
static const struct dpu_intf_cfg sm8150_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SC7180_MASK),
- INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SC7180_MASK),
- INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, INTF_SC7180_MASK),
- INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, INTF_SC7180_MASK),
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, 24, INTF_SC7180_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, 24, INTF_SC7180_MASK),
+ INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, 24, INTF_SC7180_MASK),
+ INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, 24, INTF_SC7180_MASK),
};
/*
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/a5xx: Allow all patchid for A540 chip
On at least MSM8998 it's possible to find Adreno 540.0 and 540.1
but I have never found any 540.2. In any case, the patchids 0-1
for A540 are completely supported by this driver and there is no
reason to disallow probing them (as they also share the same
firmware names).
Besides that, the patchid number is also used in the a5xx_power.c
function a540_lm_setup to disable the battery current limiter,
which makes faking the Adreno patchid to .2 (which would anyway
be sad) useless and even producing breakages.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 76a89a8175f8..133e3c15a1b7 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -216,7 +216,7 @@ static const struct adreno_info gpulist[] = {
.init = a5xx_gpu_init,
.zapfw = "a530_zap.mdt",
}, {
- .rev = ADRENO_REV(5, 4, 0, 2),
+ .rev = ADRENO_REV(5, 4, 0, ANY_ID),
.revn = 540,
.name = "A540",
.fw = {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/msm/dpu: Fix VBIF_XINL_QOS_LVL_REMAP_000 register offset
On DPUs prior to version 4 the VBIF_XINL_QOS_LVL_REMAP_000 register
is at 0x570 offset from vbif base instead of 0x590, due to the
VBIF_XINL_QOS_RP_REMAP_000 having less instances (less possible XINs).
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
index cf867f3f7c36..b757054e1c23 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
@@ -30,7 +30,7 @@
#define VBIF_XIN_HALT_CTRL00x0200
#define VBIF_XIN_HALT_CTRL10x0204
#define VBIF_XINL_QOS_RP_REMAP_000 0x0550
-#define VBIF_XINL_QOS_LVL_REMAP_0000x0590
+#define VBIF_XINL_QOS_LVL_REMAP_000(v) (v < DPU_HW_VER_400 ? 0x570 : 0x0590)
static void dpu_hw_clear_errors(struct dpu_hw_vbif *vbif,
u32 *pnd_errors, u32 *src_errors)
@@ -156,18 +156,19 @@ static void dpu_hw_set_qos_remap(struct dpu_hw_vbif *vbif,
u32 xin_id, u32 level, u32 remap_level)
{
struct dpu_hw_blk_reg_map *c;
- u32 reg_val, reg_val_lvl, mask, reg_high, reg_shift;
+ u32 reg_lvl, reg_val, reg_val_lvl, mask, reg_high, reg_shift;
if (!vbif)
return;
c = &vbif->hw;
+ reg_lvl = VBIF_XINL_QOS_LVL_REMAP_000(c->hwversion);
reg_high = ((xin_id & 0x8) >> 3) * 4 + (level * 8);
reg_shift = (xin_id & 0x7) * 4;
reg_val = DPU_REG_READ(c, VBIF_XINL_QOS_RP_REMAP_000 + reg_high);
- reg_val_lvl = DPU_REG_READ(c, VBIF_XINL_QOS_LVL_REMAP_000 + reg_high);
+ reg_val_lvl = DPU_REG_READ(c, reg_lvl + reg_high);
mask = 0x7 << reg_shift;
@@ -178,7 +179,7 @@ static void dpu_hw_set_qos_remap(struct dpu_hw_vbif *vbif,
reg_val_lvl |= (remap_level << reg_shift) & mask;
DPU_REG_WRITE(c, VBIF_XINL_QOS_RP_REMAP_000 + reg_high, reg_val);
- DPU_REG_WRITE(c, VBIF_XINL_QOS_LVL_REMAP_000 + reg_high, reg_val_lvl);
+ DPU_REG_WRITE(c, reg_lvl + reg_high, reg_val_lvl);
}
static void dpu_hw_set_write_gather_en(struct dpu_hw_vbif *vbif, u32 xin_id)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/msm/dpu: Add a function to retrieve the current CTL status
Add a function that returns whether the requested CTL is active or not:
this will be used in a later commit to fix command mode panel issues.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 7 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 758c355b4fd8..626fd41379fb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -82,6 +82,11 @@ static inline void dpu_hw_ctl_trigger_start(struct
dpu_hw_ctl *ctx)
DPU_REG_WRITE(&ctx->hw, CTL_START, 0x1);
}
+static inline bool dpu_hw_ctl_is_started(struct dpu_hw_ctl *ctx)
+{
+ return !!(DPU_REG_READ(&ctx->hw, CTL_START) & BIT(0));
+}
+
static inline void dpu_hw_ctl_trigger_pending(struct dpu_hw_ctl *ctx)
{
trace_dpu_hw_ctl_trigger_prepare(ctx->pending_flush_mask,
@@ -550,6 +555,7 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->get_pending_flush = dpu_hw_ctl_get_pending_flush;
ops->get_flush_register = dpu_hw_ctl_get_flush_register;
ops->trigger_start = dpu_hw_ctl_trigger_start;
+ ops->is_started = dpu_hw_ctl_is_started;
ops->trigger_pending = dpu_hw_ctl_trigger_pending;
ops->reset = dpu_hw_ctl_reset_control;
ops->wait_reset_status = dpu_hw_ctl_wait_reset_status;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index ec579b470a80..c376b5ae7803 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -59,6 +59,13 @@ struct dpu_hw_ctl_ops {
*/
void (*trigger_start)(struct dpu_hw_ctl *ctx);
+ /**
+* check if the ctl is started
+* @ctx : ctl path ctx pointer
+* @Return: true if started, false if stopped
+*/
+ bool (*is_started)(struct dpu_hw_ctl *ctx);
+
/**
* kickoff prepare is in progress hw operation for sw
* controlled interfaces: DSI cmd mode and WB interface
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm/msm/dpu: Correctly configure vsync tearcheck for command mode
When configuring the tearcheck, the parameters for the engine were being set mostly as they should've been, but then it wasn't getting configured to get the vsync indication from the TE GPIO input because it was assumed that autorefresh could be enabled: since a previous commit makes sure to disable the autorefresh bit when committing to the cmd engine, it is now safe to just enable the vsync pin input at tearcheck setup time (instead of erroneously never enabling it). Also, set the right sync_cfg_height to enable the DPU auto-generated TE signal in order to avoid stalls in the event that we miss one external TE signal: this will still trigger recovery mechanisms in case the display is really unreachable. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index a367b093c888..c5cf59b5bd41 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -372,15 +372,12 @@ static void dpu_encoder_phys_cmd_tearcheck_config( tc_cfg.vsync_count = vsync_hz / (mode->vtotal * drm_mode_vrefresh(mode)); - /* enable external TE after kickoff to avoid premature autorefresh */ - tc_cfg.hw_vsync_mode = 0; - /* -* By setting sync_cfg_height to near max register value, we essentially -* disable dpu hw generated TE signal, since hw TE will arrive first. -* Only caveat is if due to error, we hit wrap-around. +* Set the sync_cfg_height to twice vtotal so that if we lose a +* TE event coming from the display TE pin we won't stall immediately */ - tc_cfg.sync_cfg_height = 0xFFF0; + tc_cfg.hw_vsync_mode = 1; + tc_cfg.sync_cfg_height = mode->vtotal * 2; tc_cfg.vsync_init_val = mode->vdisplay; tc_cfg.sync_threshold_start = DEFAULT_TEARCHECK_SYNC_THRESH_START; tc_cfg.sync_threshold_continue = DEFAULT_TEARCHECK_SYNC_THRESH_CONTINUE; -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/msm/dpu1: Allow specifying features and sblk in DSPP_BLK macro
The DSPP_BLK macro was ad-hoc made for SC7180, but this is wrong
because not all of the DPU DSPP versions can use the same DSPP block
configuration, and not all of them have got the same features.
For this reason, add two more params to the DSPP_BLK macro, so that
it is possible to specify the feature mask and the sblk config for
each DSPP.
Fixes: 4259ff7ae509 ("drm/msm/dpu: add support for pcc color block in dpu
driver")
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 253075091409..d1aebb5f48c1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -454,16 +454,17 @@ static const struct dpu_dspp_sub_blks sc7180_dspp_sblk = {
.len = 0x90, .version = 0x1},
};
-#define DSPP_BLK(_name, _id, _base) \
+#define DSPP_BLK(_name, _id, _base, _mask, _desc) \
{\
.name = _name, .id = _id, \
.base = _base, .len = 0x1800, \
- .features = DSPP_SC7180_MASK, \
- .sblk = &sc7180_dspp_sblk \
+ .features = _mask, \
+ .sblk = _desc \
}
static const struct dpu_dspp_cfg sc7180_dspp[] = {
- DSPP_BLK("dspp_0", DSPP_0, 0x54000),
+ DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
+&sc7180_dspp_sblk),
};
/*
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/msm/dsi_pll_10nm: Fix dividing the same numbers twice
In function dsi_pll_calc_dec_frac we are calculating the decimal div start parameter by dividing the decimal multiple by the fractional multiplier: the remainder of that operation is stored to then get programmed to the fractional divider registers of the PLL. It's useless to call div_u64_rem to get the remainder and *then* call div_u64 to get the division result, as the first is already giving that result: let's fix it by just caring about the result of div_u64_rem. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c index 6ac04fc303f5..2c1fcf092ab8 100644 --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c @@ -172,9 +172,7 @@ static void dsi_pll_calc_dec_frac(struct dsi_pll_10nm *pll) multiplier = 1 << config->frac_bits; dec_multiple = div_u64(pll_freq * multiplier, divider); - div_u64_rem(dec_multiple, multiplier, &frac); - - dec = div_u64(dec_multiple, multiplier); + dec = div_u64_rem(dec_multiple, multiplier, &frac); if (pll_freq <= 19UL) regs->pll_prop_gain_rate = 8; -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/msm/dsi_pll_10nm: Convert pr_err prints to DRM_DEV_ERROR
DRM_DEV_ERROR should be used across this entire source: convert the
pr_err prints to the first as a cleanup.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index df3e4584dfd7..f1091c023836 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -342,6 +342,7 @@ static int dsi_pll_10nm_vco_set_rate(struct clk_hw *hw,
unsigned long rate,
static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm *pll)
{
+ struct device *dev = &pll->pdev->dev;
int rc;
u32 status = 0;
u32 const delay_us = 100;
@@ -354,8 +355,8 @@ static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm
*pll)
delay_us,
timeout_us);
if (rc)
- pr_err("DSI PLL(%d) lock failed, status=0x%08x\n",
- pll->id, status);
+ DRM_DEV_ERROR(dev, "DSI PLL(%d) lock failed, status=0x%08x\n",
+ pll->id, status);
return rc;
}
@@ -402,6 +403,7 @@ static int dsi_pll_10nm_vco_prepare(struct clk_hw *hw)
{
struct msm_dsi_pll *pll = hw_clk_to_pll(hw);
struct dsi_pll_10nm *pll_10nm = to_pll_10nm(pll);
+ struct device *dev = &pll_10nm->pdev->dev;
int rc;
dsi_pll_enable_pll_bias(pll_10nm);
@@ -410,7 +412,7 @@ static int dsi_pll_10nm_vco_prepare(struct clk_hw *hw)
rc = dsi_pll_10nm_vco_set_rate(hw,pll_10nm->vco_current_rate, 0);
if (rc) {
- pr_err("vco_set_rate failed, rc=%d\n", rc);
+ DRM_DEV_ERROR(dev, "vco_set_rate failed, rc=%d\n", rc);
return rc;
}
@@ -427,7 +429,7 @@ static int dsi_pll_10nm_vco_prepare(struct clk_hw *hw)
/* Check for PLL lock */
rc = dsi_pll_10nm_lock_status(pll_10nm);
if (rc) {
- pr_err("PLL(%d) lock failed\n", pll_10nm->id);
+ DRM_DEV_ERROR(dev, "PLL(%d) lock failed\n", pll_10nm->id);
goto error;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/9] Qualcomm DRM DPU fixes
This patch series brings some fixes to the Qualcomm DPU driver, aim is to get it prepared for "legacy" SoCs (like MSM8998, SDM630/660) and to finally get command-mode displays working on this driver. The series was tested against MSM8998 (the commit that introduces it to the hw-catalog is not included in this series, as it needs to be cleaned up a little more) and specifically on: - Sony Xperia XZ Premium (MSM8998), 4K dual-dsi LCD display, command-mode - F(x)Tec Pro1 (MSM8998), single-dsi OLED display, video-mode ... And it obviously worked just perfect! AngeloGioacchino Del Regno (9): drm/msm/dpu: Fix VBIF_XINL_QOS_LVL_REMAP_000 register offset drm/msm/dpu1: Move DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks drm/msm/dpu1: Add prog_fetch_lines_worst_case to INTF_BLK macro drm/msm/dpu1: Allow specifying features and sblk in DSPP_BLK macro drm/msm/dpu: Disable autorefresh in command mode drm/msm/dpu: Correctly configure vsync tearcheck for command mode drm/msm/dpu: Remove unused call in wait_for_commit_done drm/msm/dpu: Add a function to retrieve the current CTL status drm/msm/dpu: Fix timeout issues on command mode panels .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 91 --- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 39 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 6 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h| 7 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 26 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 9 +- 7 files changed, 155 insertions(+), 37 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/msm/dsi_pll_10nm: Fix bad VCO rate calculation and prescaler
The VCO rate was being miscalculated due to a big overlook during
the process of porting this driver from downstream to upstream:
here we are really recalculating the rate of the VCO by reading
the appropriate registers and returning a real frequency, while
downstream the driver was doing something entirely different.
In our case here, the recalculated rate was wrong, as it was then
given back to the set_rate function, which was erroneously doing
a division on the fractional value, based on the prescaler being
either enabled or disabled: this was actually producing a bug for
which the final VCO rate was being doubled, causing very obvious
issues when trying to drive a DSI panel because the actual divider
value was multiplied by two!
To make things work properly, remove the multiplication of the
reference clock by two from function dsi_pll_calc_dec_frac and
account for the prescaler enablement in the vco_recalc_rate (if
the prescaler is enabled, then the hardware will divide the rate
by two).
This will make the vco_recalc_rate function to pass the right
frequency to the (clock framework) set_rate function when called,
which will - in turn - program the right values in both the
DECIMAL_DIV_START_1 and the FRAC_DIV_START_{LOW/MID/HIGH}_1
registers, finally making the PLL to output the right clock.
Also, while at it, remove the prescaler TODO by also adding the
possibility of disabling the prescaler on the PLL (it is in the
PLL_ANALOG_CONTROLS_ONE register).
Of course, both prescaler-ON and OFF cases were tested.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index 8b66e852eb36..5be562dfbf06 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -165,11 +165,7 @@ static void dsi_pll_calc_dec_frac(struct dsi_pll_10nm *pll)
pll_freq = pll->vco_current_rate;
- if (config->disable_prescaler)
- divider = fref;
- else
- divider = fref * 2;
-
+ divider = fref;
multiplier = 1 << config->frac_bits;
dec_multiple = div_u64(pll_freq * multiplier, divider);
dec = div_u64_rem(dec_multiple, multiplier, &frac);
@@ -266,9 +262,11 @@ static void dsi_pll_ssc_commit(struct dsi_pll_10nm *pll)
static void dsi_pll_config_hzindep_reg(struct dsi_pll_10nm *pll)
{
+ struct dsi_pll_config *config = &pll->pll_configuration;
void __iomem *base = pll->mmio;
+ u32 val = config->disable_prescaler ? 0x0 : 0x80;
- pll_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_ONE, 0x80);
+ pll_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_ONE, val);
pll_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_TWO, 0x03);
pll_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_THREE, 0x00);
pll_write(base + REG_DSI_10nm_PHY_PLL_DSM_DIVIDER, 0x00);
@@ -499,17 +497,15 @@ static unsigned long dsi_pll_10nm_vco_recalc_rate(struct
clk_hw *hw,
frac |= ((pll_read(base + REG_DSI_10nm_PHY_PLL_FRAC_DIV_START_HIGH_1) &
0x3) << 16);
- /*
-* TODO:
-* 1. Assumes prescaler is disabled
-*/
multiplier = 1 << config->frac_bits;
- pll_freq = dec * (ref_clk * 2);
- tmp64 = (ref_clk * 2 * frac);
+ pll_freq = dec * ref_clk;
+ tmp64 = ref_clk * frac;
pll_freq += div_u64(tmp64, multiplier);
-
vco_rate = pll_freq;
+ if (config->disable_prescaler)
+ vco_rate = div_u64(vco_rate, 2);
+
DBG("DSI PLL%d returning vco rate = %lu, dec = %x, frac = %x",
pll_10nm->id, (unsigned long)vco_rate, dec, frac);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/msm/dsi_pll_10nm: Solve TODO for multiplier frac_bits assignment
The number of fractional registers bits is known and already set in
the frac_bits variable of the dsi_pll_config struct here in 10nm:
remove the TODO by simply using that variable.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index 2c1fcf092ab8..8b66e852eb36 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -481,6 +481,7 @@ static unsigned long dsi_pll_10nm_vco_recalc_rate(struct
clk_hw *hw,
{
struct msm_dsi_pll *pll = hw_clk_to_pll(hw);
struct dsi_pll_10nm *pll_10nm = to_pll_10nm(pll);
+ struct dsi_pll_config *config = &pll_10nm->pll_configuration;
void __iomem *base = pll_10nm->mmio;
u64 ref_clk = pll_10nm->vco_ref_clk_rate;
u64 vco_rate = 0x0;
@@ -501,9 +502,8 @@ static unsigned long dsi_pll_10nm_vco_recalc_rate(struct
clk_hw *hw,
/*
* TODO:
* 1. Assumes prescaler is disabled
-* 2. Multiplier is 2^18. it should be 2^(num_of_frac_bits)
*/
- multiplier = 1 << 18;
+ multiplier = 1 << config->frac_bits;
pll_freq = dec * (ref_clk * 2);
tmp64 = (ref_clk * 2 * frac);
pll_freq += div_u64(tmp64, multiplier);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/msm/dpu: Disable autorefresh in command mode
When a command mode display is used, it may be retaining the bootloader
configuration which, in most of the cases, enables the autorefresh
feature in order to keep the splash up.
Since there is no autorefresh management in this driver, wire up the
autorefresh ops in the dpu_hw_pingpong and disable the feature when
preparing for cmd commit: instead of disabling it when initializing
the command mode, this road was chosen as to open future possibility
of enabling and managing the autorefresh feature in the driver.
Signed-off-by: AngeloGioacchino Del Regno
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 68 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 26 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14
3 files changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 8493d68ad841..a367b093c888 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -4,8 +4,10 @@
*/
#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
+#include
#include "dpu_encoder_phys.h"
#include "dpu_hw_interrupts.h"
+#include "dpu_hw_pingpong.h"
#include "dpu_core_irq.h"
#include "dpu_formats.h"
#include "dpu_trace.h"
@@ -35,6 +37,8 @@
#define DPU_ENC_WR_PTR_START_TIMEOUT_US 2
+#define DPU_ENC_MAX_POLL_TIMEOUT_US2000
+
static bool dpu_encoder_phys_cmd_is_master(struct dpu_encoder_phys *phys_enc)
{
return (phys_enc->split_role != ENC_ROLE_SLAVE) ? true : false;
@@ -582,6 +586,69 @@ static void dpu_encoder_phys_cmd_prepare_for_kickoff(
atomic_read(&phys_enc->pending_kickoff_cnt));
}
+static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
+ struct dpu_encoder_phys *phys_enc)
+{
+ struct dpu_hw_pp_vsync_info info;
+
+ if (!phys_enc)
+ return false;
+
+ phys_enc->hw_pp->ops.get_vsync_info(phys_enc->hw_pp, &info);
+ if (info.wr_ptr_line_count > 0 &&
+ info.wr_ptr_line_count < phys_enc->cached_mode.vdisplay)
+ return true;
+
+ return false;
+}
+
+static void dpu_encoder_phys_cmd_prepare_commit(
+ struct dpu_encoder_phys *phys_enc)
+{
+ struct dpu_encoder_phys_cmd *cmd_enc =
+ to_dpu_encoder_phys_cmd(phys_enc);
+ int trial = 0;
+
+ if (!phys_enc)
+ return;
+ if (!phys_enc->hw_pp)
+ return;
+ if (!dpu_encoder_phys_cmd_is_master(phys_enc))
+ return;
+
+ /* If autorefresh is already disabled, we have nothing to do */
+ if (!phys_enc->hw_pp->ops.get_autorefresh(phys_enc->hw_pp, NULL))
+ return;
+
+ /*
+* If autorefresh is enabled, disable it and make sure it is safe to
+* proceed with current frame commit/push. Sequence fallowed is,
+* 1. Disable TE
+* 2. Disable autorefresh config
+* 4. Poll for frame transfer ongoing to be false
+* 5. Enable TE back
+*/
+ _dpu_encoder_phys_cmd_connect_te(phys_enc, false);
+ phys_enc->hw_pp->ops.setup_autorefresh(phys_enc->hw_pp, 0, false);
+
+ do {
+ udelay(DPU_ENC_MAX_POLL_TIMEOUT_US);
+ if ((trial * DPU_ENC_MAX_POLL_TIMEOUT_US)
+ > (KICKOFF_TIMEOUT_MS * USEC_PER_MSEC)) {
+ DPU_ERROR_CMDENC(cmd_enc,
+ "disable autorefresh failed\n");
+ break;
+ }
+
+ trial++;
+ } while (dpu_encoder_phys_cmd_is_ongoing_pptx(phys_enc));
+
+ _dpu_encoder_phys_cmd_connect_te(phys_enc, true);
+
+ DPU_DEBUG_CMDENC(to_dpu_encoder_phys_cmd(phys_enc),
+"disabled autorefresh\n");
+}
+
static int _dpu_encoder_phys_cmd_wait_for_ctl_start(
struct dpu_encoder_phys *phys_enc)
{
@@ -683,6 +750,7 @@ static void dpu_encoder_phys_cmd_trigger_start(
static void dpu_encoder_phys_cmd_init_ops(
struct dpu_encoder_phys_ops *ops)
{
+ ops->prepare_commit = dpu_encoder_phys_cmd_prepare_commit;
ops->is_master = dpu_encoder_phys_cmd_is_master;
ops->mode_set = dpu_encoder_phys_cmd_mode_set;
ops->mode_fixup = dpu_encoder_phys_cmd_mode_fixup;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index bea4ab5c58c5..245a7a62b5c6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -23,6 +23,7 @@
#define PP_WR_PTR_IRQ 0x024
#define PP_OUT_LINE_COUNT 0x028
#define PP_LINE_COUNT 0x02C
+#define PP_AUTOREFRESH_CONFIG 0x030
#define PP_FBC_MODE 0x034
#define PP_FBC_BUDGET_CTL 0x038
@@ -120,6 +121,29 @@ static int dpu_hw
[PATCH 7/9] drm/msm/dpu: Remove unused call in wait_for_commit_done
The call to dpu_encoder_phys_cmd_prepare_for_kickoff is useless as
it's unused because the serialize_wait4pp variable is never set to
true by .. anything, literally: remove the call.
While at it, also reduce indentation by inverting the check for
dpu_encoder_phys_cmd_is_master.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index c5cf59b5bd41..2311e98480b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -687,20 +687,15 @@ static int dpu_encoder_phys_cmd_wait_for_tx_complete(
static int dpu_encoder_phys_cmd_wait_for_commit_done(
struct dpu_encoder_phys *phys_enc)
{
- int rc = 0;
struct dpu_encoder_phys_cmd *cmd_enc;
cmd_enc = to_dpu_encoder_phys_cmd(phys_enc);
/* only required for master controller */
- if (dpu_encoder_phys_cmd_is_master(phys_enc))
- rc = _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc);
-
- /* required for both controllers */
- if (!rc && cmd_enc->serialize_wait4pp)
- dpu_encoder_phys_cmd_prepare_for_kickoff(phys_enc);
+ if (!dpu_encoder_phys_cmd_is_master(phys_enc))
+ return 0;
- return rc;
+ return _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc);
}
static int dpu_encoder_phys_cmd_wait_for_vblank(
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] drm/msm/dpu: Fix timeout issues on command mode panels
In function dpu_encoder_phys_cmd_wait_for_commit_done we are always checking if the relative CTL is started by waiting for an interrupt to fire: it is fine to do that, but then sometimes we call this function while the CTL is up and has never been put down, but that interrupt gets raised only when the CTL gets a state change from 0 to 1 (disabled to enabled), so we're going to wait for something that will never happen on its own. Solving this while avoiding to restart the CTL is actually possible and can be done by just checking if it is already up and running when the wait_for_commit_done function is called: in this case, so, if the CTL was already running, we can say that the commit is done if the command transmission is complete (in other terms, if the interface has been flushed). Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index 2311e98480b9..0624864da343 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -695,6 +695,9 @@ static int dpu_encoder_phys_cmd_wait_for_commit_done( if (!dpu_encoder_phys_cmd_is_master(phys_enc)) return 0; + if (phys_enc->hw_ctl->ops.is_started) + return dpu_encoder_phys_cmd_wait_for_tx_complete(phys_enc); + return _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc); } -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver, On Fri, Jan 8, 2021 at 7:24 PM Oliver Graute wrote: > > On 19/12/20, Oliver Graute wrote: > > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD > > to panel-simple. > > > > The panel spec from Variscite can be found at: > > https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf > > some clue what bus_format and bus_flags I have to use? > > [ 42.505156] panel-simple panel-lcd: Specify missing bus_flags > [ 42.511090] panel-simple panel-lcd: Specify missing bus_format > [ 42.615131] mxsfb 21c8000.lcdif: Cannot connect bridge: -517 Does this patch work? https://pastebin.com/raw/diTMVsh8 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] soc: mediatek: cmdq: Remove cmdq_pkt_flush()
Hi, Matthias:
Chun-Kuang Hu 於 2020年12月3日 週四 上午7:59寫道：
>
> rx_callback is a standard mailbox callback mechanism and could
> cover the function of proprietary cmdq_task_cb, so it is better
> to use the standard one instead of the proprietary one. But
> register rx_callback should before mbox_request_channel(),
> so remove cmdq_pkt_flush() and let client driver implement
> its own synchronous flush.
How do you think about this patch? This patch is derived from [1]
according to Jassi's suggestion [2].
[1]
https://patchwork.kernel.org/project/linux-mediatek/patch/20200927230422.11610-3-chunkuang...@kernel.org/
[2]
https://patchwork.kernel.org/project/linux-mediatek/cover/20200927230422.11610-1-chunkuang...@kernel.org/
Regards,
Chun-Kuang.
>
> Signed-off-by: Chun-Kuang Hu
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 32 --
> include/linux/soc/mediatek/mtk-cmdq.h | 12 --
> 2 files changed, 44 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 505651b0d715..fd3bc39538a1 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -502,36 +502,4 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt,
> cmdq_async_flush_cb cb,
> }
> EXPORT_SYMBOL(cmdq_pkt_flush_async);
>
> -struct cmdq_flush_completion {
> - struct completion cmplt;
> - bool err;
> -};
> -
> -static void cmdq_pkt_flush_cb(struct cmdq_cb_data data)
> -{
> - struct cmdq_flush_completion *cmplt;
> -
> - cmplt = (struct cmdq_flush_completion *)data.data;
> - if (data.sta != CMDQ_CB_NORMAL)
> - cmplt->err = true;
> - else
> - cmplt->err = false;
> - complete(&cmplt->cmplt);
> -}
> -
> -int cmdq_pkt_flush(struct cmdq_pkt *pkt)
> -{
> - struct cmdq_flush_completion cmplt;
> - int err;
> -
> - init_completion(&cmplt.cmplt);
> - err = cmdq_pkt_flush_async(pkt, cmdq_pkt_flush_cb, &cmplt);
> - if (err < 0)
> - return err;
> - wait_for_completion(&cmplt.cmplt);
> -
> - return cmplt.err ? -EFAULT : 0;
> -}
> -EXPORT_SYMBOL(cmdq_pkt_flush);
> -
> MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 960704d75994..2c6aa84c0e80 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -288,16 +288,4 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
> int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
> void *data);
>
> -/**
> - * cmdq_pkt_flush() - trigger CMDQ to execute the CMDQ packet
> - * @pkt: the CMDQ packet
> - *
> - * Return: 0 for success; else the error code is returned
> - *
> - * Trigger CMDQ to execute the CMDQ packet. Note that this is a
> - * synchronous flush function. When the function returned, the recorded
> - * commands have been done.
> - */
> -int cmdq_pkt_flush(struct cmdq_pkt *pkt);
> -
> #endif /* __MTK_CMDQ_H__ */
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Check actual format for legacy pageflip.
With modifiers one can actually have different format_info structs
for the same format, which now matters for AMDGPU since we convert
implicit modifiers to explicit modifiers with multiple planes.
I checked other drivers and it doesn't look like they end up triggering
this case so I think this is safe to relax.
Signed-off-by: Bas Nieuwenhuizen
Reviewed-by: Daniel Vetter
Reviewed-by: Zhan Liu
Acked-by: Christian König
Acked-by: Alex Deucher
Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
metadata.")
---
drivers/gpu/drm/drm_plane.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index e6231947f987..a0cb746bcb0a 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1163,7 +1163,14 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (ret)
goto out;
- if (old_fb->format != fb->format) {
+ /*
+* Only check the FOURCC format code, excluding modifiers. This is
+* enough for all legacy drivers. Atomic drivers have their own
+* checks in their ->atomic_check implementation, which will
+* return -EINVAL if any hw or driver constraint is violated due
+* to modifier changes.
+*/
+ if (old_fb->format->format != fb->format->format) {
DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer
format.\n");
ret = -EINVAL;
goto out;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
