Re: [PATCH v6 1/4] dt-bindings: display: mediatek: add property to control mipi tx drive current
Hi, Rob:
How do you think about this patch? This patch looks good to me.
Regards,
Chun-Kuang.
Jitao Shi 於 2020年4月11日 週六 下午3:44寫道：
>
> Add a property to control mipi tx drive current:
> "drive-strength-microamp"
>
> Reviewed-by: Chun-Kuang Hu
> Signed-off-by: Jitao Shi
> ---
> .../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> index a19a6cc375ed..d78b6d6d8fab 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> @@ -33,6 +33,10 @@ Required properties:
> - #clock-cells: must be <0>;
> - #phy-cells: must be <0>.
>
> +Optional properties:
> +- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
> + the step is 200.
> +
> Example:
>
> mipi_tx0: mipi-dphy@10215000 {
> @@ -42,6 +46,7 @@ mipi_tx0: mipi-dphy@10215000 {
> clock-output-names = "mipi_tx0_pll";
> #clock-cells = <0>;
> #phy-cells = <0>;
> + drive-strength-microamp = <4600>;
> };
>
> dsi0: dsi@1401b000 {
> --
> 2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 3/3] drm/mediatek: set dpi pin mode to gpio low to avoid leakage current
Hi, Jitao:
Jitao Shi 於 2020年4月15日 週三 上午9:13寫道：
>
> Config dpi pins mode to output and pull low when dpi is disabled.
> Aovid leakage current from some dpi pins (Hsync Vsync DE ... ).
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,Chun-Kuang.
>
> Reviewed-by: Chun-Kuang Hu
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 087f5ce732e1..1e01254788d9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -10,7 +10,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
>
> @@ -74,6 +76,9 @@ struct mtk_dpi {
> enum mtk_dpi_out_yc_map yc_map;
> enum mtk_dpi_out_bit_num bit_num;
> enum mtk_dpi_out_channel_swap channel_swap;
> + struct pinctrl *pinctrl;
> + struct pinctrl_state *pins_gpio;
> + struct pinctrl_state *pins_dpi;
> int refcount;
> };
>
> @@ -379,6 +384,9 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi)
> if (--dpi->refcount != 0)
> return;
>
> + if (dpi->pinctrl && dpi->pins_gpio)
> + pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
> +
> mtk_dpi_disable(dpi);
> clk_disable_unprepare(dpi->pixel_clk);
> clk_disable_unprepare(dpi->engine_clk);
> @@ -403,6 +411,9 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
> goto err_pixel;
> }
>
> + if (dpi->pinctrl && dpi->pins_dpi)
> + pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
> +
> mtk_dpi_enable(dpi);
> return 0;
>
> @@ -705,6 +716,26 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> dpi->dev = dev;
> dpi->conf = (struct mtk_dpi_conf *)of_device_get_match_data(dev);
>
> + dpi->pinctrl = devm_pinctrl_get(&pdev->dev);
> + if (IS_ERR(dpi->pinctrl)) {
> + dpi->pinctrl = NULL;
> + dev_dbg(&pdev->dev, "Cannot find pinctrl!\n");
> + }
> + if (dpi->pinctrl) {
> + dpi->pins_gpio = pinctrl_lookup_state(dpi->pinctrl, "sleep");
> + if (IS_ERR(dpi->pins_gpio)) {
> + dpi->pins_gpio = NULL;
> + dev_dbg(&pdev->dev, "Cannot find pinctrl idle!\n");
> + }
> + if (dpi->pins_gpio)
> + pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
> +
> + dpi->pins_dpi = pinctrl_lookup_state(dpi->pinctrl, "default");
> + if (IS_ERR(dpi->pins_dpi)) {
> + dpi->pins_dpi = NULL;
> + dev_dbg(&pdev->dev, "Cannot find pinctrl active!\n");
> + }
> + }
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> dpi->regs = devm_ioremap_resource(dev, mem);
> if (IS_ERR(dpi->regs)) {
> --
> 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
Re: [PATCH v15 1/3] dt-bindings: display: mediatek: control dpi pins mode to avoid leakage
Hi, Jitao:
Jitao Shi 於 2020年4月15日 週三 上午9:13寫道：
>
> Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. Set
> the dpi pins to gpio mode and output-low to avoid leakage current when dpi
> disabled.
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Acked-by: Rob Herring
> Reviewed-by: Chun-Kuang Hu
> Signed-off-by: Jitao Shi
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt | 6
> ++
> 1 file changed, 6 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> index 58914cf681b8..77def4456706 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> @@ -17,6 +17,9 @@ Required properties:
>Documentation/devicetree/bindings/graph.txt. This port should be connected
>to the input port of an attached HDMI or LVDS encoder chip.
>
> +Optional properties:
> +- pinctrl-names: Contain "default" and "sleep".
> +
> Example:
>
> dpi0: dpi@1401d000 {
> @@ -27,6 +30,9 @@ dpi0: dpi@1401d000 {
> <&mmsys CLK_MM_DPI_ENGINE>,
> <&apmixedsys CLK_APMIXED_TVDPLL>;
> clock-names = "pixel", "engine", "pll";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&dpi_pin_func>;
> + pinctrl-1 = <&dpi_pin_idle>;
>
> port {
> dpi0_out: endpoint {
> --
> 2.12.5
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.7-rc2
The pull request you sent on Sat, 18 Apr 2020 14:24:32 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-04-18 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fecca68997833ef75f338fbbb76dd12fae7ca3b5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.7-rc2
On Fri, Apr 17, 2020 at 9:24 PM Dave Airlie wrote: > > amdgpu: > - Fix a regression in a previous s/r fix Side note: if I hadn't been cc'd on the problem, I'd never have had a clue what s/r stood for. I'd have assumed that it's some special amdgpu term. And the language in the actual commit message itself is not very helpful. So please do write things like this out a bit more. I expanded that "s/r" to "suspend/resume", although the change was the suspend, and the bug was how it impacted shutdown, so I guess that's not all that clear either. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/9] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP
From: "Rafael J. Wysocki"
Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which
matches its purpose more closely.
No functional impact.
Signed-off-by: Rafael J. Wysocki
Acked-by: Bjorn Helgaas # for PCI parts
Acked-by: Jeff Kirsher
---
-> v2:
* Rebased.
* Added tags received so far.
---
Documentation/driver-api/pm/devices.rst| 6 +++---
Documentation/power/pci.rst| 10 +-
drivers/base/power/main.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.c| 2 +-
drivers/gpu/drm/radeon/radeon_kms.c| 2 +-
drivers/misc/mei/pci-me.c | 2 +-
drivers/misc/mei/pci-txe.c | 2 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/intel/igc/igc_main.c | 2 +-
drivers/pci/pcie/portdrv_pci.c | 2 +-
include/linux/pm.h | 6 +++---
13 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/Documentation/driver-api/pm/devices.rst
b/Documentation/driver-api/pm/devices.rst
index f66c7b9126ea..4ace0eba4506 100644
--- a/Documentation/driver-api/pm/devices.rst
+++ b/Documentation/driver-api/pm/devices.rst
@@ -361,9 +361,9 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``,
``suspend_noirq``.
runtime PM disabled.
This feature also can be controlled by device drivers by using the
- ``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power
- management flags. [Typically, they are set at the time the driver is
- probed against the device in question by passing them to the
+ ``DPM_FLAG_NO_DIRECT_COMPLETE`` and ``DPM_FLAG_SMART_PREPARE`` driver
+ power management flags. [Typically, they are set at the time the driver
+ is probed against the device in question by passing them to the
:c:func:`dev_pm_set_driver_flags` helper function.] If the first of
these flags is set, the PM core will not apply the direct-complete
procedure described above to the given device and, consequenty, to any
diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst
index aa1c7fce6cd0..9e1408121bea 100644
--- a/Documentation/power/pci.rst
+++ b/Documentation/power/pci.rst
@@ -1004,11 +1004,11 @@ including the PCI bus type. The flags should be set
once at the driver probe
time with the help of the dev_pm_set_driver_flags() function and they should
not
be updated directly afterwards.
-The DPM_FLAG_NEVER_SKIP flag prevents the PM core from using the
direct-complete
-mechanism allowing device suspend/resume callbacks to be skipped if the device
-is in runtime suspend when the system suspend starts. That also affects all of
-the ancestors of the device, so this flag should only be used if absolutely
-necessary.
+The DPM_FLAG_NO_DIRECT_COMPLETE flag prevents the PM core from using the
+direct-complete mechanism allowing device suspend/resume callbacks to be
skipped
+if the device is in runtime suspend when the system suspend starts. That also
+affects all of the ancestors of the device, so this flag should only be used if
+absolutely necessary.
The DPM_FLAG_SMART_PREPARE flag instructs the PCI bus type to only return a
positive value from pci_pm_prepare() if the ->prepare callback provided by the
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 3170d93e29f9..dbc1e5e7346b 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1844,7 +1844,7 @@ static int device_prepare(struct device *dev,
pm_message_t state)
spin_lock_irq(&dev->power.lock);
dev->power.direct_complete = state.event == PM_EVENT_SUSPEND &&
(ret > 0 || dev->power.no_pm_callbacks) &&
- !dev_pm_test_driver_flags(dev, DPM_FLAG_NEVER_SKIP);
+ !dev_pm_test_driver_flags(dev, DPM_FLAG_NO_DIRECT_COMPLETE);
spin_unlock_irq(&dev->power.lock);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index fd1dc3236eca..a9086ea1ab60 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -191,7 +191,7 @@ int amdgpu_driver_load_kms(struct drm_device *dev, unsigned
long flags)
}
if (adev->runpm) {
- dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NEVER_SKIP);
+ dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NO_DIRECT_COMPLETE);
pm_runtime_use_autosuspend(dev->dev);
pm_runtime_set_autosuspend_delay(dev->dev, 5000);
pm_runtime_set_active(dev->dev);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index ad719c9602af..9cb2d7548daa 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -549,7 +549,7 @@ void intel_runtim
Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'
On Wed, 15 Apr 2020 19:55:49 -0500 Rob Herring wrote: > json-schema versions draft7 and earlier have a weird behavior in that > any keywords combined with a '$ref' are ignored (silently). The correct > form was to put a '$ref' under an 'allOf'. This behavior is now changed > in the 2019-09 json-schema spec and '$ref' can be mixed with other > keywords. The json-schema library doesn't yet support this, but the > tooling now does a fixup for this and either way works. > > This has been a constant source of review comments, so let's change this > treewide so everyone copies the simpler syntax. > > Signed-off-by: Rob Herring A few unrelated white space changes in enums in the IIO chunks. Don't suppose they matter but maybe need the description to mention there may be some minor formatting changes as well in some cases. Acked-by: Jonathan Cameron #for-iio > --- > .../devicetree/bindings/arm/cpus.yaml | 81 +++--- > .../devicetree/bindings/arm/l2c2x0.yaml | 87 +++--- > .../devicetree/bindings/arm/psci.yaml | 15 +- > .../bindings/arm/samsung/exynos-chipid.yaml | 5 +- > .../bus/allwinner,sun50i-a64-de2.yaml | 5 +- > .../bindings/clock/fixed-factor-clock.yaml| 5 +- > .../bindings/connector/usb-connector.yaml | 28 +- > .../bindings/crypto/st,stm32-hash.yaml| 9 +- > .../allwinner,sun4i-a10-display-engine.yaml | 7 +- > .../display/allwinner,sun4i-a10-tcon.yaml | 5 +- > .../bindings/display/panel/panel-common.yaml | 5 +- > .../devicetree/bindings/dma/dma-common.yaml | 3 +- > .../devicetree/bindings/dma/ti/k3-udma.yaml | 18 +- > .../devicetree/bindings/eeprom/at24.yaml | 11 +- > .../devicetree/bindings/example-schema.yaml | 17 +- > .../bindings/hwmon/adi,ltc2947.yaml | 32 +-- > .../devicetree/bindings/hwmon/ti,tmp513.yaml | 21 +- > .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 9 +- > .../bindings/iio/adc/adi,ad7124.yaml | 5 +- > .../bindings/iio/adc/lltc,ltc2496.yaml| 3 +- > .../bindings/iio/adc/microchip,mcp3911.yaml | 7 +- > .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 31 +- > .../bindings/iio/light/tsl2772.yaml | 13 +- > .../bindings/iio/temperature/adi,ltc2983.yaml | 56 ++-- ... > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml > b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml > index 97087a45ce54..deb34deff0e8 100644 > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml > @@ -83,9 +83,8 @@ patternProperties: >1: REFIN2(+)/REFIN2(−). >3: AVDD >If this field is left empty, internal reference is selected. > -allOf: > - - $ref: /schemas/types.yaml#/definitions/uint32 > - - enum: [0, 1, 3] > +$ref: /schemas/types.yaml#/definitions/uint32 > +enum: [0, 1, 3] > >diff-channels: > description: see Documentation/devicetree/bindings/iio/adc/adc.txt > diff --git a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml > b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml > index 97f521d654ea..6a991e9f78e2 100644 > --- a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml > @@ -18,8 +18,7 @@ properties: > >vref-supply: > description: phandle to an external regulator providing the reference > voltage > -allOf: > - - $ref: /schemas/types.yaml#/definitions/phandle > +$ref: /schemas/types.yaml#/definitions/phandle > >reg: > description: spi chipselect number according to the usual spi bindings > diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml > b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml > index 8ffeceb6abae..95ab285f4eba 100644 > --- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml > @@ -38,10 +38,9 @@ properties: > >microchip,device-addr: > description: Device address when multiple MCP3911 chips are present on > the same SPI bus. > -allOf: > - - $ref: /schemas/types.yaml#/definitions/uint32 > - - enum: [0, 1, 2, 3] > - - default: 0 > +$ref: /schemas/types.yaml#/definitions/uint32 > +enum: [0, 1, 2, 3] > +default: 0 > >vref-supply: > description: | > diff --git > a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml > b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml > index b1627441a0b2..d69ca492d020 100644 > --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml > @@ -95,16 +95,14 @@ patternProperties: >On stm32h7 and stm32mp1: >- For st,stm32-dfsdm-adc: up to 8 channels numbered fr
Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting
On Wed, 15 Apr 2020 19:55:48 -0500 Rob Herring wrote: > Fix various inconsistencies in schema indentation. Most of these are > list indentation which should be 2 spaces more than the start of the > enclosing keyword. This doesn't matter functionally, but affects running > scripts which do transforms on the schema files. > > Signed-off-by: Rob Herring > --- ... > .../bindings/iio/adc/adi,ad7124.yaml | 4 +- > .../bindings/iio/adc/lltc,ltc2496.yaml| 6 +- Acked-by: Jonathan Cameron #for-iio > .../input/allwinner,sun4i-a10-lradc-keys.yaml | 4 +- > .../bindings/input/touchscreen/goodix.yaml| 2 +- > .../bindings/interconnect/qcom,msm8916.yaml | 4 +- > .../bindings/interconnect/qcom,msm8974.yaml | 4 +- > .../bindings/interconnect/qcom,qcs404.yaml| 4 +- > .../allwinner,sun7i-a20-sc-nmi.yaml | 12 ++-- > .../intel,ixp4xx-interrupt.yaml | 8 +-- > .../interrupt-controller/st,stm32-exti.yaml | 12 ++-- > .../bindings/iommu/samsung,sysmmu.yaml| 10 +-- > .../bindings/mailbox/st,stm32-ipcc.yaml | 2 +- > .../media/allwinner,sun4i-a10-csi.yaml| 28 > .../bindings/media/amlogic,gx-vdec.yaml | 14 ++-- > .../bindings/media/renesas,ceu.yaml | 28 > .../bindings/media/renesas,vin.yaml | 8 +-- > .../devicetree/bindings/media/ti,vpe.yaml | 2 +- > .../memory-controllers/fsl/imx8m-ddrc.yaml| 6 +- > .../bindings/mfd/st,stm32-lptimer.yaml| 4 +- > .../bindings/mfd/st,stm32-timers.yaml | 4 +- > .../devicetree/bindings/mfd/syscon.yaml | 12 ++-- > .../devicetree/bindings/mmc/cdns,sdhci.yaml | 2 +- > .../bindings/mmc/rockchip-dw-mshc.yaml| 16 ++--- > .../bindings/mmc/socionext,uniphier-sd.yaml | 14 ++-- > .../devicetree/bindings/mtd/denali,nand.yaml | 4 +- > .../net/allwinner,sun8i-a83t-emac.yaml| 4 +- > .../bindings/net/can/bosch,m_can.yaml | 52 +++ > .../bindings/net/renesas,ether.yaml | 4 +- > .../bindings/net/ti,cpsw-switch.yaml | 12 ++-- > .../bindings/net/ti,davinci-mdio.yaml | 27 > .../bindings/phy/intel,lgm-emmc-phy.yaml | 2 +- > .../devicetree/bindings/pwm/pwm-samsung.yaml | 16 ++--- > .../bindings/remoteproc/st,stm32-rproc.yaml | 2 +- > .../reset/brcm,bcm7216-pcie-sata-rescal.yaml | 4 +- > .../devicetree/bindings/rtc/st,stm32-rtc.yaml | 38 +-- > .../bindings/serial/amlogic,meson-uart.yaml | 16 ++--- > .../devicetree/bindings/serial/rs485.yaml | 17 ++--- > .../bindings/soc/amlogic/amlogic,canvas.yaml | 10 +-- > .../bindings/sound/renesas,fsi.yaml | 16 ++--- > .../bindings/spi/qcom,spi-qcom-qspi.yaml | 10 +-- > .../devicetree/bindings/spi/renesas,hspi.yaml | 4 +- > .../devicetree/bindings/spi/spi-pl022.yaml| 2 +- > .../bindings/spi/st,stm32-qspi.yaml | 4 +- > .../allwinner,sun4i-a10-system-control.yaml | 64 +-- > .../bindings/thermal/amlogic,thermal.yaml | 10 +-- > .../bindings/timer/arm,arch_timer.yaml| 4 +- > .../bindings/timer/arm,arch_timer_mmio.yaml | 4 +- > .../devicetree/bindings/usb/dwc2.yaml | 8 +-- > 77 files changed, 450 insertions(+), 450 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/altera.yaml > b/Documentation/devicetree/bindings/arm/altera.yaml > index 49e0362ddc11..b388c5aa7984 100644 > --- a/Documentation/devicetree/bindings/arm/altera.yaml > +++ b/Documentation/devicetree/bindings/arm/altera.yaml > @@ -13,8 +13,8 @@ properties: >compatible: > items: >- enum: > -- altr,socfpga-cyclone5 > -- altr,socfpga-arria5 > -- altr,socfpga-arria10 > + - altr,socfpga-cyclone5 > + - altr,socfpga-arria5 > + - altr,socfpga-arria10 >- const: altr,socfpga > ... > diff --git > a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > > b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > index 66213bd95e6e..6cc74523ebfd 100644 > --- > a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > +++ > b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > @@ -25,7 +25,7 @@ select: > > properties: >compatible: > - items: > +items: >- const: amlogic,meson-gx-ao-secure >- const: syscon > > diff --git a/Documentation/devicetree/bindings/arm/bitmain.yaml > b/Documentation/devicetree/bindings/arm/bitmain.yaml > index 0efdb4ac028e..5cd5b36cff2d 100644 > --- a/Documentation/devicetree/bindings/arm/bitmain.yaml > +++ b/Documentation/devicetree/bindings/arm/bitmain.yaml > @@ -13,6 +13,6 @@ properties: >compatible: > items: >- enum: > -- bitmain,sophon-edge > + - bitmain,sophon-edge >- const: bitmain,bm1880 > ... > diff --git a/Documentation/devicetree/bindings/arm/nxp/lpc32x
Re: [PATCH v2] of_device: removed #include that caused a recursion in included headers
On Thu, 16 Apr 2020 12:49:03 +0300 Hadar Gat wrote: > Both of_platform.h and of_device.h were included each other. > In of_device.h, removed unneeded #include to of_platform.h > and added include to of_platform.h in the files that needs it. > > Signed-off-by: Hadar Gat Hmm. I guess the chances of this causing merge problems are fairly low so perhaps not worth doing additions of headers via individual subsystems and actually dropping the header include after another cycle. So on that basis Acked-by: Jonathan Cameron #for-iio > --- > v2: add include to of_platform.h in more files. (reported due other builds) > > arch/sparc/mm/io-unit.c | 1 + > arch/sparc/mm/iommu.c | 1 + > drivers/base/platform.c | 1 + > drivers/bus/imx-weim.c| 1 + > drivers/bus/vexpress-config.c | 1 + > drivers/clk/mediatek/clk-mt7622-aud.c | 1 + > drivers/dma/at_hdmac.c| 1 + > drivers/dma/stm32-dmamux.c| 1 + > drivers/dma/ti/dma-crossbar.c | 1 + > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 + > drivers/gpu/drm/msm/hdmi/hdmi.c | 1 + > drivers/gpu/drm/msm/msm_drv.c | 1 + > drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1 + > drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 + > drivers/iio/adc/stm32-adc-core.c | 1 + > drivers/iio/adc/stm32-dfsdm-adc.c | 1 + > drivers/iio/adc/stm32-dfsdm-core.c| 1 + > drivers/iommu/tegra-smmu.c| 1 + > drivers/memory/atmel-ebi.c| 1 + > drivers/mfd/palmas.c | 1 + > drivers/mfd/ssbi.c| 1 + > drivers/mtd/nand/raw/omap2.c | 1 + > drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 1 + > drivers/net/ethernet/ti/cpsw.c| 1 + > drivers/phy/tegra/xusb.c | 1 + > drivers/pinctrl/freescale/pinctrl-imx1-core.c | 1 + > drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 + > drivers/soc/samsung/exynos-pmu.c | 1 + > drivers/soc/sunxi/sunxi_sram.c| 1 + > include/linux/of_device.h | 2 -- > lib/genalloc.c| 1 + > 31 files changed, 30 insertions(+), 2 deletions(-) > > diff --git a/arch/sparc/mm/io-unit.c b/arch/sparc/mm/io-unit.c > index 289276b..5638399 100644 > --- a/arch/sparc/mm/io-unit.c > +++ b/arch/sparc/mm/io-unit.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > > #include > #include > diff --git a/arch/sparc/mm/iommu.c b/arch/sparc/mm/iommu.c > index b00dde1..9cbb2e7 100644 > --- a/arch/sparc/mm/iommu.c > +++ b/arch/sparc/mm/iommu.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > > #include > #include > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > index 520..f549274b 100644 > --- a/drivers/base/platform.c > +++ b/drivers/base/platform.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c > index 28bb65a..8c786da 100644 > --- a/drivers/bus/imx-weim.c > +++ b/drivers/bus/imx-weim.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c > index ff70575..12b8b0b 100644 > --- a/drivers/bus/vexpress-config.c > +++ b/drivers/bus/vexpress-config.c > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > #include > > > diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c > b/drivers/clk/mediatek/clk-mt7622-aud.c > index 2bd4295..8cbb68f 100644 > --- a/drivers/clk/mediatek/clk-mt7622-aud.c > +++ b/drivers/clk/mediatek/clk-mt7622-aud.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > > #include "clk-mtk.h" > diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c > index 73a2078..388f8e10 100644 > --- a/drivers/dma/at_hdmac.c > +++ b/drivers/dma/at_hdmac.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > > #include "at_hdmac_regs.h" > diff --git a/drivers/dma/stm32-dmamux.c b/drivers/dma/stm32-dmamux.c > index 12f7637..b704896 100644 > --- a/drivers/dma/stm32-dmamux.c > +++ b/drivers/dma/stm32-dmamux.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/dma/ti/dma-crossbar.c b/drivers/dma/ti/dma-crossbar.c > index 4ba8fa5..2c0fd44 100644 > --- a/drivers/dma/ti/dma-crossbar.c > +++ b/drivers/dma/ti/dma-crossbar.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include >
Re: [PATCH trivial 4/6] iio: Fix misspellings of "Analog Devices"
On Thu, 16 Apr 2020 12:30:56 +0200
Geert Uytterhoeven wrote:
> According to https://www.analog.com/, the company name is spelled
> "Analog Devices".
>
> Signed-off-by: Geert Uytterhoeven
Applied to the togreg branch of iio.git and pushed out as testing as there
are other things in that tree that need a build test.
Thanks,
Jonathan
> ---
> drivers/iio/adc/ad7791.c | 2 +-
> drivers/iio/trigger/iio-trig-hrtimer.c | 2 +-
> drivers/staging/iio/Documentation/overview.txt | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/adc/ad7791.c b/drivers/iio/adc/ad7791.c
> index abb2393926317087..70bfc41052db2740 100644
> --- a/drivers/iio/adc/ad7791.c
> +++ b/drivers/iio/adc/ad7791.c
> @@ -444,5 +444,5 @@ static struct spi_driver ad7791_driver = {
> module_spi_driver(ad7791_driver);
>
> MODULE_AUTHOR("Lars-Peter Clausen ");
> -MODULE_DESCRIPTION("Analog Device AD7787/AD7788/AD7789/AD7790/AD7791 ADC
> driver");
> +MODULE_DESCRIPTION("Analog Devices AD7787/AD7788/AD7789/AD7790/AD7791 ADC
> driver");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c
> b/drivers/iio/trigger/iio-trig-hrtimer.c
> index a5e670726717f0d8..f59bf8d585866ea2 100644
> --- a/drivers/iio/trigger/iio-trig-hrtimer.c
> +++ b/drivers/iio/trigger/iio-trig-hrtimer.c
> @@ -4,7 +4,7 @@
> *
> * Copyright (C) Intuitive Aerial AB
> * Written by Marten Svanfeldt, mar...@intuitiveaerial.com
> - * Copyright (C) 2012, Analog Device Inc.
> + * Copyright (C) 2012, Analog Devices Inc.
> * Author: Lars-Peter Clausen
> * Copyright (C) 2015, Intel Corporation
> */
> diff --git a/drivers/staging/iio/Documentation/overview.txt
> b/drivers/staging/iio/Documentation/overview.txt
> index 43f92b06bc3e5574..ebdc64f451d7c798 100644
> --- a/drivers/staging/iio/Documentation/overview.txt
> +++ b/drivers/staging/iio/Documentation/overview.txt
> @@ -34,7 +34,7 @@ turned on or off (if possible) via sysfs interfaces.
> fifo / ring buffers on the sensor chip. These greatly reduce the load
> on the host CPU by buffering relatively large numbers of data samples
> based on an internal sampling clock. Examples include VTI SCA3000
> -series and Analog Device ADXL345 accelerometers. Each buffer supports
> +series and Analog Devices ADXL345 accelerometers. Each buffer supports
> polling to establish when data is available.
>
> * Trigger and software buffer support. In many data analysis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 17/28] drm/amdkfd: kfree the wrong pointer
From: Jack Zhang
[ Upstream commit 3148a6a0ef3cf93570f30a477292768f7eb5d3c3 ]
Originally, it kfrees the wrong pointer for mem_obj.
It would cause memory leak under stress test.
Signed-off-by: Jack Zhang
Acked-by: Nirmoy Das
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 61fff25b4ce7d..ecd4eba221c0a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -550,9 +550,9 @@ int kfd_gtt_sa_allocate(struct kfd_dev *kfd, unsigned int
size,
return 0;
kfd_gtt_no_free_chunk:
- pr_debug("Allocation failed with mem_obj = %p\n", mem_obj);
+ pr_debug("Allocation failed with mem_obj = %p\n", *mem_obj);
mutex_unlock(&kfd->gtt_sa_lock);
- kfree(mem_obj);
+ kfree(*mem_obj);
return -ENOMEM;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 40/47] drm/amd/display: Not doing optimize bandwidth if flip pending.
From: Yongqiang Sun
[ Upstream commit 9941b8129030c9202aaf39114477a0e58c0d6ffc ]
[Why]
In some scenario like 1366x768 VSR enabled connected with a 4K monitor
and playing 4K video in clone mode, underflow will be observed due to
decrease dppclk when previouse surface scan isn't finished
[How]
In this use case, surface flip is switching between 4K and 1366x768,
1366x768 needs smaller dppclk, and when decrease the clk and previous
surface scan is for 4K and scan isn't done, underflow will happen. Not
doing optimize bandwidth in case of flip pending.
Signed-off-by: Yongqiang Sun
Reviewed-by: Tony Cheng
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 2b2efe443c36d..b64ad9e1f0c38 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -996,6 +996,26 @@ bool dc_commit_state(struct dc *dc, struct dc_state
*context)
return (result == DC_OK);
}
+static bool is_flip_pending_in_pipes(struct dc *dc, struct dc_state *context)
+{
+ int i;
+ struct pipe_ctx *pipe;
+
+ for (i = 0; i < MAX_PIPES; i++) {
+ pipe = &context->res_ctx.pipe_ctx[i];
+
+ if (!pipe->plane_state)
+ continue;
+
+ /* Must set to false to start with, due to OR in update
function */
+ pipe->plane_state->status.is_flip_pending = false;
+ dc->hwss.update_pending_status(pipe);
+ if (pipe->plane_state->status.is_flip_pending)
+ return true;
+ }
+ return false;
+}
+
bool dc_post_update_surfaces_to_stream(struct dc *dc)
{
int i;
@@ -1003,6 +1023,9 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
post_surface_trace(dc);
+ if (is_flip_pending_in_pipes(dc, context))
+ return true;
+
for (i = 0; i < dc->res_pool->pipe_count; i++)
if (context->res_ctx.pipe_ctx[i].stream == NULL ||
context->res_ctx.pipe_ctx[i].plane_state == NULL) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 26/47] drm/vc4: Fix HDMI mode validation
From: Nicolas Saenz Julienne
[ Upstream commit b1e7396a1d0e6af6806337fdaaa44098d6b3343c ]
Current mode validation impedes setting up some video modes which should
be supported otherwise. Namely 1920x1200@60Hz.
Fix this by lowering the minimum HDMI state machine clock to pixel clock
ratio allowed.
Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks.")
Reported-by: Stefan Wahren
Suggested-by: Dave Stevenson
Signed-off-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20200326122001.22215-1-nsaenzjulie...@suse.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index fd5522fd179e5..86b98856756d9 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -698,11 +698,23 @@ static enum drm_mode_status
vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
const struct drm_display_mode *mode)
{
- /* HSM clock must be 108% of the pixel clock. Additionally,
-* the AXI clock needs to be at least 25% of pixel clock, but
-* HSM ends up being the limiting factor.
+ /*
+* As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
+* be faster than pixel clock, infinitesimally faster, tested in
+* simulation. Otherwise, exact value is unimportant for HDMI
+* operation." This conflicts with bcm2835's vc4 documentation, which
+* states HSM's clock has to be at least 108% of the pixel clock.
+*
+* Real life tests reveal that vc4's firmware statement holds up, and
+* users are able to use pixel clocks closer to HSM's, namely for
+* 1920x1200@60Hz. So it was decided to have leave a 1% margin between
+* both clocks. Which, for RPi0-3 implies a maximum pixel clock of
+* 162MHz.
+*
+* Additionally, the AXI clock needs to be at least 25% of
+* pixel clock, but HSM ends up being the limiting factor.
*/
- if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100))
+ if (mode->clock > HSM_CLOCK_FREQ / (1000 * 101 / 100))
return MODE_CLOCK_HIGH;
return MODE_OK;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 23/47] drm/amdkfd: kfree the wrong pointer
From: Jack Zhang
[ Upstream commit 3148a6a0ef3cf93570f30a477292768f7eb5d3c3 ]
Originally, it kfrees the wrong pointer for mem_obj.
It would cause memory leak under stress test.
Signed-off-by: Jack Zhang
Acked-by: Nirmoy Das
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 938d0053a8208..28022d1cb0f07 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -921,9 +921,9 @@ int kfd_gtt_sa_allocate(struct kfd_dev *kfd, unsigned int
size,
return 0;
kfd_gtt_no_free_chunk:
- pr_debug("Allocation failed with mem_obj = %p\n", mem_obj);
+ pr_debug("Allocation failed with mem_obj = %p\n", *mem_obj);
mutex_unlock(&kfd->gtt_sa_lock);
- kfree(mem_obj);
+ kfree(*mem_obj);
return -ENOMEM;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 41/78] drm/vc4: Fix HDMI mode validation
From: Nicolas Saenz Julienne
[ Upstream commit b1e7396a1d0e6af6806337fdaaa44098d6b3343c ]
Current mode validation impedes setting up some video modes which should
be supported otherwise. Namely 1920x1200@60Hz.
Fix this by lowering the minimum HDMI state machine clock to pixel clock
ratio allowed.
Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks.")
Reported-by: Stefan Wahren
Suggested-by: Dave Stevenson
Signed-off-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20200326122001.22215-1-nsaenzjulie...@suse.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 0853b980bcb31..d5f5ba4105241 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -681,11 +681,23 @@ static enum drm_mode_status
vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
const struct drm_display_mode *mode)
{
- /* HSM clock must be 108% of the pixel clock. Additionally,
-* the AXI clock needs to be at least 25% of pixel clock, but
-* HSM ends up being the limiting factor.
+ /*
+* As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
+* be faster than pixel clock, infinitesimally faster, tested in
+* simulation. Otherwise, exact value is unimportant for HDMI
+* operation." This conflicts with bcm2835's vc4 documentation, which
+* states HSM's clock has to be at least 108% of the pixel clock.
+*
+* Real life tests reveal that vc4's firmware statement holds up, and
+* users are able to use pixel clocks closer to HSM's, namely for
+* 1920x1200@60Hz. So it was decided to have leave a 1% margin between
+* both clocks. Which, for RPi0-3 implies a maximum pixel clock of
+* 162MHz.
+*
+* Additionally, the AXI clock needs to be at least 25% of
+* pixel clock, but HSM ends up being the limiting factor.
*/
- if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100))
+ if (mode->clock > HSM_CLOCK_FREQ / (1000 * 101 / 100))
return MODE_CLOCK_HIGH;
return MODE_OK;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 52/78] drm/amd/display: Calculate scaling ratios on every medium/full update
From: Nicholas Kazlauskas
[ Upstream commit 3bae20137cae6c03f58f96c0bc9f3d46f0bc17d4 ]
[Why]
If a plane isn't being actively enabled or disabled then DC won't
always recalculate scaling rects and ratios for the primary plane.
This results in only a partial or corrupted rect being displayed on
the screen instead of scaling to fit the screen.
[How]
Add back the logic to recalculate the scaling rects into
dc_commit_updates_for_stream since this is the expected place to
do it in DC.
This was previously removed a few years ago to fix an underscan issue
but underscan is still functional now with this change - and it should
be, since this is only updating to the latest plane state getting passed
in.
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Aric Cyr
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 89bd0ba3db1df..71c574d1e8be2 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2154,7 +2154,7 @@ void dc_commit_updates_for_stream(struct dc *dc,
enum surface_update_type update_type;
struct dc_state *context;
struct dc_context *dc_ctx = dc->ctx;
- int i;
+ int i, j;
stream_status = dc_stream_get_status(stream);
context = dc->current_state;
@@ -2192,6 +2192,17 @@ void dc_commit_updates_for_stream(struct dc *dc,
copy_surface_update_to_plane(surface, &srf_updates[i]);
+ if (update_type >= UPDATE_TYPE_MED) {
+ for (j = 0; j < dc->res_pool->pipe_count; j++) {
+ struct pipe_ctx *pipe_ctx =
+ &context->res_ctx.pipe_ctx[j];
+
+ if (pipe_ctx->plane_state != surface)
+ continue;
+
+ resource_build_scaling_params(pipe_ctx);
+ }
+ }
}
copy_stream_update_to_stream(dc, context, stream, stream_update);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 30/78] drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in demsg:
"nouveau :01:00.0: Refused to change power state, currently in D3"
"nouveau :01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.
It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2cd83849600f3..b1beed40e746a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
}
+/*
+ * On some Intel PCIe bridge controllers doing a
+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
+ * Skipping the intermediate D3hot step seems to make it work again. This is
+ * probably caused by not meeting the expectation the involved AML code has
+ * when the GPU is put into D3hot state before invoking it.
+ *
+ * This leads to various manifestations of this issue:
+ * - AML code execution to power on the GPU hits an infinite loop (as the
+ *code waits on device memory to change).
+ * - kernel crashes, as all PCI reads return -1, which most code isn't able
+ *to handle well enough.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
+ * documented PCI config space register 0x248 of the Intel PCIe bridge
+ * controller (0x1901) in order to change the state of the PCIe link between
+ * the PCIe port and the GPU. There are alternative code paths using other
+ * registers, which seem to work fine (executed pre Windows 8):
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether
+ * this issue only occurs in combination with listed Intel PCIe bridge
+ * controllers and the mentioned GPUs or other devices as well.
+ *
+ * documentation on the PCIe bridge controller can be found in the
+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume
2"
+ * Section "12 PCI Express* Controller (x16) Registers"
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct pci_dev *bridge = pci_upstream_bridge(pdev);
+
+ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+ return;
+
+ switch (bridge->device) {
+ case 0x1901:
+ drm->old_pm_cap = pdev->pm_cap;
+ pdev->pm_cap = 0;
+ NV_INFO(drm, "Disabling PCI power management to avoid bug\n");
+ break;
+ }
+}
+
static int nouveau_drm_probe(struct pci_dev *pdev,
const struct pci_device_id *pent)
{
@@ -699,6 +757,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
+ quirk_broken_nv_runpm(pdev);
return 0;
fail_drm_dev_init:
@@ -736,7 +795,11 @@ static void
nouveau_drm_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ /* revert our workaround */
+ if (drm->old_pm_cap)
+ pdev->pm_cap = drm->old_pm_cap;
nouveau_drm_device_remove(dev);
}
diff --git a/drive
[PATCH AUTOSEL 5.4 64/78] drm/amd/display: Not doing optimize bandwidth if flip pending.
From: Yongqiang Sun
[ Upstream commit 9941b8129030c9202aaf39114477a0e58c0d6ffc ]
[Why]
In some scenario like 1366x768 VSR enabled connected with a 4K monitor
and playing 4K video in clone mode, underflow will be observed due to
decrease dppclk when previouse surface scan isn't finished
[How]
In this use case, surface flip is switching between 4K and 1366x768,
1366x768 needs smaller dppclk, and when decrease the clk and previous
surface scan is for 4K and scan isn't done, underflow will happen. Not
doing optimize bandwidth in case of flip pending.
Signed-off-by: Yongqiang Sun
Reviewed-by: Tony Cheng
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 71c574d1e8be2..2028dc017f7a0 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1182,6 +1182,26 @@ bool dc_commit_state(struct dc *dc, struct dc_state
*context)
return (result == DC_OK);
}
+static bool is_flip_pending_in_pipes(struct dc *dc, struct dc_state *context)
+{
+ int i;
+ struct pipe_ctx *pipe;
+
+ for (i = 0; i < MAX_PIPES; i++) {
+ pipe = &context->res_ctx.pipe_ctx[i];
+
+ if (!pipe->plane_state)
+ continue;
+
+ /* Must set to false to start with, due to OR in update
function */
+ pipe->plane_state->status.is_flip_pending = false;
+ dc->hwss.update_pending_status(pipe);
+ if (pipe->plane_state->status.is_flip_pending)
+ return true;
+ }
+ return false;
+}
+
bool dc_post_update_surfaces_to_stream(struct dc *dc)
{
int i;
@@ -1192,6 +1212,9 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
post_surface_trace(dc);
+ if (is_flip_pending_in_pipes(dc, context))
+ return true;
+
for (i = 0; i < dc->res_pool->pipe_count; i++)
if (context->res_ctx.pipe_ctx[i].stream == NULL ||
context->res_ctx.pipe_ctx[i].plane_state == NULL) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 37/78] drm/amdkfd: kfree the wrong pointer
From: Jack Zhang
[ Upstream commit 3148a6a0ef3cf93570f30a477292768f7eb5d3c3 ]
Originally, it kfrees the wrong pointer for mem_obj.
It would cause memory leak under stress test.
Signed-off-by: Jack Zhang
Acked-by: Nirmoy Das
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 0dc1084b5e829..ad9483b9eea32 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -1112,9 +1112,9 @@ int kfd_gtt_sa_allocate(struct kfd_dev *kfd, unsigned int
size,
return 0;
kfd_gtt_no_free_chunk:
- pr_debug("Allocation failed with mem_obj = %p\n", mem_obj);
+ pr_debug("Allocation failed with mem_obj = %p\n", *mem_obj);
mutex_unlock(&kfd->gtt_sa_lock);
- kfree(mem_obj);
+ kfree(*mem_obj);
return -ENOMEM;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 21/78] drm/amd/display: Update stream adjust in dc_stream_adjust_vmin_vmax
From: Isabel Zhang
[ Upstream commit 346d8a0a3c91888a412c2735d69daa09c00f0203 ]
[Why]
After v_total_min and max are updated in vrr structure, the changes are
not reflected in stream adjust. When these values are read from stream
adjust it does not reflect the actual state of the system.
[How]
Set stream adjust values equal to vrr adjust values after vrr adjust
values are updated.
Signed-off-by: Isabel Zhang
Reviewed-by: Alvin Lee
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 4704aac336c29..89bd0ba3db1df 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -283,6 +283,8 @@ bool dc_stream_adjust_vmin_vmax(struct dc *dc,
int i = 0;
bool ret = false;
+ stream->adjust = *adjust;
+
for (i = 0; i < MAX_PIPES; i++) {
struct pipe_ctx *pipe = &dc->current_state->res_ctx.pipe_ctx[i];
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 69/75] drm/amd/display: Not doing optimize bandwidth if flip pending.
From: Yongqiang Sun
[ Upstream commit 9941b8129030c9202aaf39114477a0e58c0d6ffc ]
[Why]
In some scenario like 1366x768 VSR enabled connected with a 4K monitor
and playing 4K video in clone mode, underflow will be observed due to
decrease dppclk when previouse surface scan isn't finished
[How]
In this use case, surface flip is switching between 4K and 1366x768,
1366x768 needs smaller dppclk, and when decrease the clk and previous
surface scan is for 4K and scan isn't done, underflow will happen. Not
doing optimize bandwidth in case of flip pending.
Signed-off-by: Yongqiang Sun
Reviewed-by: Tony Cheng
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index d25e0a937bf57..870e3903f02b9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1281,6 +1281,26 @@ bool dc_commit_state(struct dc *dc, struct dc_state
*context)
return (result == DC_OK);
}
+static bool is_flip_pending_in_pipes(struct dc *dc, struct dc_state *context)
+{
+ int i;
+ struct pipe_ctx *pipe;
+
+ for (i = 0; i < MAX_PIPES; i++) {
+ pipe = &context->res_ctx.pipe_ctx[i];
+
+ if (!pipe->plane_state)
+ continue;
+
+ /* Must set to false to start with, due to OR in update
function */
+ pipe->plane_state->status.is_flip_pending = false;
+ dc->hwss.update_pending_status(pipe);
+ if (pipe->plane_state->status.is_flip_pending)
+ return true;
+ }
+ return false;
+}
+
bool dc_post_update_surfaces_to_stream(struct dc *dc)
{
int i;
@@ -1291,6 +1311,9 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
post_surface_trace(dc);
+ if (is_flip_pending_in_pipes(dc, context))
+ return true;
+
for (i = 0; i < dc->res_pool->pipe_count; i++)
if (context->res_ctx.pipe_ctx[i].stream == NULL ||
context->res_ctx.pipe_ctx[i].plane_state == NULL) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 57/75] drm/amd/display: Calculate scaling ratios on every medium/full update
From: Nicholas Kazlauskas
[ Upstream commit 3bae20137cae6c03f58f96c0bc9f3d46f0bc17d4 ]
[Why]
If a plane isn't being actively enabled or disabled then DC won't
always recalculate scaling rects and ratios for the primary plane.
This results in only a partial or corrupted rect being displayed on
the screen instead of scaling to fit the screen.
[How]
Add back the logic to recalculate the scaling rects into
dc_commit_updates_for_stream since this is the expected place to
do it in DC.
This was previously removed a few years ago to fix an underscan issue
but underscan is still functional now with this change - and it should
be, since this is only updating to the latest plane state getting passed
in.
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Aric Cyr
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 7fdbb47e8c259..d25e0a937bf57 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2283,7 +2283,7 @@ void dc_commit_updates_for_stream(struct dc *dc,
enum surface_update_type update_type;
struct dc_state *context;
struct dc_context *dc_ctx = dc->ctx;
- int i;
+ int i, j;
stream_status = dc_stream_get_status(stream);
context = dc->current_state;
@@ -2321,6 +2321,17 @@ void dc_commit_updates_for_stream(struct dc *dc,
copy_surface_update_to_plane(surface, &srf_updates[i]);
+ if (update_type >= UPDATE_TYPE_MED) {
+ for (j = 0; j < dc->res_pool->pipe_count; j++) {
+ struct pipe_ctx *pipe_ctx =
+ &context->res_ctx.pipe_ctx[j];
+
+ if (pipe_ctx->plane_state != surface)
+ continue;
+
+ resource_build_scaling_params(pipe_ctx);
+ }
+ }
}
copy_stream_update_to_stream(dc, context, stream, stream_update);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 22/75] drm/amd/display: Update stream adjust in dc_stream_adjust_vmin_vmax
From: Isabel Zhang
[ Upstream commit 346d8a0a3c91888a412c2735d69daa09c00f0203 ]
[Why]
After v_total_min and max are updated in vrr structure, the changes are
not reflected in stream adjust. When these values are read from stream
adjust it does not reflect the actual state of the system.
[How]
Set stream adjust values equal to vrr adjust values after vrr adjust
values are updated.
Signed-off-by: Isabel Zhang
Reviewed-by: Alvin Lee
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 8904a85186aab..7fdbb47e8c259 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -283,6 +283,8 @@ bool dc_stream_adjust_vmin_vmax(struct dc *dc,
int i = 0;
bool ret = false;
+ stream->adjust = *adjust;
+
for (i = 0; i < MAX_PIPES; i++) {
struct pipe_ctx *pipe = &dc->current_state->res_ctx.pipe_ctx[i];
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 39/75] drm/amdkfd: kfree the wrong pointer
From: Jack Zhang
[ Upstream commit 3148a6a0ef3cf93570f30a477292768f7eb5d3c3 ]
Originally, it kfrees the wrong pointer for mem_obj.
It would cause memory leak under stress test.
Signed-off-by: Jack Zhang
Acked-by: Nirmoy Das
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 4fa8834ce7cb0..fb22a58ce99b5 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -1086,9 +1086,9 @@ int kfd_gtt_sa_allocate(struct kfd_dev *kfd, unsigned int
size,
return 0;
kfd_gtt_no_free_chunk:
- pr_debug("Allocation failed with mem_obj = %p\n", mem_obj);
+ pr_debug("Allocation failed with mem_obj = %p\n", *mem_obj);
mutex_unlock(&kfd->gtt_sa_lock);
- kfree(mem_obj);
+ kfree(*mem_obj);
return -ENOMEM;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 32/75] drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in demsg:
"nouveau :01:00.0: Refused to change power state, currently in D3"
"nouveau :01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.
It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2cd83849600f3..b1beed40e746a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
}
+/*
+ * On some Intel PCIe bridge controllers doing a
+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
+ * Skipping the intermediate D3hot step seems to make it work again. This is
+ * probably caused by not meeting the expectation the involved AML code has
+ * when the GPU is put into D3hot state before invoking it.
+ *
+ * This leads to various manifestations of this issue:
+ * - AML code execution to power on the GPU hits an infinite loop (as the
+ *code waits on device memory to change).
+ * - kernel crashes, as all PCI reads return -1, which most code isn't able
+ *to handle well enough.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
+ * documented PCI config space register 0x248 of the Intel PCIe bridge
+ * controller (0x1901) in order to change the state of the PCIe link between
+ * the PCIe port and the GPU. There are alternative code paths using other
+ * registers, which seem to work fine (executed pre Windows 8):
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether
+ * this issue only occurs in combination with listed Intel PCIe bridge
+ * controllers and the mentioned GPUs or other devices as well.
+ *
+ * documentation on the PCIe bridge controller can be found in the
+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume
2"
+ * Section "12 PCI Express* Controller (x16) Registers"
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct pci_dev *bridge = pci_upstream_bridge(pdev);
+
+ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+ return;
+
+ switch (bridge->device) {
+ case 0x1901:
+ drm->old_pm_cap = pdev->pm_cap;
+ pdev->pm_cap = 0;
+ NV_INFO(drm, "Disabling PCI power management to avoid bug\n");
+ break;
+ }
+}
+
static int nouveau_drm_probe(struct pci_dev *pdev,
const struct pci_device_id *pent)
{
@@ -699,6 +757,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
+ quirk_broken_nv_runpm(pdev);
return 0;
fail_drm_dev_init:
@@ -736,7 +795,11 @@ static void
nouveau_drm_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ /* revert our workaround */
+ if (drm->old_pm_cap)
+ pdev->pm_cap = drm->old_pm_cap;
nouveau_drm_device_remove(dev);
}
diff --git a/drive
[PATCH AUTOSEL 5.5 44/75] drm/vc4: Fix HDMI mode validation
From: Nicolas Saenz Julienne
[ Upstream commit b1e7396a1d0e6af6806337fdaaa44098d6b3343c ]
Current mode validation impedes setting up some video modes which should
be supported otherwise. Namely 1920x1200@60Hz.
Fix this by lowering the minimum HDMI state machine clock to pixel clock
ratio allowed.
Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks.")
Reported-by: Stefan Wahren
Suggested-by: Dave Stevenson
Signed-off-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20200326122001.22215-1-nsaenzjulie...@suse.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 1c62c6c9244b7..568953898ce6b 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -678,11 +678,23 @@ static enum drm_mode_status
vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
const struct drm_display_mode *mode)
{
- /* HSM clock must be 108% of the pixel clock. Additionally,
-* the AXI clock needs to be at least 25% of pixel clock, but
-* HSM ends up being the limiting factor.
+ /*
+* As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
+* be faster than pixel clock, infinitesimally faster, tested in
+* simulation. Otherwise, exact value is unimportant for HDMI
+* operation." This conflicts with bcm2835's vc4 documentation, which
+* states HSM's clock has to be at least 108% of the pixel clock.
+*
+* Real life tests reveal that vc4's firmware statement holds up, and
+* users are able to use pixel clocks closer to HSM's, namely for
+* 1920x1200@60Hz. So it was decided to have leave a 1% margin between
+* both clocks. Which, for RPi0-3 implies a maximum pixel clock of
+* 162MHz.
+*
+* Additionally, the AXI clock needs to be at least 25% of
+* pixel clock, but HSM ends up being the limiting factor.
*/
- if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100))
+ if (mode->clock > HSM_CLOCK_FREQ / (1000 * 101 / 100))
return MODE_CLOCK_HIGH;
return MODE_OK;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.6 61/73] drm/amd/display: Calculate scaling ratios on every medium/full update
From: Nicholas Kazlauskas
[ Upstream commit 3bae20137cae6c03f58f96c0bc9f3d46f0bc17d4 ]
[Why]
If a plane isn't being actively enabled or disabled then DC won't
always recalculate scaling rects and ratios for the primary plane.
This results in only a partial or corrupted rect being displayed on
the screen instead of scaling to fit the screen.
[How]
Add back the logic to recalculate the scaling rects into
dc_commit_updates_for_stream since this is the expected place to
do it in DC.
This was previously removed a few years ago to fix an underscan issue
but underscan is still functional now with this change - and it should
be, since this is only updating to the latest plane state getting passed
in.
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Aric Cyr
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index fc25600107050..188e51600070b 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2349,7 +2349,7 @@ void dc_commit_updates_for_stream(struct dc *dc,
enum surface_update_type update_type;
struct dc_state *context;
struct dc_context *dc_ctx = dc->ctx;
- int i;
+ int i, j;
stream_status = dc_stream_get_status(stream);
context = dc->current_state;
@@ -2387,6 +2387,17 @@ void dc_commit_updates_for_stream(struct dc *dc,
copy_surface_update_to_plane(surface, &srf_updates[i]);
+ if (update_type >= UPDATE_TYPE_MED) {
+ for (j = 0; j < dc->res_pool->pipe_count; j++) {
+ struct pipe_ctx *pipe_ctx =
+ &context->res_ctx.pipe_ctx[j];
+
+ if (pipe_ctx->plane_state != surface)
+ continue;
+
+ resource_build_scaling_params(pipe_ctx);
+ }
+ }
}
copy_stream_update_to_stream(dc, context, stream, stream_update);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.6 47/73] drm/vc4: Fix HDMI mode validation
From: Nicolas Saenz Julienne
[ Upstream commit b1e7396a1d0e6af6806337fdaaa44098d6b3343c ]
Current mode validation impedes setting up some video modes which should
be supported otherwise. Namely 1920x1200@60Hz.
Fix this by lowering the minimum HDMI state machine clock to pixel clock
ratio allowed.
Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks.")
Reported-by: Stefan Wahren
Suggested-by: Dave Stevenson
Signed-off-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20200326122001.22215-1-nsaenzjulie...@suse.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index cea18dc15f77c..340719238753d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -681,11 +681,23 @@ static enum drm_mode_status
vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
const struct drm_display_mode *mode)
{
- /* HSM clock must be 108% of the pixel clock. Additionally,
-* the AXI clock needs to be at least 25% of pixel clock, but
-* HSM ends up being the limiting factor.
+ /*
+* As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
+* be faster than pixel clock, infinitesimally faster, tested in
+* simulation. Otherwise, exact value is unimportant for HDMI
+* operation." This conflicts with bcm2835's vc4 documentation, which
+* states HSM's clock has to be at least 108% of the pixel clock.
+*
+* Real life tests reveal that vc4's firmware statement holds up, and
+* users are able to use pixel clocks closer to HSM's, namely for
+* 1920x1200@60Hz. So it was decided to have leave a 1% margin between
+* both clocks. Which, for RPi0-3 implies a maximum pixel clock of
+* 162MHz.
+*
+* Additionally, the AXI clock needs to be at least 25% of
+* pixel clock, but HSM ends up being the limiting factor.
*/
- if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100))
+ if (mode->clock > HSM_CLOCK_FREQ / (1000 * 101 / 100))
return MODE_CLOCK_HIGH;
return MODE_OK;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.6 34/73] drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in demsg:
"nouveau :01:00.0: Refused to change power state, currently in D3"
"nouveau :01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.
It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b65ae817eabf5..2d4c899e1f8b9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
}
+/*
+ * On some Intel PCIe bridge controllers doing a
+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
+ * Skipping the intermediate D3hot step seems to make it work again. This is
+ * probably caused by not meeting the expectation the involved AML code has
+ * when the GPU is put into D3hot state before invoking it.
+ *
+ * This leads to various manifestations of this issue:
+ * - AML code execution to power on the GPU hits an infinite loop (as the
+ *code waits on device memory to change).
+ * - kernel crashes, as all PCI reads return -1, which most code isn't able
+ *to handle well enough.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
+ * documented PCI config space register 0x248 of the Intel PCIe bridge
+ * controller (0x1901) in order to change the state of the PCIe link between
+ * the PCIe port and the GPU. There are alternative code paths using other
+ * registers, which seem to work fine (executed pre Windows 8):
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether
+ * this issue only occurs in combination with listed Intel PCIe bridge
+ * controllers and the mentioned GPUs or other devices as well.
+ *
+ * documentation on the PCIe bridge controller can be found in the
+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume
2"
+ * Section "12 PCI Express* Controller (x16) Registers"
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct pci_dev *bridge = pci_upstream_bridge(pdev);
+
+ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+ return;
+
+ switch (bridge->device) {
+ case 0x1901:
+ drm->old_pm_cap = pdev->pm_cap;
+ pdev->pm_cap = 0;
+ NV_INFO(drm, "Disabling PCI power management to avoid bug\n");
+ break;
+ }
+}
+
static int nouveau_drm_probe(struct pci_dev *pdev,
const struct pci_device_id *pent)
{
@@ -699,6 +757,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
+ quirk_broken_nv_runpm(pdev);
return 0;
fail_drm_dev_init:
@@ -734,7 +793,11 @@ static void
nouveau_drm_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ /* revert our workaround */
+ if (drm->old_pm_cap)
+ pdev->pm_cap = drm->old_pm_cap;
nouveau_drm_device_remove(dev);
pci_disable_dev
[PATCH AUTOSEL 5.6 41/73] drm/amdkfd: kfree the wrong pointer
From: Jack Zhang
[ Upstream commit 3148a6a0ef3cf93570f30a477292768f7eb5d3c3 ]
Originally, it kfrees the wrong pointer for mem_obj.
It would cause memory leak under stress test.
Signed-off-by: Jack Zhang
Acked-by: Nirmoy Das
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 2a9e401317353..0d70cb2248fe9 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -1104,9 +1104,9 @@ int kfd_gtt_sa_allocate(struct kfd_dev *kfd, unsigned int
size,
return 0;
kfd_gtt_no_free_chunk:
- pr_debug("Allocation failed with mem_obj = %p\n", mem_obj);
+ pr_debug("Allocation failed with mem_obj = %p\n", *mem_obj);
mutex_unlock(&kfd->gtt_sa_lock);
- kfree(mem_obj);
+ kfree(*mem_obj);
return -ENOMEM;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.6 24/73] drm/amd/display: Update stream adjust in dc_stream_adjust_vmin_vmax
From: Isabel Zhang
[ Upstream commit 346d8a0a3c91888a412c2735d69daa09c00f0203 ]
[Why]
After v_total_min and max are updated in vrr structure, the changes are
not reflected in stream adjust. When these values are read from stream
adjust it does not reflect the actual state of the system.
[How]
Set stream adjust values equal to vrr adjust values after vrr adjust
values are updated.
Signed-off-by: Isabel Zhang
Reviewed-by: Alvin Lee
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 04441dbcba76f..fc25600107050 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -283,6 +283,8 @@ bool dc_stream_adjust_vmin_vmax(struct dc *dc,
int i = 0;
bool ret = false;
+ stream->adjust = *adjust;
+
for (i = 0; i < MAX_PIPES; i++) {
struct pipe_ctx *pipe = &dc->current_state->res_ctx.pipe_ctx[i];
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #6 from Cyrax (ev...@hotmail.com) --- Created attachment 288595 --> https://bugzilla.kernel.org/attachment.cgi?id=288595&action=edit dmesg output And another one. It seems that switching between virtual consoles causes this bug to happen -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 Cyrax (ev...@hotmail.com) changed: What|Removed |Added Kernel Version|5.5.13 |5.6.4 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207331] commit "drm/amdgpu: fix gfx hang during suspend with video playback" breaks reboot/shutdown
https://bugzilla.kernel.org/show_bug.cgi?id=207331 --- Comment #3 from Grzegorz Kowal (custos.men...@gmail.com) --- Thanks! I applied the patch and the problem is gone. Both reboot and shutdown work again. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BUG: kernel NULL pointer dereference, address: 0000000000000026 after switching to 5.7 kernel
On Sat, 11 Apr 2020 at 14:56, Christian König wrote: > > Yeah, that is a known issue. > > You could try the attached patch, but please be aware that it is not > even compile tested because of the Easter holidays here. > Looks good to me, so it's pity that this patch did not exist in the pull request https://patchwork.kernel.org/patch/11492083/ -- Best Regards, Mike Gavrilov. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] fbdev: w100fb: clean up mach-pxa compile-time dependency
On Sat, Apr 18, 2020 at 12:11 PM Robert Jarzmik wrote: > > Arnd Bergmann writes: > > Hi Arnd, > > > diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig > > index f60bc29aef68..8444d40df1b3 100644 > > --- a/arch/arm/mach-pxa/Kconfig > > +++ b/arch/arm/mach-pxa/Kconfig > > @@ -549,9 +549,6 @@ config MACH_ICONTROL > > > > config ARCH_PXA_ESERIES > > bool "PXA based Toshiba e-series PDAs" > > - select FB_W100 > > - select FB > > - select PXA25x > This last line puzzles me a bit in this patch. Why removing the PXA25x select > ? It's a mistake, fixed now. Thanks for taking a look! Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] amdgpu_connector_set_property, fix error branch not return errno
The "if(!encoder)" branch return the same value 0 of the success branch, maybe return -EINVAL is more better. Signed-off-by: Bernard Zhao w --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c index f355d9a..1f8c6b4 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c @@ -474,12 +474,12 @@ static int amdgpu_connector_set_property(struct drm_connector *connector, /* need to find digital encoder on connector */ encoder = amdgpu_connector_find_encoder(connector, DRM_MODE_ENCODER_TMDS); if (!encoder) - return 0; + return -EINVAL; amdgpu_encoder = to_amdgpu_encoder(encoder); if (!amdgpu_encoder->enc_priv) - return 0; + return -EINVAL; dig = amdgpu_encoder->enc_priv; new_coherent_mode = val ? true : false; @@ -494,7 +494,7 @@ static int amdgpu_connector_set_property(struct drm_connector *connector, /* need to find digital encoder on connector */ encoder = amdgpu_connector_find_encoder(connector, DRM_MODE_ENCODER_TMDS); if (!encoder) - return 0; + return -EINVAL; amdgpu_encoder = to_amdgpu_encoder(encoder); @@ -509,7 +509,7 @@ static int amdgpu_connector_set_property(struct drm_connector *connector, /* need to find digital encoder on connector */ encoder = amdgpu_connector_find_encoder(connector, DRM_MODE_ENCODER_TMDS); if (!encoder) - return 0; + return -EINVAL; amdgpu_encoder = to_amdgpu_encoder(encoder); @@ -523,7 +523,7 @@ static int amdgpu_connector_set_property(struct drm_connector *connector, /* need to find digital encoder on connector */ encoder = amdgpu_connector_find_encoder(connector, DRM_MODE_ENCODER_TMDS); if (!encoder) - return 0; + return -EINVAL; amdgpu_encoder = to_amdgpu_encoder(encoder); @@ -537,7 +537,7 @@ static int amdgpu_connector_set_property(struct drm_connector *connector, /* need to find digital encoder on connector */ encoder = amdgpu_connector_find_encoder(connector, DRM_MODE_ENCODER_TMDS); if (!encoder) - return 0; + return -EINVAL; amdgpu_encoder = to_amdgpu_encoder(encoder); @@ -551,7 +551,7 @@ static int amdgpu_connector_set_property(struct drm_connector *connector, /* need to find digital encoder on connector */ encoder = amdgpu_connector_find_encoder(connector, DRM_MODE_ENCODER_TMDS); if (!encoder) - return 0; + return -EINVAL; amdgpu_encoder = to_amdgpu_encoder(encoder); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: Omit superfluous error message in etnaviv_gpu_platform_probe()
In the function etnaviv_gpu_platform_probe(), when get irq failed,
the function platform_get_irq() logs an error message, so remove
redundant message here.
Signed-off-by: Tang Bin
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index a31eeff2b..6dbe0c45b 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1770,10 +1770,8 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
/* Get Interrupt: */
gpu->irq = platform_get_irq(pdev, 0);
- if (gpu->irq < 0) {
- dev_err(dev, "failed to get irq: %d\n", gpu->irq);
+ if (gpu->irq < 0)
return gpu->irq;
- }
err = devm_request_irq(&pdev->dev, gpu->irq, irq_handler, 0,
dev_name(gpu->dev), gpu);
--
2.20.1.windows.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver
Convert mtk_dsi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v3:
- Add the bridge.type. (Laurent Pinchart)
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 93 ++
1 file changed, 69 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 37b8d7ffd835..869ae0a2e9f8 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -180,6 +180,7 @@ struct mtk_dsi {
struct device *dev;
struct mipi_dsi_host host;
struct drm_encoder encoder;
+ struct drm_bridge bridge;
struct drm_connector conn;
struct drm_panel *panel;
struct drm_bridge *next_bridge;
@@ -205,9 +206,9 @@ struct mtk_dsi {
const struct mtk_dsi_driver_data *driver_data;
};
-static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
+static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
{
- return container_of(e, struct mtk_dsi, encoder);
+ return container_of(b, struct mtk_dsi, bridge);
}
static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
@@ -796,32 +797,43 @@ static const struct drm_encoder_funcs
mtk_dsi_encoder_funcs = {
.destroy = mtk_dsi_encoder_destroy,
};
-static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
*dsi);
+static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
+
+static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+ return mtk_dsi_create_conn_enc(bridge->dev, dsi);
+}
+
+static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
{
- return true;
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+ mtk_dsi_destroy_conn_enc(dsi);
}
-static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted)
+static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ const struct drm_display_mode *adjusted)
{
- struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
drm_display_mode_to_videomode(adjusted, &dsi->vm);
}
-static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
{
- struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
mtk_output_dsi_disable(dsi);
}
-static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
{
- struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
mtk_output_dsi_enable(dsi);
}
@@ -833,11 +845,12 @@ static int mtk_dsi_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(dsi->panel, connector);
}
-static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
- .mode_fixup = mtk_dsi_encoder_mode_fixup,
- .mode_set = mtk_dsi_encoder_mode_set,
- .disable = mtk_dsi_encoder_disable,
- .enable = mtk_dsi_encoder_enable,
+static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
+ .attach = mtk_dsi_bridge_attach,
+ .detach = mtk_dsi_bridge_detach,
+ .disable = mtk_dsi_bridge_disable,
+ .enable = mtk_dsi_bridge_enable,
+ .mode_set = mtk_dsi_bridge_mode_set,
};
static const struct drm_connector_funcs mtk_dsi_connector_funcs = {
@@ -1123,6 +1136,34 @@ static const struct mipi_dsi_host_ops mtk_dsi_ops = {
.transfer = mtk_dsi_host_transfer,
};
+static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
+{
+ int ret;
+
+ ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
+ DRM_MODE_ENCODER_DSI, NULL);
+ if (ret) {
+ DRM_ERROR("Failed to encoder init to drm\n");
+ return ret;
+ }
+
+ /*
+* Currently display data paths are statically assigned to a crtc each.
+* crtc 0 is OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0
+*/
+ dsi->encoder.possible_crtcs = 1;
+
+ ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
+ if (ret)
+ goto err_cleanup_encoder;
+
+ return
[PATCH v4 1/3] drm/tegra: output: Don't leak OF node on error
The OF node should be put before returning error in tegra_output_probe(),
otherwise node's refcount will be leaked.
Reviewed-by: Laurent Pinchart
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/output.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index e36e5e7c2f69..a6a711d54e88 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -102,10 +102,10 @@ int tegra_output_probe(struct tegra_output *output)
panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
if (panel) {
output->panel = of_drm_find_panel(panel);
+ of_node_put(panel);
+
if (IS_ERR(output->panel))
return PTR_ERR(output->panel);
-
- of_node_put(panel);
}
output->edid = of_get_property(output->of_node, "nvidia,edid", &size);
@@ -113,13 +113,12 @@ int tegra_output_probe(struct tegra_output *output)
ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
if (ddc) {
output->ddc = of_find_i2c_adapter_by_node(ddc);
+ of_node_put(ddc);
+
if (!output->ddc) {
err = -EPROBE_DEFER;
- of_node_put(ddc);
return err;
}
-
- of_node_put(ddc);
}
output->hpd_gpio = devm_gpiod_get_from_of_node(output->dev,
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
Newer Tegra device-trees will specify a video output graph, which involves
LVDS encoder bridge. This patch adds support for the LVDS encoder bridge
to the RGB output, allowing us to model the display hardware properly.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/rgb.c | 58 +++--
1 file changed, 49 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index 0562a7eb793f..f28a226914c0 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
@@ -267,24 +268,63 @@ int tegra_dc_rgb_remove(struct tegra_dc *dc)
int tegra_dc_rgb_init(struct drm_device *drm, struct tegra_dc *dc)
{
struct tegra_output *output = dc->rgb;
+ struct drm_connector *connector;
int err;
if (!dc->rgb)
return -ENODEV;
- drm_connector_init(drm, &output->connector, &tegra_rgb_connector_funcs,
- DRM_MODE_CONNECTOR_LVDS);
- drm_connector_helper_add(&output->connector,
-&tegra_rgb_connector_helper_funcs);
- output->connector.dpms = DRM_MODE_DPMS_OFF;
-
drm_simple_encoder_init(drm, &output->encoder, DRM_MODE_ENCODER_LVDS);
drm_encoder_helper_add(&output->encoder,
&tegra_rgb_encoder_helper_funcs);
- drm_connector_attach_encoder(&output->connector,
- &output->encoder);
- drm_connector_register(&output->connector);
+ /*
+* Tegra devices that have LVDS panel utilize LVDS encoder bridge
+* for converting up to 28 LCD LVTTL lanes into 5/4 LVDS lanes that
+* go to display panel's receiver.
+*
+* Encoder usually have a power-down control which needs to be enabled
+* in order to transmit data to the panel. Historically devices that
+* use an older device-tree version didn't model the bridge, assuming
+* that encoder is turned ON by default, while today's DRM allows us
+* to model LVDS encoder properly.
+*
+* Newer device-trees utilize LVDS encoder bridge, which provides
+* us with a connector and handles the display panel.
+*
+* For older device-trees we fall back to our own connector and use
+* nvidia,panel phandle.
+*/
+ if (output->bridge) {
+ err = drm_bridge_attach(&output->encoder, output->bridge,
+ NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+ if (err) {
+ dev_err(output->dev, "failed to attach bridge: %d\n",
+ err);
+ return err;
+ }
+
+ connector = drm_bridge_connector_init(drm, &output->encoder);
+ if (IS_ERR(connector)) {
+ dev_err(output->dev,
+ "failed to initialize bridge connector: %pe\n",
+ connector);
+ return PTR_ERR(connector);
+ }
+
+ drm_connector_attach_encoder(connector, &output->encoder);
+ } else {
+ drm_connector_init(drm, &output->connector,
+ &tegra_rgb_connector_funcs,
+ DRM_MODE_CONNECTOR_LVDS);
+ drm_connector_helper_add(&output->connector,
+&tegra_rgb_connector_helper_funcs);
+ output->connector.dpms = DRM_MODE_DPMS_OFF;
+
+ drm_connector_attach_encoder(&output->connector,
+&output->encoder);
+ drm_connector_register(&output->connector);
+ }
err = tegra_output_init(drm, output);
if (err < 0) {
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
17.04.2020 22:24, Laurent Pinchart пишет: ... > As I tried to explain before, if you wrap the panel in a bridge with > drm_panel_bridge_add() (or the devm_ variant), you will always have a > bridge associated with the output, and will be able to remove your > custom connector implementation. I thus recommend converting to > drm_panel_bridge_add() either as part of this patch series, or just > after it, to get full benefits. > > With the assumption that this will be handled, > > Reviewed-by: Laurent Pinchart Thanks you very much! Yes, I got yours point about wrapping panel into the bridge. But I don't think that it's worth the effort right now because each Tegra output has it's own implantation of the connector and it should be cleaner not to touch that code. Secondly, I don't have hardware to test all available panel output types on Tegra and the benefits of messing with all that code are a bit dim to me. I can make a patch to wrap the RGB panel into a bridge, but this should make code a bit inconsistent in regards to not having a common code path for the "legacy" nvidia,panel. So perhaps it's better to leave it all as-is for now. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
---
Changes in v3:
- Use next_bridge field to store the panel bridge. (Laurent Pinchart)
- Add the bridge.type field. (Laurent Pinchart)
- This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
properly.
Changes in v2:
- Do not set connector_type for panel here. (Sam Ravnborg)
drivers/gpu/drm/mediatek/mtk_dsi.c | 187 +++--
1 file changed, 14 insertions(+), 173 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index d68694ff00dc..157097c63b23 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,8 +182,6 @@ struct mtk_dsi {
struct mipi_dsi_host host;
struct drm_encoder encoder;
struct drm_bridge bridge;
- struct drm_connector conn;
- struct drm_panel *panel;
struct drm_bridge *next_bridge;
struct phy *phy;
@@ -212,11 +210,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct
drm_bridge *b)
return container_of(b, struct mtk_dsi, bridge);
}
-static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
-{
- return container_of(c, struct mtk_dsi, conn);
-}
-
static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
{
return container_of(h, struct mtk_dsi, host);
@@ -682,16 +675,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_lane0_ulp_mode_leave(dsi);
mtk_dsi_clk_hs_mode(dsi, 0);
- if (dsi->panel) {
- if (drm_panel_prepare(dsi->panel)) {
- DRM_ERROR("failed to prepare the panel\n");
- goto err_disable_digital_clk;
- }
- }
-
return 0;
-err_disable_digital_clk:
- clk_disable_unprepare(dsi->digital_clk);
err_disable_engine_clk:
clk_disable_unprepare(dsi->engine_clk);
err_phy_power_off:
@@ -718,15 +702,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
*/
mtk_dsi_stop(dsi);
- if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
- if (dsi->panel) {
- if (drm_panel_unprepare(dsi->panel)) {
- DRM_ERROR("failed to unprepare the panel\n");
- return;
- }
- }
- }
-
+ mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);
@@ -757,19 +733,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
mtk_dsi_start(dsi);
- if (dsi->panel) {
- if (drm_panel_enable(dsi->panel)) {
- DRM_ERROR("failed to enable the panel\n");
- goto err_dsi_power_off;
- }
- }
-
dsi->enabled = true;
-
- return;
-err_dsi_power_off:
- mtk_dsi_stop(dsi);
- mtk_dsi_poweroff(dsi);
}
static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
@@ -777,34 +741,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
if (!dsi->enabled)
return;
- if (dsi->panel) {
- if (drm_panel_disable(dsi->panel)) {
- DRM_ERROR("failed to disable the panel\n");
- return;
- }
- }
-
mtk_dsi_poweroff(dsi);
dsi->enabled = false;
}
-static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
*dsi);
-static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
-
static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)
{
struct mtk_dsi *dsi = bridge_to_dsi(bridge);
- return mtk_dsi_create_conn_enc(bridge->dev, dsi);
-}
-
-static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
-{
- struct mtk_dsi *dsi = bridge_to_dsi(bridge);
-
- mtk_dsi_destroy_conn_enc(dsi);
+ /* Attach the panel or bridge to the dsi bridge */
+ return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
+&dsi->bridge, flags);
}
static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
@@ -830,115 +779,13 @@ static void mtk_dsi_bridge_enable(struct drm_bridge
*bridge)
mtk_output_dsi_enable(dsi);
}
-static int mtk_dsi_connector_get_modes(struct drm_connector *connector)
-{
- struct mtk_dsi *dsi = connector_to_dsi(connector);
-
- return drm_panel_get_modes(dsi->panel, connector);
-}
-
static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
.attach = mtk_dsi_bridge_attach,
- .detach = mtk_dsi_bridge_deta
[PATCH 1/1] drm/qxl: add mutex_lock/mutex_unlock to ensure the order in which resources are released.
When a qxl resource is released, the list that needs to be released is
fetched from the linked list ring and cleared. When you empty the list,
instead of trying to determine whether the ttm buffer object for each
qxl in the list is locked, you release the qxl object and remove the
element from the list until the list is empty. It was found that the
linked list was cleared first, and that the lock on the corresponding
ttm Bo for the QXL had not been released, so that the new qxl could not
be locked when it used the TTM. By adding an additional mutex to ensure
timing, qxl elements are not allowed to be removed from the list until
ttm Bo's lock is released
Signed-off-by: Caicai
---
drivers/gpu/drm/qxl/qxl_cmd.c | 12 +++-
drivers/gpu/drm/qxl/qxl_display.c | 15 +++
drivers/gpu/drm/qxl/qxl_draw.c| 19 +++
drivers/gpu/drm/qxl/qxl_drv.h | 3 ++-
drivers/gpu/drm/qxl/qxl_ioctl.c | 3 +++
drivers/gpu/drm/qxl/qxl_release.c | 2 ++
6 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index 208af9f37914..484405dae253 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -203,7 +203,9 @@ bool qxl_queue_garbage_collect(struct qxl_device *qdev,
bool flush)
if (!qxl_check_idle(qdev->release_ring)) {
schedule_work(&qdev->gc_work);
if (flush)
- flush_work(&qdev->gc_work);
+ //can't flush work, it may lead to deadlock
+ usleep_range(500, 1000);
+
return true;
}
return false;
@@ -241,7 +243,11 @@ int qxl_garbage_collect(struct qxl_device *qdev)
}
id = next_id;
+ mutex_lock(&release->async_release_mutex);
+
qxl_release_free(qdev, release);
+
+ mutex_unlock(&release->async_release_mutex);
++i;
}
}
@@ -475,6 +481,8 @@ int qxl_hw_surface_alloc(struct qxl_device *qdev,
if (ret)
return ret;
+ mutex_lock(&release->async_release_mutex);
+
cmd = (struct qxl_surface_cmd *)qxl_release_map(qdev, release);
cmd->type = QXL_SURFACE_CMD_CREATE;
cmd->flags = QXL_SURF_FLAG_KEEP_DATA;
@@ -503,6 +511,8 @@ int qxl_hw_surface_alloc(struct qxl_device *qdev,
qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
qxl_release_fence_buffer_objects(release);
+ mutex_unlock(&release->async_release_mutex);
+
surf->hw_surf_alloc = true;
spin_lock(&qdev->surf_id_idr_lock);
idr_replace(&qdev->surf_id_idr, surf, surf->surface_id);
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 0570c6826bff..04bfb181a402 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -522,6 +522,8 @@ static int qxl_primary_apply_cursor(struct drm_plane *plane)
if (ret)
goto out_free_release;
+ mutex_lock(&release->async_release_mutex);
+
cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release);
cmd->type = QXL_CURSOR_SET;
cmd->u.set.position.x = plane->state->crtc_x + fb->hot_x;
@@ -535,6 +537,8 @@ static int qxl_primary_apply_cursor(struct drm_plane *plane)
qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
qxl_release_fence_buffer_objects(release);
+ mutex_unlock(&release->async_release_mutex);
+
return ret;
out_free_release:
@@ -653,6 +657,8 @@ static void qxl_cursor_atomic_update(struct drm_plane
*plane,
if (ret)
goto out_free_bo;
+ mutex_lock(&release->async_release_mutex);
+
ret = qxl_bo_kmap(cursor_bo, (void **)&cursor);
if (ret)
goto out_backoff;
@@ -686,6 +692,8 @@ static void qxl_cursor_atomic_update(struct drm_plane
*plane,
if (ret)
goto out_free_release;
+ mutex_lock(&release->async_release_mutex);
+
cmd = (struct qxl_cursor_cmd *) qxl_release_map(qdev, release);
cmd->type = QXL_CURSOR_MOVE;
}
@@ -697,6 +705,8 @@ static void qxl_cursor_atomic_update(struct drm_plane
*plane,
qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
qxl_release_fence_buffer_objects(release);
+ mutex_unlock(&release->async_release_mutex);
+
if (old_cursor_bo)
qxl_bo_unref(&old_cursor_bo);
@@ -706,6 +716,7 @@ static void qxl_cursor_atomic_update(struct drm_plane
*plane,
out_backoff:
qxl_release_backoff_reserve_list(release);
+ mutex_unlock(&release->async_release_mutex);
out_free_bo:
qxl_bo_unref(&cursor_bo);
out_kunmap:
@@ -736,12 +747,16 @@ s
Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
Hello Laurent, 17.04.2020 22:30, Laurent Pinchart пишет: ... >> #include >> +#include > > You could add a forward declaration of struct drm_bridge instead, that > can lower the compilation time a little bit. This include is not only for the struct, but also for the drm_bridge_attach(). It looks to me that it should be nicer to keep the include here. ... >> +port = of_get_child_by_name(output->of_node, "port"); > > Do you need to check for the presence of a port node first ? Can you > just check the return value of drm_of_find_panel_or_bridge(), and fall > back to "nvidia,panel" if it returns -ENODEV ? Without the check, the drm_of_find_panel_or_bridge() prints a very noisy error message about missing port node for every output that doesn't have a graph specified in a device-tree (HDMI, DSI and etc). https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] amdgpu_amdkfd_gpuvm_free_memory_of_gpu, reduce noneed mutex_lock area
Maybe we could reduce the mutex_lock(&mem->lock)`s protected code area,
and noneed to protect pr_debug.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 327317c..3c3769e5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1285,17 +1285,18 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
struct bo_vm_reservation_context ctx;
struct ttm_validate_buffer *bo_list_entry;
int ret;
+ unsigned int mapped_to_gpu_memory;
mutex_lock(&mem->lock);
+ mapped_to_gpu_memory = mem->mapped_to_gpu_memory;
+ mutex_unlock(&mem->lock);
- if (mem->mapped_to_gpu_memory > 0) {
+ if (mapped_to_gpu_memory > 0) {
pr_debug("BO VA 0x%llx size 0x%lx is still mapped.\n",
mem->va, bo_size);
- mutex_unlock(&mem->lock);
return -EBUSY;
}
- mutex_unlock(&mem->lock);
/* lock is not needed after this, since mem is unused and will
* be freed anyway
*/
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/7] drm/bridge: ps8640: Get the EDID from eDP control
The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/parade-ps8640.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 4b099196afeb..13755d278db6 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
}
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+ return drm_get_edid(connector,
+ ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+ .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
};
@@ -294,6 +304,8 @@ static int ps8640_probe(struct i2c_client *client)
ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+ ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+ ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
ps_bridge->page[PAGE0_DP_CNTL] = client;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/7] drm/bridge_connector: Set default status connected for eDP connectors
In an eDP application, HPD is not required and on most bridge chips useless. If HPD is not used, we need to set initial status as connected, otherwise the connector created by the drm_bridge_connector API remains in an unknown state. Signed-off-by: Enric Balletbo i Serra Reviewed-by: Laurent Pinchart --- Changes in v3: None Changes in v2: None drivers/gpu/drm/drm_bridge_connector.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_bridge_connector.c b/drivers/gpu/drm/drm_bridge_connector.c index c6994fe673f3..a58cbde59c34 100644 --- a/drivers/gpu/drm/drm_bridge_connector.c +++ b/drivers/gpu/drm/drm_bridge_connector.c @@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector *connector, bool force) case DRM_MODE_CONNECTOR_DPI: case DRM_MODE_CONNECTOR_LVDS: case DRM_MODE_CONNECTOR_DSI: + case DRM_MODE_CONNECTOR_eDP: status = connector_status_connected; break; default: -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
17.04.2020 23:31, Laurent Pinchart пишет: > Hi Dmitry, > > On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote: >> 17.04.2020 22:30, Laurent Pinchart пишет: >> ... #include +#include >>> >>> You could add a forward declaration of struct drm_bridge instead, that >>> can lower the compilation time a little bit. >> >> This include is not only for the struct, but also for the >> drm_bridge_attach(). It looks to me that it should be nicer to keep the >> include here. > > drm_bridge_attach() is called from .c files. In the .h file you can use > a forward declaration. It's entirely up to you, but as a general rule, I > personally try to use forward structure declarations in .h files as much > as possible. The current Tegra DRM code is a bit inconsistent in regards to having forward declarations, it doesn't have them more than have. I'll add a forward declaration if there will be need to make a v5, ok? >> ... + port = of_get_child_by_name(output->of_node, "port"); >>> >>> Do you need to check for the presence of a port node first ? Can you >>> just check the return value of drm_of_find_panel_or_bridge(), and fall >>> back to "nvidia,panel" if it returns -ENODEV ? >> >> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy >> error message about missing port node for every output that doesn't have >> a graph specified in a device-tree (HDMI, DSI and etc). >> >> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621 > > Ah yes indeed. That's not very nice. > Please let me know if you'll have a better idea about how this could be handled. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm:simple_bridge_attach [simple_bridge]] *ERROR* Fix bridge driver to make connector optional!
Hi Laurent, > Am 17.04.2020 um 14:58 schrieb Laurent Pinchart > : > > Hello, > > On Fri, Apr 17, 2020 at 02:44:22PM +0200, Maxime Ripard wrote: >> On Fri, Apr 17, 2020 at 02:18:11PM +0200, H. Nikolaus Schaller wrote: >>> Hi Maxime, >>> I have started to test v5.7-rc1 and can't fully boot the GTA04 >>> device any more. >>> >>> What I see in the log is: >>> >>> [ 28.567840] [drm:simple_bridge_attach [simple_bridge]] *ERROR* Fix >>> bridge driver to make connector optional! >>> [ 28.567871] omapdrm omapdrm.0: unable to attach bridge >>> /ocp@6800/dss@4805/encoder@48050c00 >>> [ 28.786529] omapdrm omapdrm.0: omap_modeset_init failed: ret=-22 >>> [ 28.841552] omapdrm: probe of omapdrm.0 failed with error -22 >>> >>> This device uses the ti,opa362 chip which did have a dedicated >>> omapdss driver before (which is removed now) and which seems to >>> be supported by the simple_bridge now. >>> >>> The opa362 is sitting in the video out path from >>> >>> omapdrm -> venc -> opa362 -> video-out-connector. >>> >>> What does this error mean? How can it be fixed? >> >> -22 is usually EINVAL, which can be pretty much anything. A good thing to do >> would be to bisect to see which actual commit broke it, but if I was to bet >> on >> something I guess it would be >> >> https://lore.kernel.org/dri-devel/20200226112514.12455-1-laurent.pinch...@ideasonboard.com/ > > Would "[PATCH 0/2] drm: bridge: simple-bridge: Enable usage with DRM > bridge connector helper" solve it ? Yes, seems to magically solve the boot issue! I'll confirm later if the opa362 is still (or again) working. BR and thanks, Nikolaus Schaller ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v3:
- Move the bridge.type line to the patch that adds drm_bridge support. (Laurent
Pinchart)
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 157097c63b23..85f76b01ae4d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -183,6 +184,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
+ struct drm_connector *connector;
struct phy *phy;
void __iomem *regs;
@@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
struct mtk_dsi *dsi)
*/
dsi->encoder.possible_crtcs = 1;
- ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
+ ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
+ DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
goto err_cleanup_encoder;
+ dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
+ if (IS_ERR(dsi->connector)) {
+ DRM_ERROR("Unable to create bridge connector\n");
+ ret = PTR_ERR(dsi->connector);
+ goto err_cleanup_encoder;
+ }
+ drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
+
return 0;
err_cleanup_encoder:
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] reserve_bo_and_cond_vms: Remove unnecessary condition check
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9dff792..327317c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -735,10 +735,8 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
false, &ctx->duplicates);
if (!ret)
ctx->reserved = true;
- else
+ else {
pr_err("Failed to reserve buffers in ttm.\n");
-
- if (ret) {
kfree(ctx->vm_pd);
ctx->vm_pd = NULL;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge
Hi Laurent,
On 16/4/20 19:24, Laurent Pinchart wrote:
> Hi Enric,
>
> Thank you for the patch.
>
> On Thu, Apr 16, 2020 at 05:57:15PM +0200, Enric Balletbo i Serra wrote:
>> This is really a cosmetic change just to make a bit more readable the
>> code after convert the driver to drm_bridge. The bridge variable name
>> will be used by the encoder drm_bridge, and the chained bridge will be
>> named next_bridge.
>>
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>>
>> Changes in v2: None
>>
>> 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 cfa45d6abd74..44ee884cc31c 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> @@ -182,7 +182,7 @@ struct mtk_dsi {
>> struct drm_encoder encoder;
>> struct drm_connector conn;
>> struct drm_panel *panel;
>> -struct drm_bridge *bridge;
>> +struct drm_bridge *next_bridge;
>> struct phy *phy;
>>
>> void __iomem *regs;
>> @@ -903,8 +903,9 @@ static int mtk_dsi_create_conn_enc(struct drm_device
>> *drm, struct mtk_dsi *dsi)
>> dsi->encoder.possible_crtcs = 1;
>>
>> /* If there's a bridge, attach to it and let it create the connector */
>
> Maybe s/bridge/next bridge/ here ? I expect this comment to go away
> though, as there will always be a next bridge when the driver switches
> to the DRM panel bridge helper.
>
I'll rename it to next bridge for coherency, however, as you point this message
is removed later.
> Reviewed-by: Laurent Pinchart
>
>> -if (dsi->bridge) {
>> -ret = drm_bridge_attach(&dsi->encoder, dsi->bridge, NULL, 0);
>> +if (dsi->next_bridge) {
>> +ret = drm_bridge_attach(&dsi->encoder, dsi->next_bridge, NULL,
>> +0);
>> if (ret) {
>> DRM_ERROR("Failed to attach bridge to drm\n");
>> goto err_encoder_cleanup;
>> @@ -1185,7 +1186,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>> }
>>
>> ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
>> - &dsi->panel, &dsi->bridge);
>> + &dsi->panel, &dsi->next_bridge);
>> if (ret)
>> goto err_unregister_host;
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/gma500: remove unused variable 'hdmi_ids'
drivers/gpu/drm/gma500/oaktrail_hdmi.c:676:35: warning: ‘hdmi_ids’ defined but
not used [-Wunused-const-variable=]
static const struct pci_device_id hdmi_ids[] = {
^~~~
It is never used, remove it.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index b25086f252ae..a097a59a9eae 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -663,11 +663,6 @@ void oaktrail_hdmi_init(struct drm_device *dev,
kfree(gma_encoder);
}
-static const struct pci_device_id hdmi_ids[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x080d) },
- { 0 }
-};
-
void oaktrail_hdmi_setup(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
"The PM core always increments the runtime usage counter
before calling the ->suspend() callback and decrements it
after calling the ->resume() callback"
DPU and DSI are managed as runtime devices. When
suspend is triggered, PM core adds a refcount on all the
devices and calls device suspend, since usage count is
already incremented, runtime suspend was not getting called
and it kept the clocks on which resulted in target not
entering into XO shutdown.
Add changes to force suspend on runtime devices during pm sleep.
Changes in v1:
- Remove unnecessary checks in the function
_dpu_kms_disable_dpu (Rob Clark).
Changes in v2:
- Avoid using suspend_late to reset the usagecount
as suspend_late might not be called during suspend
call failures (Doug).
Changes in v3:
- Use force suspend instead of managing device usage_count
via runtime put and get API's to trigger callbacks (Doug).
Changes in v4:
- Check the return values of pm_runtime_force_suspend and
pm_runtime_force_resume API's and pass appropriately (Doug).
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi.c | 2 ++
drivers/gpu/drm/msm/msm_drv.c | 14 +-
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ce19f1d..b886d9d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1123,6 +1123,8 @@ static int __maybe_unused dpu_runtime_resume(struct
device *dev)
static const struct dev_pm_ops dpu_pm_ops = {
SET_RUNTIME_PM_OPS(dpu_runtime_suspend, dpu_runtime_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static const struct of_device_id dpu_dt_match[] = {
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 55ea4bc2..62704885 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -161,6 +161,8 @@ static int dsi_dev_remove(struct platform_device *pdev)
static const struct dev_pm_ops dsi_pm_ops = {
SET_RUNTIME_PM_OPS(msm_dsi_runtime_suspend, msm_dsi_runtime_resume,
NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static struct platform_driver dsi_driver = {
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7d985f8..4b93fc1 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1040,6 +1040,7 @@ static int msm_pm_suspend(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
struct msm_drm_private *priv = ddev->dev_private;
+ int ret, rc;
if (WARN_ON(priv->pm_state))
drm_atomic_state_put(priv->pm_state);
@@ -1051,7 +1052,14 @@ static int msm_pm_suspend(struct device *dev)
return ret;
}
- return 0;
+ ret = pm_runtime_force_suspend(dev);
+ if (ret) {
+ rc = drm_atomic_helper_resume(ddev, priv->pm_state);
+ if (!rc)
+ priv->pm_state = NULL;
+ }
+
+ return ret;
}
static int msm_pm_resume(struct device *dev)
@@ -1063,6 +1071,10 @@ static int msm_pm_resume(struct device *dev)
if (WARN_ON(!priv->pm_state))
return -ENOENT;
+ ret = pm_runtime_force_resume(dev);
+ if (ret)
+ return ret;
+
ret = drm_atomic_helper_resume(ddev, priv->pm_state);
if (!ret)
priv->pm_state = NULL;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge
The PS8640 dsi-to-eDP bridge driver is using the panel bridge API, however, not all the components in the chain have been ported to the drm_bridge API. Actually, when a panel is attached the default panel's mode is used, but in some cases we can't get display up if mode getting from eDP control EDID is not chosen. This series address that problem, first implements the .get_edid() callback in the PS8640 driver (which is not used until the conversion is done) and then, converts the Mediatek DSI driver to use the drm_bridge API. As far as I know, we're the only users of the mediatek dsi driver in mainline, so should be safe to switch to the new chain of drm_bridge API unconditionally. The patches has been tested on a Acer Chromebook R13 (Elm) running a Chrome OS userspace and checking that the valid EDID mode reported by the bridge is selected. [1] https://lore.kernel.org/lkml/20200210063523.13-1-hsi...@chromium.org/ Changes in v3: - Replace s/bridge/next bridge/ for comment. (Laurent Pinchart) - Add the bridge.type. (Laurent Pinchart) - Use next_bridge field to store the panel bridge. (Laurent Pinchart) - Add the bridge.type field. (Laurent Pinchart) - This patch requires https://lkml.org/lkml/2020/4/16/2080 to work properly. - Move the bridge.type line to the patch that adds drm_bridge support. (Laurent Pinchart) Changes in v2: - Do not set connector_type for panel here. (Sam Ravnborg) Enric Balletbo i Serra (7): drm/bridge: ps8640: Get the EDID from eDP control drm/bridge_connector: Set default status connected for eDP connectors drm/mediatek: mtk_dsi: Rename bridge to next_bridge drm/mediatek: mtk_dsi: Convert to bridge driver drm/mediatek: mtk_dsi: Use simple encoder drm/mediatek: mtk_dsi: Use the drm_panel_bridge API drm/mediatek: mtk_dsi: Create connector for bridges drivers/gpu/drm/bridge/parade-ps8640.c | 12 ++ drivers/gpu/drm/drm_bridge_connector.c | 1 + drivers/gpu/drm/mediatek/mtk_dsi.c | 276 - 3 files changed, 96 insertions(+), 193 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: aty128fb: remove unused 'sdr_64'
Fix the following gcc warning:
drivers/video/fbdev/aty/aty128fb.c:337:36: warning: ‘sdr_64’ defined but
not used [-Wunused-const-variable=]
static const struct aty128_meminfo sdr_64 = {
^~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/video/fbdev/aty/aty128fb.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/video/fbdev/aty/aty128fb.c
b/drivers/video/fbdev/aty/aty128fb.c
index d7e41c8dd533..d05d4195acad 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -334,20 +334,6 @@ static const struct aty128_meminfo sdr_128 = {
.name = "128-bit SDR SGRAM (1:1)",
};
-static const struct aty128_meminfo sdr_64 = {
- .ML = 4,
- .MB = 8,
- .Trcd = 3,
- .Trp = 3,
- .Twr = 1,
- .CL = 3,
- .Tr2w = 1,
- .LoopLatency = 17,
- .DspOn = 46,
- .Rloop = 17,
- .name = "64-bit SDR SGRAM (1:1)",
-};
-
static const struct aty128_meminfo sdr_sgram = {
.ML = 4,
.MB = 4,
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm:simple_bridge_attach [simple_bridge]] *ERROR* Fix bridge driver to make connector optional!
Hi Maxime, I have started to test v5.7-rc1 and can't fully boot the GTA04 device any more. What I see in the log is: [ 28.567840] [drm:simple_bridge_attach [simple_bridge]] *ERROR* Fix bridge driver to make connector optional! [ 28.567871] omapdrm omapdrm.0: unable to attach bridge /ocp@6800/dss@4805/encoder@48050c00 [ 28.786529] omapdrm omapdrm.0: omap_modeset_init failed: ret=-22 [ 28.841552] omapdrm: probe of omapdrm.0 failed with error -22 This device uses the ti,opa362 chip which did have a dedicated omapdss driver before (which is removed now) and which seems to be supported by the simple_bridge now. The opa362 is sitting in the video out path from omapdrm -> venc -> opa362 -> video-out-connector. What does this error mean? How can it be fixed? BR and thanks, Nikolaus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/v3d: remove unused 'v3d_v3d_pm_ops '
Fix the following gcc warning:
drivers/gpu/drm/v3d/v3d_drv.c:73:32: warning: ‘v3d_v3d_pm_ops’ defined
but not used [-Wunused-const-variable=]
static const struct dev_pm_ops v3d_v3d_pm_ops = {
^~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/gpu/drm/v3d/v3d_drv.c | 36 ---
1 file changed, 36 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 8d0c0daaac81..63f09c55a970 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -38,42 +38,6 @@
#define DRIVER_MINOR 0
#define DRIVER_PATCHLEVEL 0
-#ifdef CONFIG_PM
-static int v3d_runtime_suspend(struct device *dev)
-{
- struct drm_device *drm = dev_get_drvdata(dev);
- struct v3d_dev *v3d = to_v3d_dev(drm);
-
- v3d_irq_disable(v3d);
-
- clk_disable_unprepare(v3d->clk);
-
- return 0;
-}
-
-static int v3d_runtime_resume(struct device *dev)
-{
- struct drm_device *drm = dev_get_drvdata(dev);
- struct v3d_dev *v3d = to_v3d_dev(drm);
- int ret;
-
- ret = clk_prepare_enable(v3d->clk);
- if (ret != 0)
- return ret;
-
- /* XXX: VPM base */
-
- v3d_mmu_set_page_table(v3d);
- v3d_irq_enable(v3d);
-
- return 0;
-}
-#endif
-
-static const struct dev_pm_ops v3d_v3d_pm_ops = {
- SET_RUNTIME_PM_OPS(v3d_runtime_suspend, v3d_runtime_resume, NULL)
-};
-
static int v3d_get_param_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/powerplay: remove defined but not used variables
Fix the following gcc warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega10_powertune.c:710:46:
warning: ‘PSMGCEDCThresholdConfig_vega10’ defined but not used
[-Wunused-const-variable=]
static const struct vega10_didt_config_reg
PSMGCEDCThresholdConfig_vega10[] =
^~
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega10_powertune.c:654:46:
warning: ‘PSMSEEDCThresholdConfig_Vega10’ defined but not used
[-Wunused-const-variable=]
static const struct vega10_didt_config_reg
PSMSEEDCThresholdConfig_Vega10[] =
^~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
.../amd/powerplay/hwmgr/vega10_powertune.c| 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
index ca9b23b5abc9..9757d47dd6b8 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
@@ -651,18 +651,6 @@ static const struct vega10_didt_config_reg
PSMSEEDCStallDelayConfig_Vega10[] =
{ 0x } /* End of list */
};
-static const struct vega10_didt_config_reg PSMSEEDCThresholdConfig_Vega10[] =
-{
-/*
-
- * Offset Mask
Shift Value
- *
-
- */
- /* SQ EDC THRESHOLD */
- { ixDIDT_SQ_EDC_THRESHOLD,
DIDT_SQ_EDC_THRESHOLD__EDC_THRESHOLD_MASK,
DIDT_SQ_EDC_THRESHOLD__EDC_THRESHOLD__SHIFT,0x },
-
- { 0x } /* End of list */
-};
-
static const struct vega10_didt_config_reg PSMSEEDCCtrlResetConfig_Vega10[] =
{
/*
-
@@ -707,17 +695,6 @@ static const struct vega10_didt_config_reg
PSMSEEDCCtrlConfig_Vega10[] =
{ 0x } /* End of list */
};
-static const struct vega10_didt_config_reg PSMGCEDCThresholdConfig_vega10[] =
-{
-/*
-
- * Offset Mask
Shift Value
- *
-
- */
- { mmGC_EDC_THRESHOLD,
GC_EDC_THRESHOLD__EDC_THRESHOLD_MASK,
GC_EDC_THRESHOLD__EDC_THRESHOLD__SHIFT, 0x000 },
-
- { 0x } /* End of list */
-};
-
static const struct vega10_didt_config_reg PSMGCEDCDroopCtrlConfig_vega10[] =
{
/*
-
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
Hi Maxime,
> Am 17.04.2020 um 12:25 schrieb Maxime Ripard :
>
> Hi,
>
> On Wed, Apr 15, 2020 at 06:42:18PM +0200, H. Nikolaus Schaller wrote:
>>> Am 15.04.2020 um 18:21 schrieb Maxime Ripard :
>>>
>>> On Wed, Apr 15, 2020 at 05:09:45PM +0200, H. Nikolaus Schaller wrote:
Hi Maxime,
Hm. Yes. We know that there likely are clocks and maybe reset
but for some SoC this seems to be undocumented and the reset
line the VHDL of the sgx gpu provides may be permanently tied
to "inactive".
So if clocks are optional and not provided, a driver simply can assume
they are enabled somewhere else and does not have to care about. If
they are specified, the driver can enable/disable them.
>>>
>>> Except that at the hardware level, the clock is always going to be
>>> there. You can't control it, but it's there.
>>
>> Sure, we can deduce that from general hardware design knowledge.
>> But not every detail must be described in DT. Only the important
>> ones.
>>
> If OMAP is too much of a pain, you can also make
> a separate binding for it, and a generic one for the rest of us.
No, omap isn't any pain at all.
The pain is that some other SoC are most easily defined by clocks in
the gpu node which the omap doesn't need to explicitly specify.
I would expect a much bigger nightmare if we split this into two
bindings variants.
> I'd say that it's pretty unlikely that the clocks, interrupts (and
> even regulators) are optional. It might be fixed on some SoCs, but
> that's up to the DT to express that using fixed clocks / regulators,
> not the GPU binding itself.
omap already has these defined them not to be part of the GPU binding.
The reason seems to be that this needs special clock gating control
especially for idle states which is beyond simple clock-enable.
This sysc target-module@5600 node is already merged and therefore
we are only adding the gpu child node. Without defining clocks.
For example:
sgx_module: target-module@5600 {
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x5600fe00 0x4>,
<0x5600fe10 0x4>;
reg-names = "rev", "sysc";
ti,sysc-midle = ,
,
;
ti,sysc-sidle = ,
,
;
clocks = <&gpu_clkctrl OMAP5_GPU_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
gpu: gpu@0 {
compatible = "ti,omap5-sgx544-116",
"img,sgx544-116", "img,sgx544";
reg = <0x0 0x1>;
interrupts = ;
};
};
The jz4780 example will like this:
gpu: gpu@1304 {
compatible = "ingenic,jz4780-sgx540-130", "img,sgx540-130",
"img,sgx540";
reg = <0x1304 0x4000>;
clocks = <&cgu JZ4780_CLK_GPU>;
clock-names = "gpu";
interrupt-parent = <&intc>;
interrupts = <63>;
};
So the question is which one is "generic for the rest of us"?
>>>
>>> I'd say the latter.
>>
>> Why?
>>
>> TI SoC seem to be the broadest number of available users
>> of sgx5xx in the past and nowadays. Others are more the exception.
>
> And maybe TI has some complicated stuff around the GPU that others don't have?
Looks so.
> If I look quickly at the Allwinner stuff, I see nothing looking alike in the
> SoC, so making the binding like that for everyone just because TI did
> something
> doesn't really make much sense.
That is why I propose to make the clocks optional. This solves both
cases in a simple and neat way.
>
>>> If your clock is optional, then you define it but don't mandate
>>> it. Not documenting it will only result in a mess where everyone will
>>> put some clock into it, possibly with different semantics each and
>>> every time.
>>
>> So you mean that we should require a dummy clock for the omap gpu node
>> or did I misunderstand that?
>>
>> Well, yes there is of course a clock connection between the
>> omap target-module and the sgx but it is IMHO pointless to
>> describe it because it can't and does not need to be controlled
>> separately.
>>
>> As said the target-module is already accepted and upstream and my
>> proposal is to get the gpu node described there. There is simply
>> no need for a clocks node for the omap.
>
> There is no need for a clocks property
[PATCH v3 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
---
Changes in v3:
- Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index cfa45d6abd74..37b8d7ffd835 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,7 +182,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_connector conn;
struct drm_panel *panel;
- struct drm_bridge *bridge;
+ struct drm_bridge *next_bridge;
struct phy *phy;
void __iomem *regs;
@@ -902,9 +902,10 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm,
struct mtk_dsi *dsi)
*/
dsi->encoder.possible_crtcs = 1;
- /* If there's a bridge, attach to it and let it create the connector */
- if (dsi->bridge) {
- ret = drm_bridge_attach(&dsi->encoder, dsi->bridge, NULL, 0);
+ /* If there's a next bridge, attach to it and let it create the
connector */
+ if (dsi->next_bridge) {
+ ret = drm_bridge_attach(&dsi->encoder, dsi->next_bridge, NULL,
+ 0);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
goto err_encoder_cleanup;
@@ -1185,7 +1186,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
}
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- &dsi->panel, &dsi->bridge);
+ &dsi->panel, &dsi->next_bridge);
if (ret)
goto err_unregister_host;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] drm, fbdev: rework dependencies
On Fri, Apr 17, 2020 at 07:14:53PM +0200, Daniel Vetter wrote: > On Fri, Apr 17, 2020 at 05:55:45PM +0200, Arnd Bergmann wrote: > > I tried to fix up some dependencies after the sii8620 "imply EXTCON" > > statementn broke, trying a few things but in the backing out a > > change that would completely reverse the LEDS_CLASS selects into > > a 'depends on'. > > > > However, what I got now are multiple changes that remove gratious > > "selects" that lead to circular dependencies for sii8620 and others: > > > > - Anything doing "select FB" is now gone, or becomes "depends on FB", > > > > - DDC support depends on I2C instead of selecting it > > > > - backlight class device support is never selected by framebuffer > > drivers but has proper dependencies > > > > I have done thousands of randconfig build tests on this, but no > > runtime tests. > > > > Some of the 'depends on FOO || !FOO' statements could be simplified > > into a new 'uses FOO' syntax based on a patch from Saeed Mahameed, > > but I would for the moment treat that as a cleanup that can be done > > later. > > > > If we can agree on these changes, maybe someone can merge them > > through the drm-misc tree. > > > > Please review > > Biggest concern I have is that usability of make menuconfig is horrible, > and it's very hard to find options that are hidden by depends on. You can > use the search interface, if you happen to know the option. > > Once you've surmounted that bar, the next one is trying to find what > exactly you need to enable. Which again means endless of recursive > screaming at Kconfig files, since make menuconfig doesn't help you at all. +1 on this. But this is a general kconfig problem, and not unique to DRM, I've done this screaming for many different things now.. eg to turn on every single RDMA driver. I hackily delt with it by creating this rather insane script based on the python kconfiglib to try and sort things out mostly automatically: https://github.com/jgunthorpe/Kernel-Maintainer-Tools/blob/master/gj_tools/cmd_kconfig.py It would be great if menuconfig had a key to say 'hey, really, turn this on and everything it depends on, recursively' Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
Hi,
On Wed, Apr 15, 2020 at 06:42:18PM +0200, H. Nikolaus Schaller wrote:
> > Am 15.04.2020 um 18:21 schrieb Maxime Ripard :
> >
> > On Wed, Apr 15, 2020 at 05:09:45PM +0200, H. Nikolaus Schaller wrote:
> >> Hi Maxime,
> >>
> >> Hm. Yes. We know that there likely are clocks and maybe reset
> >> but for some SoC this seems to be undocumented and the reset
> >> line the VHDL of the sgx gpu provides may be permanently tied
> >> to "inactive".
> >>
> >> So if clocks are optional and not provided, a driver simply can assume
> >> they are enabled somewhere else and does not have to care about. If
> >> they are specified, the driver can enable/disable them.
> >
> > Except that at the hardware level, the clock is always going to be
> > there. You can't control it, but it's there.
>
> Sure, we can deduce that from general hardware design knowledge.
> But not every detail must be described in DT. Only the important
> ones.
>
> >>> If OMAP is too much of a pain, you can also make
> >>> a separate binding for it, and a generic one for the rest of us.
> >>
> >> No, omap isn't any pain at all.
> >>
> >> The pain is that some other SoC are most easily defined by clocks in
> >> the gpu node which the omap doesn't need to explicitly specify.
> >>
> >> I would expect a much bigger nightmare if we split this into two
> >> bindings variants.
> >>
> >>> I'd say that it's pretty unlikely that the clocks, interrupts (and
> >>> even regulators) are optional. It might be fixed on some SoCs, but
> >>> that's up to the DT to express that using fixed clocks / regulators,
> >>> not the GPU binding itself.
> >>
> >> omap already has these defined them not to be part of the GPU binding.
> >> The reason seems to be that this needs special clock gating control
> >> especially for idle states which is beyond simple clock-enable.
> >>
> >> This sysc target-module@5600 node is already merged and therefore
> >> we are only adding the gpu child node. Without defining clocks.
> >>
> >> For example:
> >>
> >>sgx_module: target-module@5600 {
> >>compatible = "ti,sysc-omap4", "ti,sysc";
> >>reg = <0x5600fe00 0x4>,
> >> <0x5600fe10 0x4>;
> >>reg-names = "rev", "sysc";
> >>ti,sysc-midle = ,
> >>,
> >>;
> >>ti,sysc-sidle = ,
> >>,
> >>;
> >>clocks = <&gpu_clkctrl OMAP5_GPU_CLKCTRL 0>;
> >>clock-names = "fck";
> >>#address-cells = <1>;
> >>#size-cells = <1>;
> >>ranges = <0 0x5600 0x200>;
> >>
> >>gpu: gpu@0 {
> >>compatible = "ti,omap5-sgx544-116",
> >> "img,sgx544-116", "img,sgx544";
> >>reg = <0x0 0x1>;
> >>interrupts = ;
> >>};
> >>};
> >>
> >> The jz4780 example will like this:
> >>
> >>gpu: gpu@1304 {
> >>compatible = "ingenic,jz4780-sgx540-130", "img,sgx540-130",
> >> "img,sgx540";
> >>reg = <0x1304 0x4000>;
> >>
> >>clocks = <&cgu JZ4780_CLK_GPU>;
> >>clock-names = "gpu";
> >>
> >>interrupt-parent = <&intc>;
> >>interrupts = <63>;
> >>};
> >>
> >> So the question is which one is "generic for the rest of us"?
> >
> > I'd say the latter.
>
> Why?
>
> TI SoC seem to be the broadest number of available users
> of sgx5xx in the past and nowadays. Others are more the exception.
And maybe TI has some complicated stuff around the GPU that others don't have?
If I look quickly at the Allwinner stuff, I see nothing looking alike in the
SoC, so making the binding like that for everyone just because TI did something
doesn't really make much sense.
> > If your clock is optional, then you define it but don't mandate
> > it. Not documenting it will only result in a mess where everyone will
> > put some clock into it, possibly with different semantics each and
> > every time.
>
> So you mean that we should require a dummy clock for the omap gpu node
> or did I misunderstand that?
>
> Well, yes there is of course a clock connection between the
> omap target-module and the sgx but it is IMHO pointless to
> describe it because it can't and does not need to be controlled
> separately.
>
> As said the target-module is already accepted and upstream and my
> proposal is to get the gpu node described there. There is simply
> no need for a clocks node for the omap.
There is no need for a clocks property *currently* *on the OMAP*.
> What I also assume is that developers of DTS know what they do.
> So the risk that there is different semantics is IMHO very low.
Well, they know what they do if you document the binding. Let's s
[PATCH] backlight: qcom-wled: remove 'wled4_string_cfg' and 'wled3_string_cfg'
Fix the following gcc warning:
drivers/video/backlight/qcom-wled.c:939:34: warning: ‘wled4_string_cfg’
defined but not used [-Wunused-const-variable=]
static const struct wled_var_cfg wled4_string_cfg = {
^~~~
drivers/video/backlight/qcom-wled.c:935:34: warning: ‘wled3_string_cfg’
defined but not used [-Wunused-const-variable=]
static const struct wled_var_cfg wled3_string_cfg = {
^~~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/video/backlight/qcom-wled.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 3d276b30a78c..df53fbd5cd03 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -932,14 +932,6 @@ static const struct wled_var_cfg wled4_string_i_limit_cfg
= {
.size = ARRAY_SIZE(wled4_string_i_limit_values),
};
-static const struct wled_var_cfg wled3_string_cfg = {
- .size = 8,
-};
-
-static const struct wled_var_cfg wled4_string_cfg = {
- .size = 16,
-};
-
static u32 wled_values(const struct wled_var_cfg *cfg, u32 idx)
{
if (idx >= cfg->size)
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 3/4] backlight: qcom-wled: Add WLED5 bindings
On 2020-04-15 20:42, Rob Herring wrote: On Tue, Apr 07, 2020 at 09:17:09PM +0530, Kiran Gunda wrote: Add WLED5 specific bindings. checkpatch.pl complains about some trailing whitespace. The previous patch too. Signed-off-by: Kiran Gunda Signed-off-by: Subbaraman Narayanamurthy --- .../bindings/leds/backlight/qcom-wled.yaml | 60 -- 1 file changed, 57 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml index 770e780..5714631 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -21,6 +21,7 @@ properties: - qcom,pm8941-wled - qcom,pmi8998-wled - qcom,pm660l-wled + - qcom,pm8150l-wled reg: maxItems: 1 @@ -28,12 +29,13 @@ properties: default-brightness: description: brightness value on boot. -minimum: 0 -maximum: 4095 -default: 2048 label: true + max-brightness: +description: + Maximum brightness level. + qcom,cs-out: description: enable current sink output. @@ -130,6 +132,31 @@ properties: This feature is not supported for WLED3. type: boolean + qcom,modulator-sel: +description: Need a '|' at the end to preserve formatting. + Selects the modulator used for brightness modulation. + Allowed values are, + 0 - Modulator A + 1 - Modulator B + This property is applicable only to WLED5 peripheral. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 0, 1 ] + - default: 0 + + qcom,cabc-sel: +description: Need a '|'. + Selects the CABC pin signal used for brightness modulation. + Allowed values are, + 0 - CABC disabled + 1 - CABC 1 + 2 - CABC 2 + 3 - External signal (e.g. LPG) is used for dimming + This property is applicable only to WLED5 peripheral. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 0, 1, 2, 3 ] + allOf: - if: properties: @@ -179,6 +206,33 @@ allOf: - const: ovp - const: short + - if: + properties: +compatible: + contains: +enum: + - qcom,pm8150l-wled + +then: + properties: +default-brightness: + minimum: 0 + maximum: 32767 + +max-brightness: + minimum: 0 + maximum: 32767 + +else: + properties: +default-brightness: +minimum: 0 +maximum: 4095 Wrong indentation. + +max-brightness: + minimum: 0 + maximum: 4095 + required: - compatible - reg -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project Thanks for reviewing. I will submit the next revision with all the fixes. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/7] drm/bridge: ps8640: Get the EDID from eDP control
Hi Laurent,
On 16/4/20 19:22, Laurent Pinchart wrote:
> Hi Enric,
>
> Thank you for the patch.
>
> On Thu, Apr 16, 2020 at 05:57:13PM +0200, Enric Balletbo i Serra wrote:
>> The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
>> .get_edid callback and set the flag to indicate the core to use it.
>>
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>>
>> Changes in v2: None
>>
>> drivers/gpu/drm/bridge/parade-ps8640.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
>> b/drivers/gpu/drm/bridge/parade-ps8640.c
>> index d3a53442d449..956b76e0a44d 100644
>> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> @@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge
>> *bridge,
>> return ret;
>> }
>>
>> +static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
>> + struct drm_connector *connector)
>> +{
>> +struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> +
>> +return drm_get_edid(connector,
>> +ps_bridge->page[PAGE0_DP_CNTL]->adapter);
>
> This will only work if the DDC signals are connected to the PS8640
> (quite obviously). Is that guaranteed, or could some systems connect
> them directory to an SoC I2C controller ?
It is possible but IMHO opinion this is hardware tricky, I mean, ps8640 outputs
eDP interface and the panel is an eDP interface, so I'd expect hardware
engineers do a pin to pin design, not routing the DDC signals to the SoC
directly ignoring the eDP interface.
> In the latter case we would
> have to report this in the DT bindings of the PS8640. That's not
> blocking for this patch, I am just wondering, as I would have expected
> the driver to already expose EDID one way or another if this was
> available and used.
>
> Reviewed-by: Laurent Pinchart
>
>> +}
>> +
>> static const struct drm_bridge_funcs ps8640_bridge_funcs = {
>> .attach = ps8640_bridge_attach,
>> +.get_edid = ps8640_bridge_get_edid,
>> .post_disable = ps8640_post_disable,
>> .pre_enable = ps8640_pre_enable,
>> };
>> @@ -296,6 +306,8 @@ static int ps8640_probe(struct i2c_client *client)
>>
>> ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
>> ps_bridge->bridge.of_node = dev->of_node;
>> +ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
>> +ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
>>
>> ps_bridge->page[PAGE0_DP_CNTL] = client;
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/amd/dc: remove unused variable 'video_optimized_pixel_rates'
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:1017:50:
warning: ‘video_optimized_pixel_rates’ defined but not used
[-Wunused-const-variable=]
static const struct pixel_rate_range_table_entry video_optimized_pixel_rates[]
= {
^~~
commit d8cd587d2bfd ("drm/amd/display: removing MODULO change for dcn2")
left behind this unused vairable, remove it.
Signed-off-by: YueHaibing
---
.../drm/amd/display/dc/dce/dce_clock_source.c | 33 ---
1 file changed, 33 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
index 2e992fbc0d71..d2ad0504b0de 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
@@ -1014,39 +1014,6 @@ struct pixel_rate_range_table_entry {
unsigned short div_factor;
};
-static const struct pixel_rate_range_table_entry video_optimized_pixel_rates[]
= {
- // /1.001 rates
- {25170, 25180, 25200, 1000, 1001}, //25.2MHz -> 25.17
- {59340, 59350, 59400, 1000, 1001}, //59.4Mhz -> 59.340
- {74170, 74180, 74250, 1000, 1001}, //74.25Mhz -> 74.1758
- {125870, 125880, 126000, 1000, 1001}, //126Mhz-> 125.87
- {148350, 148360, 148500, 1000, 1001}, //148.5Mhz -> 148.3516
- {167830, 167840, 168000, 1000, 1001}, //168Mhz-> 167.83
- {222520, 222530, 222750, 1000, 1001}, //222.75Mhz -> 222.527
- {257140, 257150, 257400, 1000, 1001}, //257.4Mhz -> 257.1429
- {296700, 296710, 297000, 1000, 1001}, //297Mhz-> 296.7033
- {342850, 342860, 343200, 1000, 1001}, //343.2Mhz -> 342.857
- {395600, 395610, 396000, 1000, 1001}, //396Mhz-> 395.6
- {409090, 409100, 409500, 1000, 1001}, //409.5Mhz -> 409.091
- {445050, 445060, 445500, 1000, 1001}, //445.5Mhz -> 445.055
- {467530, 467540, 468000, 1000, 1001}, //468Mhz-> 467.5325
- {519230, 519240, 519750, 1000, 1001}, //519.75Mhz -> 519.231
- {525970, 525980, 526500, 1000, 1001}, //526.5Mhz -> 525.974
- {545450, 545460, 546000, 1000, 1001}, //546Mhz-> 545.455
- {593400, 593410, 594000, 1000, 1001}, //594Mhz-> 593.4066
- {623370, 623380, 624000, 1000, 1001}, //624Mhz-> 623.377
- {692300, 692310, 693000, 1000, 1001}, //693Mhz-> 692.308
- {701290, 701300, 702000, 1000, 1001}, //702Mhz-> 701.2987
- {791200, 791210, 792000, 1000, 1001}, //792Mhz-> 791.209
- {890100, 890110, 891000, 1000, 1001}, //891Mhz-> 890.1099
- {1186810, 1186820, 1188000, 1000, 1001},//1188Mhz -> 1186.8131
-
- // *1.001 rates
- {27020, 27030, 27000, 1001, 1000}, //27Mhz
- {54050, 54060, 54000, 1001, 1000}, //54Mhz
- {108100, 108110, 108000, 1001, 1000},//108Mhz
-};
-
static bool dcn20_program_pix_clk(
struct clock_source *clock_source,
struct pixel_clk_params *pix_clk_params,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Multiple regulators for one device [was drm/panfrost: add devfreq regulator support]
Hi Robin, On Fri, 17 Apr 2020 at 13:10, Robin Murphy wrote: > > On 2020-04-16 2:42 pm, Steven Price wrote: > [...] > > Perhaps a better approach would be for Panfrost to hand over the struct > > regulator objects it has already got to the OPP framework. I.e. open > > code dev_pm_opp_set_regulators(), but instead of calling > > regulator_get_optional() simply populate the regulators we already have? > > > > The other benefit of that is it would provide a clear hand-over of > > responsibility between Panfrost handling it's own regulators and the OPP > > framework picking up the work. The disadvantage is that Panfrost would > > have to track whether the regulators have been handed over or not. > > Sounds like the most logical thing to do is to shuffle things around so > we start by trying to set up an OPP table, then fall back to explicitly > claiming clocks and regulators if necessary. Then we can easily make the > devfreq decision later in probe based on how that turned out. Ok I will propose a new serie with this behavior, Thanks Clement > > Robin. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
17.04.2020 23:34, Laurent Pinchart пишет: > On Fri, Apr 17, 2020 at 11:11:06PM +0300, Dmitry Osipenko wrote: >> 17.04.2020 22:24, Laurent Pinchart пишет: >> ... >>> As I tried to explain before, if you wrap the panel in a bridge with >>> drm_panel_bridge_add() (or the devm_ variant), you will always have a >>> bridge associated with the output, and will be able to remove your >>> custom connector implementation. I thus recommend converting to >>> drm_panel_bridge_add() either as part of this patch series, or just >>> after it, to get full benefits. >>> >>> With the assumption that this will be handled, >>> >>> Reviewed-by: Laurent Pinchart >> >> Thanks you very much! >> >> Yes, I got yours point about wrapping panel into the bridge. But I don't >> think that it's worth the effort right now because each Tegra output has >> it's own implantation of the connector and it should be cleaner not to >> touch that code. >> >> Secondly, I don't have hardware to test all available panel output types >> on Tegra and the benefits of messing with all that code are a bit dim to me. >> >> I can make a patch to wrap the RGB panel into a bridge, but this should >> make code a bit inconsistent in regards to not having a common code path >> for the "legacy" nvidia,panel. So perhaps it's better to leave it all >> as-is for now. > > I had a brief look at the code, converting the different output types > one by one would be a better way forward than not doing anything at all > in my opinion :-) Once you convert the first output it will also serve > as an example on how to do it, and hopefully other developers with > access to hardware could then do more conversions. > Thierry, would you want to have RGB panel converted into a bridge? If yes, I'll make a v5 with that change. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/3] drm/tegra: output: Support DRM bridges
Newer Tegra device-trees will specify a video output graph which involves
a bridge. This patch adds initial support for the DRM bridges to the
Tegra's DRM output.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/drm.h| 2 ++
drivers/gpu/drm/tegra/output.c | 13 -
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 804869799305..cccd368b6752 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -116,6 +117,7 @@ struct tegra_output {
struct device_node *of_node;
struct device *dev;
+ struct drm_bridge *bridge;
struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index a6a711d54e88..ec0cd4a1ced1 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
@@ -92,13 +93,23 @@ static irqreturn_t hpd_irq(int irq, void *data)
int tegra_output_probe(struct tegra_output *output)
{
- struct device_node *ddc, *panel;
+ struct device_node *ddc, *panel, *port;
unsigned long flags;
int err, size;
if (!output->of_node)
output->of_node = output->dev->of_node;
+ port = of_get_child_by_name(output->of_node, "port");
+ if (port) {
+ err = drm_of_find_panel_or_bridge(output->of_node, 0, 0, NULL,
+ &output->bridge);
+ of_node_put(port);
+
+ if (err)
+ return err;
+ }
+
panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
if (panel) {
output->panel = of_drm_find_panel(panel);
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm:simple_bridge_attach [simple_bridge]] *ERROR* Fix bridge driver to make connector optional!
Hi, Cc'ing Laurent On Fri, Apr 17, 2020 at 02:18:11PM +0200, H. Nikolaus Schaller wrote: > Hi Maxime, > I have started to test v5.7-rc1 and can't fully boot the GTA04 > device any more. > > What I see in the log is: > > [ 28.567840] [drm:simple_bridge_attach [simple_bridge]] *ERROR* Fix bridge > driver to make connector optional! > [ 28.567871] omapdrm omapdrm.0: unable to attach bridge > /ocp@6800/dss@4805/encoder@48050c00 > [ 28.786529] omapdrm omapdrm.0: omap_modeset_init failed: ret=-22 > [ 28.841552] omapdrm: probe of omapdrm.0 failed with error -22 > > This device uses the ti,opa362 chip which did have a dedicated > omapdss driver before (which is removed now) and which seems to > be supported by the simple_bridge now. > > The opa362 is sitting in the video out path from > > omapdrm -> venc -> opa362 -> video-out-connector. > > What does this error mean? How can it be fixed? -22 is usually EINVAL, which can be pretty much anything. A good thing to do would be to bisect to see which actual commit broke it, but if I was to bet on something I guess it would be https://lore.kernel.org/dri-devel/20200226112514.12455-1-laurent.pinch...@ideasonboard.com/ Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] backlight: lms501kf03: remove unused 'seq_sleep_in' and 'seq_up_dn'
Fix the following gcc warning:
drivers/video/backlight/lms501kf03.c:96:28: warning: ‘seq_sleep_in’
defined but not used [-Wunused-const-variable=]
static const unsigned char seq_sleep_in[] = {
^~~~
drivers/video/backlight/lms501kf03.c:92:28: warning: ‘seq_up_dn’ defined
but not used [-Wunused-const-variable=]
static const unsigned char seq_up_dn[] = {
^
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/video/backlight/lms501kf03.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/video/backlight/lms501kf03.c
b/drivers/video/backlight/lms501kf03.c
index 8ae32e3573c1..c1bd02bb8b2e 100644
--- a/drivers/video/backlight/lms501kf03.c
+++ b/drivers/video/backlight/lms501kf03.c
@@ -89,14 +89,6 @@ static const unsigned char seq_rgb_gamma[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};
-static const unsigned char seq_up_dn[] = {
- 0x36, 0x10,
-};
-
-static const unsigned char seq_sleep_in[] = {
- 0x10,
-};
-
static const unsigned char seq_sleep_out[] = {
0x11,
};
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 01/12] dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
Hi Rob, > Am 16.04.2020 um 22:41 schrieb Rob Herring : > > On Wed, 15 Apr 2020 10:35:08 +0200, "H. Nikolaus Schaller" wrote: >> The Imagination PVR/SGX GPU is part of several SoC from >> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo, >> Allwinner A83 and others. >> >> With this binding, we describe how the SGX processor is >> interfaced to the SoC (registers, interrupt etc.). >> >> In most cases, Clock, Reset and power management is handled >> by a parent node or elsewhere (e.g. code in the driver). >> >> Tested by make dt_binding_check dtbs_check >> >> Signed-off-by: H. Nikolaus Schaller >> --- >> .../devicetree/bindings/gpu/img,pvrsgx.yaml | 122 ++ >> 1 file changed, 122 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> > > My bot found errors running 'make dt_binding_check' on your patch: > > Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml: while parsing a block > mapping > in "", line 74, column 13 It turned out that there was a stray " in line 74 from the last editing phase. Will be fixed in v7. Would it be possible to make dt_binding_check not only report line/column but the contents of the line instead of ""? > did not find expected key > in "", line 117, column 21 > Documentation/devicetree/bindings/Makefile:12: recipe for target > 'Documentation/devicetree/bindings/gpu/img,pvrsgx.example.dts' failed > make[1]: *** [Documentation/devicetree/bindings/gpu/img,pvrsgx.example.dts] > Error 1 > make[1]: *** Waiting for unfinished jobs > Makefile:1264: recipe for target 'dt_binding_check' failed > make: *** [dt_binding_check] Error 2 > > See https://patchwork.ozlabs.org/patch/1270997 > > 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. BR and thanks, Nikolaus Schaller ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/7] drm/mediatek: mtk_dsi: Use simple encoder
The mtk_dsi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 869ae0a2e9f8..d68694ff00dc 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "mtk_drm_ddp_comp.h"
@@ -788,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
dsi->enabled = false;
}
-static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
- .destroy = mtk_dsi_encoder_destroy,
-};
-
static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
*dsi);
static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
@@ -1140,8 +1132,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
struct mtk_dsi *dsi)
{
int ret;
- ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
- DRM_MODE_ENCODER_DSI, NULL);
+ ret = drm_simple_encoder_init(drm, &dsi->encoder,
+ DRM_MODE_ENCODER_DSI);
if (ret) {
DRM_ERROR("Failed to encoder init to drm\n");
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/3] Support DRM bridges on NVIDIA Tegra
Hello, This small series adds initial support for the DRM bridges to NVIDIA Tegra DRM driver. This is required by newer device-trees where we model the LVDS encoder bridge properly. Changelog: v4: - Following review comments that were made by Laurent Pinchart to the v3, we now create and use the "bridge connector". v3: - Following recommendation from Sam Ravnborg, the new bridge attachment model is now being used, i.e. we ask bridge to *not* create a connector using the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. - The bridge is now created only for the RGB (LVDS) output, and only when necessary. For now we don't need bridges for HDMI or DSI outputs. - I noticed that we're leaking OF node in the panel's error code path, this is fixed now by the new patch "Don't leak OF node on error". v2: - Added the new "rgb: Don't register connector if bridge is used" patch, which hides the unused connector provided by the Tegra DRM driver when bridge is used, since bridge provides its own connector to us. - Please notice that the first "Support DRM bridges" patch was previously sent out as a standalone v1 change. Dmitry Osipenko (3): drm/tegra: output: Don't leak OF node on error drm/tegra: output: Support DRM bridges drm/tegra: output: rgb: Support LVDS encoder bridge drivers/gpu/drm/tegra/drm.h| 2 ++ drivers/gpu/drm/tegra/output.c | 22 + drivers/gpu/drm/tegra/rgb.c| 58 -- 3 files changed, 67 insertions(+), 15 deletions(-) -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 08/12] arm: dts: s5pv210: Add G3D node
Hi Jonathan,
> Am 15.04.2020 um 20:17 schrieb Jonathan Bakker :
>
> Hi Nikolaus,
>
> On 2020-04-15 5:50 a.m., H. Nikolaus Schaller wrote:
>>
>>> Am 15.04.2020 um 13:49 schrieb Krzysztof Kozlowski :
>>>
>>> On Wed, 15 Apr 2020 at 10:36, H. Nikolaus Schaller
>>> wrote:
From: Jonathan Bakker
to add support for SGX540 GPU.
>>>
>>> Do not continue the subject in commit msg like it is one sentence.
>>> These are two separate sentences, so commit msg starts with capital
>>> letter and it is sentence by itself.
>>>
>
> Sorry, that's my fault, I should know better.
Mine as well...
>
> Nikolaus took this from my testing tree and I apparently didn't have it in
> as good as state as I should have.
>
Signed-off-by: Jonathan Bakker
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/s5pv210.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/s5pv210.dtsi
b/arch/arm/boot/dts/s5pv210.dtsi
index 2ad642f51fd9..e7fc709c0cca 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -512,6 +512,21 @@ vic3: interrupt-controller@f230 {
#interrupt-cells = <1>;
};
+ g3d: g3d@f300 {
+ compatible = "samsung,s5pv210-sgx540-120";
+ reg = <0xf300 0x1>;
+ interrupt-parent = <&vic2>;
+ interrupts = <10>;
+ clock-names = "sclk";
+ clocks = <&clocks CLK_G3D>;
>>>
>>> Not part of bindings, please remove or add to the bindings.
>>
>> Well, the bindings should describe what is common for all SoC
>> and they are quite different in what they need in addition.
>>
>> Thererfore we have no "additionalProperties: false" in the
>> bindings [PATCH v6 01/12].
>>
>>>
+
+ power-domains = <&pd S5PV210_PD_G3D>;
>>>
>>> Ditto
>>
>> In this case it might be possible to add the clock/power-domains
>> etc. to a wrapper node compatible to "simple-pm-bus" or similar
>> and make the gpu a child of it.
>>
>> @Jontahan: can you please give it a try?
>>
>>
>
> The power-domains comes from a (so far) non-upstreamed power domain driver
> for s5pv210 that I've been playing around with. It's not necessary for proper
> operation as it's on by default.
>
> Looking at simple-pm-bus, I don't really understand its purpose. Is it a way
> of separating
> out a power domain from a main device's node? Or is it designed for when you
> have multiple
> devices under the same power domain?
>
> Nikolaus, I can regenerate a proper patch for you if you want that's not
> based on my testing tree.
Yes, please.
>
>>>
+
+ assigned-clocks = <&clocks MOUT_G3D>, <&clocks
DOUT_G3D>;
+ assigned-clock-rates = <0>, <6670>;
+ assigned-clock-parents = <&clocks MOUT_MPLL>;
>>>
>>> Probably this should have status disabled because you do not set
>>> regulator supply.
>
> I don't believe there is a regulator on s5pv210, if there is, then it is a
> fixed regulator with no control on both s5pv210 devices that I have.
>
> The vendor driver did use the regulator framework for its power domain
> implementation, but that definitely shouldn't be upstreamed.
Ok, this means there is no need for regulators in the bindings.
BR,
Nikolaus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/panel: remove set but not used variable 'config'
drivers/gpu/drm/panel/panel-truly-nt35597.c:493:31: warning: variable ‘config’
set but not used [-Wunused-but-set-variable]
const struct nt35597_config *config;
^~
Signed-off-by: YueHaibing
---
drivers/gpu/drm/panel/panel-truly-nt35597.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
b/drivers/gpu/drm/panel/panel-truly-nt35597.c
index 012ca62bf30e..f0ad6081570f 100644
--- a/drivers/gpu/drm/panel/panel-truly-nt35597.c
+++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
@@ -490,9 +490,7 @@ static int truly_nt35597_panel_add(struct truly_nt35597
*ctx)
{
struct device *dev = ctx->dev;
int ret, i;
- const struct nt35597_config *config;
- config = ctx->config;
for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++)
ctx->supplies[i].supply = regulator_names[i];
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
Hi all, On 15.04.20 15:04, H. Nikolaus Schaller wrote: Am 15.04.2020 um 15:02 schrieb Maxime Ripard : On Wed, Apr 15, 2020 at 02:41:52PM +0200, H. Nikolaus Schaller wrote: The kernel modules built from this project have successfully demonstrated to work with the DTS definitions from this patch set on AM335x BeagleBone Black, DM3730 and OMAP5 Pyra and Droid 4. They partially work on OMAP3530 and PandaBoard ES but that is likely a problem in the kernel driver or the (non-free) user-space libraries and binaries. Wotk for JZ4780 (CI20 board) is in progress and there is potential to extend this work to e.g. BananaPi-M3 (A83) and some Intel Poulsbo and CedarView devices. If it's not been tested on any Allwinner board yet, I'll leave it aside until it's been properly shown to work. Phillip has tested something on a83. Yes I'm currently working on the a83t demo. The kernel module is loading correctly and the clocks, interrupts and resets seems to be working correctly. I'm currently working on getting the users space driver working with the kernel driver. This is hopefully done soon. I'm a bit skeptical on that one since it doesn't even list the interrupts connected to the GPU that the binding mandates. I think he left it out for a future update. But best he comments himself. I'm currently working on those bindings. They are now 90% done, but they are not finished till now. Currently there is some mainline support missing to add the full binding. The A83T and also the A31/A31s have a GPU Power Off Gating Register in the R_PRCM module, that is not supported right now in Mainline. The Register need to be written when the GPU is powered on and off. @Maxime: I totally agree on your point that a demo needs to be provided before the related DTS patches should be provided. That's the reason why I added the gpu placeholder patches. Do you have an idea how a driver for the R_PRCM stuff can look like? I'm not that experienced with the clock driver framework. The big question is right now how to proceed with the A83T and A31s patches. I see there three options, which one do you prefer?: 1. Provide now placeholder patches and send new patches, if everything is clear and other things are mainlined 2. Provide now patches as complete as possible and provide later patches to complete them when the R_PRCM things are mainlined 3. Leave them out, till the related work is mainlined and the bindings are final. Since this GPU IP core is very flexible and the SOC manufactures can configure it on their needs, I think the binding will extend in the future. For example the SGX544 GPU is available in different configurations: there is a SGX544 core and SGX544MPx core. The x stands for the count of the USSE (Universal Scalable Shader Engine) cores. For example the GPU in the A83T is a MP1 and the A31/A31s a MP2. In addition to that some of the GPU's have also a 2D engine. There might be even more differences in the GPU's that we don't know right now and should be described in the Devicetree, but that's a different topic that we should keep in mind. Cheers Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 1/4] backlight: qcom-wled: convert the wled bindings to .yaml format
On 2020-04-15 20:39, Rob Herring wrote: On Tue, Apr 07, 2020 at 09:17:07PM +0530, Kiran Gunda wrote: Convert the qcom-wled bindings from .txt to .yaml format. Also replace PM8941 to WLED3 and PMI8998 to WLED4. Signed-off-by: Kiran Gunda Signed-off-by: Subbaraman Narayanamurthy Acked-by: Daniel Thompson --- .../bindings/leds/backlight/qcom-wled.txt | 154 .../bindings/leds/backlight/qcom-wled.yaml | 201 + 2 files changed, 201 insertions(+), 154 deletions(-) delete mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml new file mode 100644 index 000..770e780 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -0,0 +1,201 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/qcom-wled.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for Qualcomm Technologies, Inc. WLED driver + +maintainers: + - Bjorn Andersson + - Kiran Gunda + +description: | + WLED (White Light Emitting Diode) driver is used for controlling display + backlight that is part of PMIC on Qualcomm Technologies, Inc. reference + platforms. The PMIC is connected to the host processor via SPMI bus. + +properties: + compatible: +enum: + - qcom,pm8941-wled + - qcom,pmi8998-wled + - qcom,pm660l-wled + + reg: +maxItems: 1 + + default-brightness: +description: + brightness value on boot. +minimum: 0 +maximum: 4095 +default: 2048 + + label: true + + qcom,cs-out: +description: + enable current sink output. + This property is supported only for WLED3. +type: boolean + + qcom,cabc: +description: + enable content adaptive backlight control. +type: boolean + + qcom,ext-gen: +description: + use externally generated modulator signal to dim. + This property is supported only for WLED3. +type: boolean + + qcom,current-limit: +description: + mA; per-string current limit. + This property is supported only for WLED3. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +default: 20 +minimum: 0 +maximum: 25 +multipleOf: 1 No point in defining a multiple of 1. + + qcom,current-limit-microamp: +description: + uA; per-string current limit. +default: 25 +minimum: 0 +maximum: 3 +multipleOf: 25 + + qcom,current-boost-limit: +description: + mA; boost current limit. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + + qcom,switching-freq: +description: + kHz; switching frequency. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200, 4800, 9600 ] + + qcom,ovp: +description: + V; Over-voltage protection limit. + This property is supported only for WLED3. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 27, 29, 32, 35 ] + - default: 29 + + qcom,ovp-millivolt: +description: + Over-voltage protection limit. This property is for WLED4 only. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 18100, 19600, 29600, 31100 ] + - default: 29600 + + qcom,num-strings: +description: + number of led strings attached. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + + qcom,enabled-strings: +description: + Array of the WLED strings numbered from 0 to 3. Each + string of leds are operated individually. Specify the + list of strings used by the device. Any combination of + led strings can be used. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32-array +minItems: 1 +maxItems: 4 + + qcom,external-pfet: +description: + Specify if external PFET control for short circuit + protection is used. This property is supported only + for WLED4. +type: boolean + + qcom,auto-string-detection: +description: + Enables auto-detection of the WLED string configuration. + This feature is not supported for WLED3. +type: boolean + +allOf: + - if: + properties: +compatible: + contains: +const: qcom,pm8941-wled + +then: + properties: +qcom,current-boost-limit: + enum: [ 105, 385, 525, 805, 980, 1260, 1400, 1680 ] + default: 805 + +qcom,switching-freq: + default: 1600 + +qcom,num-strings: + enum: [ 1, 2, 3 ] + +interrupts: + items: +- description: over voltage protection interrupt. + +
Re: [PATCH v2 05/17] drm/msm/dpu: Use OPP API to set clk/perf state
On 4/17/2020 11:47 PM, Matthias Kaehlcke wrote: Hi Rajendra, I have essentially the same comments as for "tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state" (https://patchwork.kernel.org/patch/11495209/). about error handling of 'dev_pm_opp_of_add_table' and misleading struct member names 'opp'/'opp_table'. Please apply the requested changes to the entire series unless you disagree (we can keep the discussion in the patch referenced above). Thanks, yes, I will apply those changes across the series and respin. Will wait a few days to see I get any more feedback. -- 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
