The driver returns an error when devm_phy_optional_get() fails leaving
the previously enabled clock turned on. Change order and enable the
clock only after the phy has been acquired.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
@@ -226,6 +227,16 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)returnPTR_ERR(hdmi->grf_clk);}+hdmi->hclk_clk=devm_clk_get(hdmi->dev,"hclk");+if(PTR_ERR(hdmi->hclk_clk)==-ENOENT){+hdmi->hclk_clk=NULL;+}elseif(PTR_ERR(hdmi->hclk_clk)==-EPROBE_DEFER){+return-EPROBE_DEFER;+}elseif(IS_ERR(hdmi->hclk_clk)){+DRM_DEV_ERROR(hdmi->dev,"failed to get hclk_clk clock\n");+returnPTR_ERR(hdmi->hclk_clk);+}+hdmi->avdd_0v9=devm_regulator_get(hdmi->dev,"avdd-0v9");if(IS_ERR(hdmi->avdd_0v9))returnPTR_ERR(hdmi->avdd_0v9);
@@ -593,6 +604,13 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,gotoerr_clk;}+ret=clk_prepare_enable(hdmi->hclk_clk);+if(ret){+DRM_DEV_ERROR(hdmi->dev,"Failed to enable HDMI hclk clock: %d\n",+ret);+gotoerr_clk;+}+if(hdmi->chip_data==&rk3568_chip_data){regmap_write(hdmi->regmap,RK3568_GRF_VO_CON1,HIWORD_UPDATE(RK3568_HDMI_SDAIN_MSK|
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../boot/dts/rockchip/rk3568-evb1-v10.dts | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
@@ -44,11 +44,12 @@ properties:items:-{}-{}-# The next three clocks are all optional, but shall be specified in this+# The next four clocks are all optional, but shall be specified in this# order when present.-description:The HDMI CEC controller main clock-description:Power for GRF IO-description:External clock for some HDMI PHY+-description:hclkclock-names:minItems:2
@@ -4,9 +4,10 @@# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.rockchipdrm-y:=rockchip_drm_drv.orockchip_drm_fb.o\-rockchip_drm_gem.orockchip_drm_vop.orockchip_vop_reg.o+rockchip_drm_gem.orockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION)+=rockchip_drm_fbdev.o+rockchipdrm-$(CONFIG_ROCKCHIP_VOP)+=rockchip_drm_vop.orockchip_vop_reg.orockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP)+=analogix_dp-rockchip.orockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP)+=cdn-dp-core.ocdn-dp-reg.orockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI)+=dw_hdmi-rockchip.o
The pixel clocks dclk_vop[012] can be clocked from hpll, vpll, gpll or
cpll. gpll and cpll also drive many other clocks, so changing the
dclk_vop[012] clocks could change these other clocks as well. Drop
CLK_SET_RATE_PARENT to fix that. With this change the VOP2 driver can
only adjust the pixel clocks with the divider between the PLL and the
dclk_vop[012] which means the user may have to adjust the PLL clock to a
suitable rate using the assigned-clock-rate device tree property.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/clk/rockchip/clk-rk3568.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210707120323.401785-2-benjamin.gaignard@collabora.com
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 +
1 file changed, 1 insertion(+)
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock. The clock
name "vpll" is left for compatibility to old device trees.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 29 ++++++++++++---------
1 file changed, 16 insertions(+), 13 deletions(-)
@@ -196,14 +196,17 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)returnPTR_ERR(hdmi->regmap);}-hdmi->vpll_clk=devm_clk_get(hdmi->dev,"vpll");-if(PTR_ERR(hdmi->vpll_clk)==-ENOENT){-hdmi->vpll_clk=NULL;-}elseif(PTR_ERR(hdmi->vpll_clk)==-EPROBE_DEFER){+hdmi->ref_clk=devm_clk_get(hdmi->dev,"ref");+if(PTR_ERR(hdmi->ref_clk)==-ENOENT)+hdmi->ref_clk=devm_clk_get(hdmi->dev,"vpll");++if(PTR_ERR(hdmi->ref_clk)==-ENOENT){+hdmi->ref_clk=NULL;+}elseif(PTR_ERR(hdmi->ref_clk)==-EPROBE_DEFER){return-EPROBE_DEFER;-}elseif(IS_ERR(hdmi->vpll_clk)){-DRM_DEV_ERROR(hdmi->dev,"failed to get vpll clock\n");-returnPTR_ERR(hdmi->vpll_clk);+}elseif(IS_ERR(hdmi->ref_clk)){+DRM_DEV_ERROR(hdmi->dev,"failed to get reference clock\n");+returnPTR_ERR(hdmi->ref_clk);}hdmi->grf_clk=devm_clk_get(hdmi->dev,"grf");
The VOP2 is the display output controller on the RK3568. Add the node
for it to the dtsi file along with the required display-subsystem node
and the iommu node.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm64/boot/dts/rockchip/rk3566.dtsi | 4 ++
arch/arm64/boot/dts/rockchip/rk3568.dtsi | 4 ++
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 50 ++++++++++++++++++++++++
include/dt-bindings/soc/rockchip,vop2.h | 14 +++++++
4 files changed, 72 insertions(+)
create mode 100644 include/dt-bindings/soc/rockchip,vop2.h
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
for the HDMI port. add support for these to the driver for boards which
have them supplied by switchable regulators.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 41 +++++++++++++++++++--
1 file changed, 38 insertions(+), 3 deletions(-)
@@ -28,6 +28,17 @@ properties:reg-io-width:const:4+avdd-0v9-supply:+description:+A 0.9V supply that powers up the SoC internal circuitry. The actual pin name+varies between the different SoCs and is usually HDMI_TX_AVDD_0V9 or sometimes+HDMI_AVDD_1V0.++avdd-1v8-supply:+description:+A 1.8V supply that powers up the SoC internal circuitry. The pin name on the+SoC usually is HDMI_TX_AVDD_1V8.+clocks:minItems:2items:
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Add a device node to drm_encoder which corresponds with the port node
in the DT description of the encoder. This allows drivers to find the
of_graph link between a crtc and an encoder.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
include/drm/drm_encoder.h | 2 ++
1 file changed, 2 insertions(+)
The reference clock for the HDMI controller has been renamed to 'ref',
the previous 'vpll' name is only left for compatibility in the driver.
Rename the clock to the new name.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
None of the upstream device tree files has a "unwedge" pinctrl
specified. Make it optional.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 +
1 file changed, 1 insertion(+)
@@ -73,6 +73,7 @@ properties:The unwedge pinctrl entry shall drive the DDC SDA line low. This isintended to work around a hardware errata that can cause the DDC I2Cbus to be wedged.+minItems:1items:-const:default-const:unwedge
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On the rk3568 we have this (simplified) situation:
.--------. .-----. .---------.
-| hpll |--.--| /n |----|dclk_vop0|-
`--------´ | `-----´ `---------´
| .-----. .---------.
`--| /m |----|dclk_vop1|-
| `-----´ `---------´
| .---------.
`-------------|hdmi_ref |-
`---------´
For the HDMI to work the HDMI reference clock needs to be the same as the
pixel clock which means the dividers have be set to one. The last patch removed
the CLK_SET_RATE_PARENT flag from the pixel clocks which means the hpll is not
changed on pixel clock changes. In order to allow the HDMI controller to
set a suitable PLL rate we now add the CLK_SET_RATE_PARENT flag to the
HDMI reference clock. With this the flow becomes:
1) HDMI controller driver sets the rate to its pixel clock which means
hpll is set to the pixel clock
2) VOP2 driver sets dclk_vop[012] to the pixel clock. As this can't change
the hpll clock anymore this means only the divider is adjusted to the
desired value of dividing by one.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/clk/rockchip/clk-rk3568.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 31 +++++++++++++++++++++
1 file changed, 31 insertions(+)
From: Michael Riesch <redacted>
Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.
Signed-off-by: Michael Riesch <redacted>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../boot/dts/rockchip/rk3566-quartz64-a.dts | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../display/rockchip/rockchip-vop2.yaml | 146 ++++++++++++++++++
1 file changed, 146 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
@@ -0,0 +1,146 @@+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause+%YAML1.2+---+$id:http://devicetree.org/schemas/display/rockchip/rockchip-vop2.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Rockchip SoC display controller (VOP2)++description:+VOP2 (Video Output Processor v2) is the display controller for the Rockchip+series of SoCs which transfers the image data from a video memory+buffer to an external LCD interface.++maintainers:+-Sandy Huang <hjc@rock-chips.com>+-Heiko Stuebner <heiko@sntech.de>++properties:+compatible:+enum:+-rockchip,rk3566-vop+-rockchip,rk3568-vop++reg:+minItems:1+items:+-description:+Must contain one entry corresponding to the base address and length+of the register space.+-description:+Can optionally contain a second entry corresponding to+the CRTC gamma LUT address.++interrupts:+maxItems:1+description:+The VOP interrupt is shared by several interrupt sources, such as+frame start (VSYNC), line flag and other status interrupts.++clocks:+items:+-description:Clock for ddr buffer transfer.+-description:Clock for the ahb bus to R/W the phy regs.+-description:Pixel clock for video port 0.+-description:Pixel clock for video port 1.+-description:Pixel clock for video port 2.++clock-names:+items:+-const:aclk_vop+-const:hclk_vop+-const:dclk_vp0+-const:dclk_vp1+-const:dclk_vp2++rockchip,grf:+$ref:/schemas/types.yaml#/definitions/phandle+description:+Phandle to GRF regs used for misc control++ports:+$ref:/schemas/graph.yaml#/properties/port++properties:+port@0:+$ref:/schemas/graph.yaml#/properties/port+description:+Output endpoint of VP0++port@1:+$ref:/schemas/graph.yaml#/properties/port+description:+Output endpoint of VP1++port@:+$ref:/schemas/graph.yaml#/properties/port+description:+Output endpoint of VP2++assigned-clocks:true++assigned-clock-rates:true++assigned-clock-parents:true++iommus:+maxItems:1++power-domains:+maxItems:1++required:+-compatible+-reg+-interrupts+-clocks+-clock-names+-ports++additionalProperties:false++examples:+-|+#include <dt-bindings/clock/rk3568-cru.h>+#include <dt-bindings/interrupt-controller/arm-gic.h>+#include <dt-bindings/power/rk3568-power.h>+bus {+#address-cells = <2>;+#size-cells = <2>;+vop:vop@fe040000 {+compatible = "rockchip,rk3568-vop";+reg = <0x0 0xfe040000 0x0 0x3000>, <0x0 0xfe044000 0x0 0x1000>;+interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;+clocks = <&cru ACLK_VOP>,+<&cru HCLK_VOP>,+<&cru DCLK_VOP0>,+<&cru DCLK_VOP1>,+<&cru DCLK_VOP2>;+clock-names = "aclk_vop",+"hclk_vop",+"dclk_vp0",+"dclk_vp1",+"dclk_vp2";+power-domains = <&power RK3568_PD_VO>;+iommus = <&vop_mmu>;+vop_out:ports {+#address-cells = <1>;+#size-cells = <0>;+vp0:port@0 {+reg = <0>;+#address-cells = <1>;+#size-cells = <0>;+};+vp1:port@1 {+reg = <1>;+#address-cells = <1>;+#size-cells = <0>;+};+vp2:port@2 {+reg = <2>;+#address-cells = <1>;+#size-cells = <0>;+};+};+};+};
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Date: 2021-12-20 11:51:39
On Montag, 20. Dezember 2021 12:06:08 CET Sascha Hauer wrote:
Third round of patches and last one for this year. I hopefully integrated
all review feedback. Additionally the driver is now fully converted to
regmap, so no struct vop_reg necessary anymore.
Sascha
Changes since v2:
- Add pin names to HDMI supply pin description
- Add hclk support to HDMI driver
- Dual license rockchip-vop2 binding, update binding
- Add HDMI connector to board dts files
- drop unnecessary gamma_lut registers from vop2
- Update dclk_vop[012] clock handling, no longer hacks needed
- Complete regmap conversion
Hi Sascha,
for future reference, you can add `-v 3` to your git format-patch
command line to mark the whole patch series as PATCH v3 and not
just the cover letter.
Thanks for your continued work on this,
Nicolas Frattaroli
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2021-12-20 14:27:47
On Mon, 20 Dec 2021 12:06:16 +0100, Sascha Hauer wrote:
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml: properties:clock-names:items: 'oneOf' conditional failed, one must be fixed:
[{}, {}, {'enum': ['cec', 'grf', 'ref']}, {'enum': ['grf', 'ref']}, {'const': ['ref']}] is not of type 'object'
['ref'] is not of type 'string'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml: ignoring, error in schema: properties: clock-names: items
warning: no schema found in file: ./Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.example.dt.yaml:0:0: /example-0/hdmi@ff980000: failed to match any schema with compatible: ['rockchip,rk3288-dw-hdmi']
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1570972
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Running 'make dtbs_check' with the schema in this patch gives the
following warnings. Consider if they are expected or the schema is
incorrect. These may not be new warnings.
Note that it is not yet a requirement to have 0 warnings for dtbs_check.
This will change in the future.
Full log is available here: https://patchwork.ozlabs.org/patch/1570969
hdmi@200a0000: clock-names:0: 'iahb' was expected
arch/arm/boot/dts/rk3228-evb.dt.yaml
arch/arm/boot/dts/rk3229-evb.dt.yaml
arch/arm/boot/dts/rk3229-xms6.dt.yaml
hdmi@200a0000: clock-names:1: 'isfr' was expected
arch/arm/boot/dts/rk3228-evb.dt.yaml
arch/arm/boot/dts/rk3229-evb.dt.yaml
arch/arm/boot/dts/rk3229-xms6.dt.yaml
hdmi@200a0000: pinctrl-names: ['default'] is too short
arch/arm/boot/dts/rk3228-evb.dt.yaml
arch/arm/boot/dts/rk3229-evb.dt.yaml
arch/arm/boot/dts/rk3229-xms6.dt.yaml
hdmi@200a0000: ports:port: 'endpoint@1' is a required property
arch/arm/boot/dts/rk3229-xms6.dt.yaml
hdmi@200a0000: Unevaluated properties are not allowed ('reg', 'interrupts', 'pinctrl-names', 'pinctrl-0', 'resets', 'reset-names', 'ports' were unexpected)
arch/arm/boot/dts/rk3228-evb.dt.yaml
arch/arm/boot/dts/rk3229-evb.dt.yaml
arch/arm/boot/dts/rk3229-xms6.dt.yaml
hdmi@ff3c0000: interrupts: [[0, 35, 4], [0, 71, 4]] is too long
arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-evb.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-pc.dt.yaml
hdmi@ff3c0000: pinctrl-names: ['default'] is too short
arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-evb.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-pc.dt.yaml
hdmi@ff3c0000: ports:port: 'endpoint@0' is a required property
arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-pc.dt.yaml
hdmi@ff3c0000: ports:port: 'endpoint@1' is a required property
arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-pc.dt.yaml
hdmi@ff3c0000: Unevaluated properties are not allowed ('reg', 'interrupts', 'pinctrl-names', 'pinctrl-0', '#sound-dai-cells', 'ports' were unexpected)
arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-evb.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-pc.dt.yaml
hdmi@ff940000: clock-names:4: 'vpll' was expected
arch/arm64/boot/dts/rockchip/rk3399-evb.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-ficus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-firefly.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-inx.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-kd.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-neo4.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-orangepi.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399pro-rock-pi-n10.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock960.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a-plus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b-plus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rockpro64-v2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-roc-pc-mezzanine.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-roc-pc-plus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-sapphire.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dt.yaml
hdmi@ff940000: pinctrl-names: ['default'] is too short
arch/arm64/boot/dts/rockchip/rk3399-ficus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-firefly.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-neo4.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399pro-rock-pi-n10.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock960.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a-plus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b-plus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rockpro64-v2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-roc-pc-mezzanine.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-roc-pc-plus.dt.yaml
hdmi@ff980000: pinctrl-names: ['default'] is too short
arch/arm/boot/dts/rk3288-firefly-reload.dt.yaml
arch/arm/boot/dts/rk3288-rock-pi-n8.dt.yaml
arch/arm/boot/dts/rk3288-tinker-s.dt.yaml
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2021-12-20 14:27:50
On Mon, 20 Dec 2021 12:06:19 +0100, Sascha Hauer wrote:
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../display/rockchip/rockchip-vop2.yaml | 146 ++++++++++++++++++
1 file changed, 146 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.example.dt.yaml: vop@fe040000: ports: Unevaluated properties are not allowed ('port@0', 'port@1', 'port@2' were unexpected)
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1570971
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2021-12-20 14:27:52
On Mon, 20 Dec 2021 12:06:15 +0100, Sascha Hauer wrote:
None of the upstream device tree files has a "unwedge" pinctrl
specified. Make it optional.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 +
1 file changed, 1 insertion(+)
Running 'make dtbs_check' with the schema in this patch gives the
following warnings. Consider if they are expected or the schema is
incorrect. These may not be new warnings.
Note that it is not yet a requirement to have 0 warnings for dtbs_check.
This will change in the future.
Full log is available here: https://patchwork.ozlabs.org/patch/1570970
hdmi@200a0000: clock-names:0: 'iahb' was expected
arch/arm/boot/dts/rk3228-evb.dt.yaml
arch/arm/boot/dts/rk3229-evb.dt.yaml
arch/arm/boot/dts/rk3229-xms6.dt.yaml
hdmi@200a0000: clock-names:1: 'isfr' was expected
arch/arm/boot/dts/rk3228-evb.dt.yaml
arch/arm/boot/dts/rk3229-evb.dt.yaml
arch/arm/boot/dts/rk3229-xms6.dt.yaml
hdmi@200a0000: ports:port: 'endpoint@1' is a required property
arch/arm/boot/dts/rk3229-xms6.dt.yaml
hdmi@200a0000: Unevaluated properties are not allowed ('reg', 'interrupts', 'pinctrl-0', 'resets', 'reset-names', 'ports' were unexpected)
arch/arm/boot/dts/rk3228-evb.dt.yaml
arch/arm/boot/dts/rk3229-evb.dt.yaml
arch/arm/boot/dts/rk3229-xms6.dt.yaml
hdmi@ff3c0000: interrupts: [[0, 35, 4], [0, 71, 4]] is too long
arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-evb.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-pc.dt.yaml
hdmi@ff3c0000: ports:port: 'endpoint@0' is a required property
arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-pc.dt.yaml
hdmi@ff3c0000: ports:port: 'endpoint@1' is a required property
arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-pc.dt.yaml
hdmi@ff3c0000: Unevaluated properties are not allowed ('reg', 'interrupts', 'pinctrl-0', '#sound-dai-cells', 'ports' were unexpected)
arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-evb.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dt.yaml
arch/arm64/boot/dts/rockchip/rk3328-roc-pc.dt.yaml
hdmi@ff940000: clock-names:4: 'vpll' was expected
arch/arm64/boot/dts/rockchip/rk3399-evb.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-ficus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-firefly.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-dumo.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-inx.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-kd.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-captain.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-khadas-edge-v.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-neo4.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-orangepi.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399pro-rock-pi-n10.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock960.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a-plus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b-plus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-rockpro64-v2.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-roc-pc-mezzanine.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-roc-pc-plus.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-sapphire.dt.yaml
arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dt.yaml
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2021-12-21 14:31:27
On Mon, Dec 20, 2021 at 12:06:16PM +0100, Sascha Hauer wrote:
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock.
The problem with this series is it breaks an old kernel with new dt. You
can partially mitigate that with stable kernel backport, but IMO keeping
the old name is not a burden to maintain.
And given RK3399 is widely used including by me, we should not be
breaking compatibility.
So allow for ref in addition to vpll if you like, but only use 'ref' for
new users. And add a comment in the schema to that effect.
Rob
From: Rob Herring <robh@kernel.org> Date: 2021-12-21 14:33:58
On Mon, Dec 20, 2021 at 12:06:19PM +0100, Sascha Hauer wrote:
quoted hunk
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
.../display/rockchip/rockchip-vop2.yaml | 146 ++++++++++++++++++
1 file changed, 146 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
@@ -0,0 +1,146 @@+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause+%YAML1.2+---+$id:http://devicetree.org/schemas/display/rockchip/rockchip-vop2.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Rockchip SoC display controller (VOP2)++description:+VOP2 (Video Output Processor v2) is the display controller for the Rockchip+series of SoCs which transfers the image data from a video memory+buffer to an external LCD interface.++maintainers:+-Sandy Huang <hjc@rock-chips.com>+-Heiko Stuebner <heiko@sntech.de>++properties:+compatible:+enum:+-rockchip,rk3566-vop+-rockchip,rk3568-vop++reg:+minItems:1+items:+-description:+Must contain one entry corresponding to the base address and length+of the register space.+-description:+Can optionally contain a second entry corresponding to+the CRTC gamma LUT address.++interrupts:+maxItems:1+description:+The VOP interrupt is shared by several interrupt sources, such as+frame start (VSYNC), line flag and other status interrupts.++clocks:+items:+-description:Clock for ddr buffer transfer.+-description:Clock for the ahb bus to R/W the phy regs.+-description:Pixel clock for video port 0.+-description:Pixel clock for video port 1.+-description:Pixel clock for video port 2.++clock-names:+items:+-const:aclk_vop+-const:hclk_vop
_vop is redundant.
+ - const: dclk_vp0
+ - const: dclk_vp1
+ - const: dclk_vp2
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to GRF regs used for misc control
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/port
Am Montag, 20. Dezember 2021, 12:06:28 CET schrieb Sascha Hauer:
quoted hunk
Add a device node to drm_encoder which corresponds with the port node
in the DT description of the encoder. This allows drivers to find the
of_graph link between a crtc and an encoder.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
include/drm/drm_encoder.h | 2 ++
1 file changed, 2 insertions(+)
Is this the port that gets used in patch 3/22?
It looks like it.
So this would break bisectability. Can we order patches
sequentially so that git bisect keeps working.
Thanks
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Dec 21, 2021 at 10:31:23AM -0400, Rob Herring wrote:
On Mon, Dec 20, 2021 at 12:06:16PM +0100, Sascha Hauer wrote:
quoted
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock.
The problem with this series is it breaks an old kernel with new dt. You
can partially mitigate that with stable kernel backport, but IMO keeping
the old name is not a burden to maintain.
As suggested I only removed vpll from the binding document, but not from
the code. The code still handles the old binding as well.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2021-12-22 13:53:09
On Wed, Dec 22, 2021 at 6:47 AM Sascha Hauer [off-list ref] wrote:
On Tue, Dec 21, 2021 at 10:31:23AM -0400, Rob Herring wrote:
quoted
On Mon, Dec 20, 2021 at 12:06:16PM +0100, Sascha Hauer wrote:
quoted
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock.
The problem with this series is it breaks an old kernel with new dt. You
can partially mitigate that with stable kernel backport, but IMO keeping
the old name is not a burden to maintain.
As suggested I only removed vpll from the binding document, but not from
the code. The code still handles the old binding as well.
The problem is updating rk3399.dtsi. That change won't work with old
kernels because they won't look for 'ref'. Since you shouldn't change
it, the binding needs to cover both the old and new cases.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Am Mittwoch, 22. Dezember 2021, 14:52:51 CET schrieb Rob Herring:
On Wed, Dec 22, 2021 at 6:47 AM Sascha Hauer [off-list ref] wrote:
quoted
On Tue, Dec 21, 2021 at 10:31:23AM -0400, Rob Herring wrote:
quoted
On Mon, Dec 20, 2021 at 12:06:16PM +0100, Sascha Hauer wrote:
quoted
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock.
The problem with this series is it breaks an old kernel with new dt. You
can partially mitigate that with stable kernel backport, but IMO keeping
the old name is not a burden to maintain.
As suggested I only removed vpll from the binding document, but not from
the code. The code still handles the old binding as well.
The problem is updating rk3399.dtsi. That change won't work with old
kernels because they won't look for 'ref'. Since you shouldn't change
it, the binding needs to cover both the old and new cases.
is "newer dt with old kernel" really a case these days?
I do understand the new kernel old dt case - for example with the
dtb being provided by firmware.
But which user would get the idea of updating only the devicetree
while staying with an older kernel?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Date: 2021-12-22 19:44:36
On Mittwoch, 22. Dezember 2021 20:39:58 CET Heiko Stübner wrote:
Am Mittwoch, 22. Dezember 2021, 14:52:51 CET schrieb Rob Herring:
quoted
On Wed, Dec 22, 2021 at 6:47 AM Sascha Hauer [off-list ref] wrote:
quoted
On Tue, Dec 21, 2021 at 10:31:23AM -0400, Rob Herring wrote:
quoted
On Mon, Dec 20, 2021 at 12:06:16PM +0100, Sascha Hauer wrote:
quoted
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock.
The problem with this series is it breaks an old kernel with new dt. You
can partially mitigate that with stable kernel backport, but IMO keeping
the old name is not a burden to maintain.
As suggested I only removed vpll from the binding document, but not from
the code. The code still handles the old binding as well.
The problem is updating rk3399.dtsi. That change won't work with old
kernels because they won't look for 'ref'. Since you shouldn't change
it, the binding needs to cover both the old and new cases.
is "newer dt with old kernel" really a case these days?
I do understand the new kernel old dt case - for example with the
dtb being provided by firmware.
But which user would get the idea of updating only the devicetree
while staying with an older kernel?
Side-by-side installations of LTS kernels with new kernels. LTS kernel
uses same DT as new kernel because distribution set it up this way.
Other scenario: user wants to modify their device tree. They download
the latest kernel sources from kernel.org because they can't use over-
lays and they don't want to fiddle with decompiled device trees.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2021-12-22 19:57:17
On Wed, Dec 22, 2021 at 3:40 PM Heiko Stübner [off-list ref] wrote:
Am Mittwoch, 22. Dezember 2021, 14:52:51 CET schrieb Rob Herring:
quoted
On Wed, Dec 22, 2021 at 6:47 AM Sascha Hauer [off-list ref] wrote:
quoted
On Tue, Dec 21, 2021 at 10:31:23AM -0400, Rob Herring wrote:
quoted
On Mon, Dec 20, 2021 at 12:06:16PM +0100, Sascha Hauer wrote:
quoted
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock.
The problem with this series is it breaks an old kernel with new dt. You
can partially mitigate that with stable kernel backport, but IMO keeping
the old name is not a burden to maintain.
As suggested I only removed vpll from the binding document, but not from
the code. The code still handles the old binding as well.
The problem is updating rk3399.dtsi. That change won't work with old
kernels because they won't look for 'ref'. Since you shouldn't change
it, the binding needs to cover both the old and new cases.
is "newer dt with old kernel" really a case these days?
I've had complaints about it. In particular from SUSE folks that were
shipping new dtbs with old (stable) kernels.
I do understand the new kernel old dt case - for example with the
dtb being provided by firmware.
Yes, so update your firmware that contains a newer dtb and then you
stop booting or a device stops working.
But which user would get the idea of updating only the devicetree
while staying with an older kernel?
Any synchronization between firmware and OS updates is a problem.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Piotr Oniszczuk <hidden> Date: 2022-01-19 11:30:04
Wiadomość napisana przez Sascha Hauer [off-list ref] w dniu 20.12.2021, o godz. 12:06:
Third round of patches and last one for this year. I hopefully integrated
all review feedback. Additionally the driver is now fully converted to
regmap, so no struct vop_reg necessary anymore.
Sascha
Changes since v2:
- Add pin names to HDMI supply pin description
- Add hclk support to HDMI driver
- Dual license rockchip-vop2 binding, update binding
- Add HDMI connector to board dts files
- drop unnecessary gamma_lut registers from vop2
- Update dclk_vop[012] clock handling, no longer hacks needed
- Complete regmap conversion
Sascha
I'm using you VOP2 code on rk3566 tvbox (x96-x6) with very good results.
I have just few questions:
1. how support for CEC looks/prospects (plans for future, not in this code, expecting others should implement, etc)?
2. VOP2 code works nice for me for x11/glamour and for EGLFS with EGL DMAbuf rendering by Mesa EGL_LINUX_DMA_BUF_EXT.
I have issue however with app. rendering to DRM planes (GUI is DRM plane1, video is DRM pane2).
My ppp starts/works without any errors in log - but screen stays with kernel messages content.
(it looks to me like i.e. app renders to DRM plane but DRM display driver not pass it to CRTC. just wild guess here...).
3. in kernel dmesg I have many:
"rockchip-drm display-subsystem: [drm] *ERROR* Unsupported format modifier 0x810000000000001".
It comes from MESA i think - but i suspect because VOP2 provides unknown/wrong DRM modifier to mesa?.
I'm not sure how to progress with this (talk to you or involve MESA devs or wait for VOP2 v4)?
Again: great work with VOP2 on rk356x!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Piotr,
On Wed, Jan 19, 2022 at 12:29:49PM +0100, Piotr Oniszczuk wrote:
quoted
Wiadomość napisana przez Sascha Hauer [off-list ref] w dniu 20.12.2021, o godz. 12:06:
Third round of patches and last one for this year. I hopefully integrated
all review feedback. Additionally the driver is now fully converted to
regmap, so no struct vop_reg necessary anymore.
Sascha
Changes since v2:
- Add pin names to HDMI supply pin description
- Add hclk support to HDMI driver
- Dual license rockchip-vop2 binding, update binding
- Add HDMI connector to board dts files
- drop unnecessary gamma_lut registers from vop2
- Update dclk_vop[012] clock handling, no longer hacks needed
- Complete regmap conversion
Sascha
I'm using you VOP2 code on rk3566 tvbox (x96-x6) with very good results.
I have just few questions:
1. how support for CEC looks/prospects (plans for future, not in this code, expecting others should implement, etc)?
I had to google what CEC actually is. We don't have plans supporting it.
It looks like this is a matter of the HDMI driver supporting this and
not bound to the rockchip driver.
2. VOP2 code works nice for me for x11/glamour and for EGLFS with EGL DMAbuf rendering by Mesa EGL_LINUX_DMA_BUF_EXT.
I have issue however with app. rendering to DRM planes (GUI is DRM plane1, video is DRM pane2).
My ppp starts/works without any errors in log - but screen stays with kernel messages content.
(it looks to me like i.e. app renders to DRM plane but DRM display driver not pass it to CRTC. just wild guess here...).
You enabled the panfrost driver with other patches, right?
3. in kernel dmesg I have many:
"rockchip-drm display-subsystem: [drm] *ERROR* Unsupported format modifier 0x810000000000001".
This message is correct. This corresponds to
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED and the VOP2 driver doesn't
support this. I have a similar problem here with
weston-simple-dmabuf-egl. By default this uses DRM_FORMAT_XRGB8888
which ends up being PIPE_FORMAT_B8G8R8_UNORM in MESA. In
panfrost_afbc_format() we have:
/* Don't allow swizzled formats on v7 */
switch (format) {
case PIPE_FORMAT_B8G8R8A8_UNORM:
case PIPE_FORMAT_B8G8R8X8_UNORM:
case PIPE_FORMAT_A8R8G8B8_UNORM:
case PIPE_FORMAT_X8R8G8B8_UNORM:
case PIPE_FORMAT_X8B8G8R8_UNORM:
case PIPE_FORMAT_A8B8G8R8_UNORM:
case PIPE_FORMAT_B8G8R8_UNORM:
case PIPE_FORMAT_B5G6R5_UNORM:
if (dev->arch >= 7)
return PIPE_FORMAT_NONE;
break;
default:
break;
}
This means the driver won't do AFBC with that format and picks
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED instead. Now weston is
clever enough to not pass that into the VOP2 driver, apparently your
application is not and as a result you see that message.
In weston-simple-dmabuf-egl I can pass a suitable format on the command
line, in my case I use DRM_FORMAT_ABGR8888 (which becomes
PIPE_FORMAT_R8G8B8A8_UNORM). With this the panfrost driver does AFBC
which then can be rendered in the VOP2 cluster window overlay.
It comes from MESA i think - but i suspect because VOP2 provides
unknown/wrong DRM modifier to mesa?
Nope, the modifiers the VOP2 driver propagates are correct. It doesn't
claim to support DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Piotr Oniszczuk <hidden> Date: 2022-01-21 15:43:47
Wiadomość napisana przez Sascha Hauer [off-list ref] w dniu 21.01.2022, o godz. 11:32:
quoted
1. how support for CEC looks/prospects (plans for future, not in this code, expecting others should implement, etc)?
I had to google what CEC actually is. We don't have plans supporting it.
It looks like this is a matter of the HDMI driver supporting this and
not bound to the rockchip driver.
Ah ok. sure. got it!
(I asked as Rockchip hdmi driver already well supports CEC - so i was thinking on rk3566 this is more of enabling than writing support code).
You enabled the panfrost driver with other patches, right?
Oh - i wasn't aware any patches are needed for Mesa for rk3566....
If so - may you pls point me for latest/correct patches for rk3566?
quoted
3. in kernel dmesg I have many:
"rockchip-drm display-subsystem: [drm] *ERROR* Unsupported format modifier 0x810000000000001".
This message is correct. This corresponds to
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED and the VOP2 driver doesn't
support this. I have a similar problem here with
weston-simple-dmabuf-egl. By default this uses DRM_FORMAT_XRGB8888
which ends up being PIPE_FORMAT_B8G8R8_UNORM in MESA.
Ah ok. Clear now.
Thx!
btw: i added support for argb8888 in my app and now all is ok.
no anymore errors in dmesg :-)
so summarising:
your vop2 code works for me in all supported video pipeline variants:
-x11/Glamour
-Wayland-EGL
-EGLFS/EGL-dmabuf
-EGLFS/DRM Planes
Your vop2 work is impressive!
btw:
you mention:
In weston-simple-dmabuf-egl I can pass a suitable format on the command
line, in my case I use DRM_FORMAT_ABGR8888 (which becomes
PIPE_FORMAT_R8G8B8A8_UNORM). With this the panfrost driver does AFBC
which then can be rendered in the VOP2 cluster window overlay.
is this mean that: when my app is using ARGB8888 format - then I have AFBC on rk3566?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel