Re: [PATCH v2] ARM: dts: bcm2835: Enable 3D rendering through V3D
On Mon, 15 Apr 2024 13:00:39 -0300
Maíra Canal wrote:
Hi,
> RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to
> the RPi. Currently, the downstream kernel uses an overlay to enable the
> GPU and use GPU hardware acceleration. When deploying a mainline kernel
> to the RPi 0-3, we end up without any GPU hardware acceleration
> (essentially, we can't use the OpenGL driver).
>
> Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel.
So I think Krzysztof's initial comment still stands: What does that patch
actually change? If I build those DTBs as of now, none of them has a
status property in the v3d node. Which means it's enabled:
https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter2-devicetree-basics.rst#status
So adding an explicit 'status = "okay";' doesn't make a difference.
What do I miss here?
Cheers,
Andre
> Signed-off-by: Maíra Canal
> ---
>
> v1 -> v2:
> https://lore.kernel.org/dri-devel/41694292-af1f-4760-a7b6-101ed5dd6...@gmx.net/T/
>
> * As mentioned by Krzysztof, enabling should be done in last place of
> override/extend. Therefore, I'm disabling V3D in the common dtsi
> and enabling in the last place of extend, i.e. the RPi DTS files.
>
> arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 1 +
> arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts | 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts| 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts | 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts | 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts| 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts | 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-zero-w.dts | 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-zero.dts | 4
> arch/arm/boot/dts/broadcom/bcm2836-rpi-2-b.dts | 4
> arch/arm/boot/dts/broadcom/bcm2837-rpi-3-a-plus.dts | 4
> arch/arm/boot/dts/broadcom/bcm2837-rpi-3-b-plus.dts | 4
> arch/arm/boot/dts/broadcom/bcm2837-rpi-3-b.dts | 4
> arch/arm/boot/dts/broadcom/bcm2837-rpi-cm3-io3.dts | 4
> arch/arm/boot/dts/broadcom/bcm2837-rpi-zero-2-w.dts | 4
> 15 files changed, 57 insertions(+)
>
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
> b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
> index 9261b67dbee1..69e34831de51 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
> @@ -139,6 +139,7 @@ v3d: v3d@7ec0 {
> compatible = "brcm,bcm2835-v3d";
> reg = <0x7ec0 0x1000>;
> interrupts = <1 10>;
> + status = "disabled";
> };
>
> vc4: gpu {
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
> index 069b48272aa5..495ab1dfd2ce 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
> @@ -128,3 +128,7 @@ {
> pinctrl-0 = <_gpio14>;
> status = "okay";
> };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
> index 2726c00431e8..4634d88ce3af 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
> @@ -121,3 +121,7 @@ {
> pinctrl-0 = <_gpio14>;
> status = "okay";
> };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
> index c57b999a4520..45fa0f6851fc 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
> @@ -130,3 +130,7 @@ {
> pinctrl-0 = <_gpio14>;
> status = "okay";
> };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
> index ae6d3a9586ab..c1dac5d704aa 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
> @@ -121,3 +121,7 @@ {
> pinctrl-0 = <_gpio14>;
> status = "okay";
> };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
> index 72764be75a79..72ca31f2a7d6 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
> @@ -115,3 +115,7 @@ {
> pinctrl-0 = <_gpio14>;
> status = "okay";
> };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts
> index 3f9d198ac3ab..881a07d2f28f 100644
> ---
Re: arm: ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] undefined!
On Mon, 04 Mar 2024 12:26:46 +0100 "Arnd Bergmann" wrote: > On Mon, Mar 4, 2024, at 12:24, Andre Przywara wrote: > > On Mon, 04 Mar 2024 12:11:36 +0100 "Arnd Bergmann" wrote: > >> > >> This used to be a 32-bit division. If the rate is never more than > >> 4.2GHz, clock could be turned back into 'unsigned long' to avoid > >> the expensive div_u64(). > > > > Wouldn't "div_u64(clock, 200)" solve this problem? > > Yes, that's why I mentioned it as the worse of the two obvious > solutions. ;-) Argh, should have cleaned my glasses first ;-) I guess I was put somehow put off by the word "expensive". While it's admittedly not trivial, I wonder if we care about the (hidden) complexity of that function? I mean it's neither core code nor something called frequently? I don't think we have any clock exceeding 3GHz at the moment, but it sounds fishy to rely on that. Cheers, Andre
Re: arm: ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] undefined!
On Mon, 04 Mar 2024 12:11:36 +0100
"Arnd Bergmann" wrote:
Hi,
> On Mon, Mar 4, 2024, at 09:07, Naresh Kamboju wrote:
> > The arm defconfig builds failed on today's Linux next tag next-20240304.
> >
> > Build log:
> > -
> > ERROR: modpost: "__aeabi_uldivmod"
> > [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] undefined!
> >
>
> Apparently caused by the 64-bit division in 358e76fd613a
> ("drm/sun4i: hdmi: Consolidate atomic_check and mode_valid"):
>
>
> +static enum drm_mode_status
> +sun4i_hdmi_connector_clock_valid(const struct drm_connector *connector,
> +const struct drm_display_mode *mode,
> +unsigned long long clock)
> {
> - struct sun4i_hdmi *hdmi = drm_encoder_to_sun4i_hdmi(encoder);
> - unsigned long rate = mode->clock * 1000;
> - unsigned long diff = rate / 200; /* +-0.5% allowed by HDMI spec */
> + const struct sun4i_hdmi *hdmi =
> drm_connector_to_sun4i_hdmi(connector);
> + unsigned long diff = clock / 200; /* +-0.5% allowed by HDMI spec */
Wouldn't "div_u64(clock, 200)" solve this problem?
Cheers,
Andre
> long rounded_rate;
>
> This used to be a 32-bit division. If the rate is never more than
> 4.2GHz, clock could be turned back into 'unsigned long' to avoid
> the expensive div_u64().
>
> Arnd
>
Re: [PATCH v2 01/11] pwm: Make .get_state() callback return an error code
On Thu, 1 Dec 2022 14:16:04 +0100 Uwe Kleine-König wrote: Hi Uwe, > Hello Andre, > > On Thu, Dec 01, 2022 at 10:22:52AM +0000, Andre Przywara wrote: > > Just one comment: I don't see a sunxi specific patch later in the series, > > though it seems we have at least one error error exit (see prescaler == 0 > > above). Plus potentially another exit if clk_get_rate() (at the very > > beginning) fails. > > Shall I send a patch for that? > > That would we very welcome. I mentioned that shortly in the cover > letter, I wasn't entirely sure how to handle that prescaler = 0 case. Ah right, sorry, I missed that. So the Allwinner manual somehow marks those prescaler encodings as reserved or invalid (it's just a "/" in there), and we never set those values in the driver (there is an explicit check). So it could only be a leftover from firmware/bootloader, or someone poking at this register behind our back. I am tempted to just return some -EINVAL. As the current code stands, we don't manipulate any state flags before that check, so it doesn't really matter, but would be best practise, at least. Cheers, Andre
Re: [PATCH v2 01/11] pwm: Make .get_state() callback return an error code
On Wed, 30 Nov 2022 16:21:38 +0100
Uwe Kleine-König wrote:
Hi,
> .get_state() might fail in some cases. To make it possible that a driver
> signals such a failure change the prototype of .get_state() to return an
> error code.
>
> This patch was created using coccinelle and the following semantic patch:
>
> @p1@
> identifier getstatefunc;
> identifier driver;
> @@
> struct pwm_ops driver = {
> ...,
> .get_state = getstatefunc
> ,...
> };
>
> @p2@
> identifier p1.getstatefunc;
> identifier chip, pwm, state;
> @@
> -void
> +int
> getstatefunc(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state
> *state)
> {
>...
> - return;
> + return 0;
>...
> }
>
> plus the actual change of the prototype in include/linux/pwm.h (plus some
> manual fixing of indentions and empty lines).
>
> So for now all drivers return success unconditionally. They are adapted
> in the following patches to make the changes easier reviewable.
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/gpio/gpio-mvebu.c | 9 ++---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 14 --
> drivers/leds/rgb/leds-qcom-lpg.c | 14 --
> drivers/pwm/pwm-atmel.c | 6 --
> drivers/pwm/pwm-bcm-iproc.c | 8 +---
> drivers/pwm/pwm-crc.c | 10 ++
> drivers/pwm/pwm-cros-ec.c | 8 +---
> drivers/pwm/pwm-dwc.c | 6 --
> drivers/pwm/pwm-hibvt.c | 6 --
> drivers/pwm/pwm-imx-tpm.c | 8 +---
> drivers/pwm/pwm-imx27.c | 8 +---
> drivers/pwm/pwm-intel-lgm.c | 6 --
> drivers/pwm/pwm-iqs620a.c | 6 --
> drivers/pwm/pwm-keembay.c | 6 --
> drivers/pwm/pwm-lpss.c| 6 --
> drivers/pwm/pwm-meson.c | 8 +---
> drivers/pwm/pwm-mtk-disp.c| 12 +++-
> drivers/pwm/pwm-pca9685.c | 8 +---
> drivers/pwm/pwm-raspberrypi-poe.c | 8 +---
> drivers/pwm/pwm-rockchip.c| 12 +++-
> drivers/pwm/pwm-sifive.c | 6 --
> drivers/pwm/pwm-sl28cpld.c| 8 +---
> drivers/pwm/pwm-sprd.c| 8 +---
> drivers/pwm/pwm-stm32-lp.c| 8 +---
> drivers/pwm/pwm-sun4i.c | 12 +++-
> drivers/pwm/pwm-sunplus.c | 6 --
> drivers/pwm/pwm-visconti.c| 6 --
> drivers/pwm/pwm-xilinx.c | 8 +---
> include/linux/pwm.h | 4 ++--
> 29 files changed, 146 insertions(+), 89 deletions(-)
>
[ ... ]
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index c8445b0a3339..37d75e252d4e 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -108,9 +108,9 @@ static inline void sun4i_pwm_writel(struct sun4i_pwm_chip
> *chip,
> writel(val, chip->base + offset);
> }
>
> -static void sun4i_pwm_get_state(struct pwm_chip *chip,
> - struct pwm_device *pwm,
> - struct pwm_state *state)
> +static int sun4i_pwm_get_state(struct pwm_chip *chip,
> +struct pwm_device *pwm,
> +struct pwm_state *state)
> {
> struct sun4i_pwm_chip *sun4i_pwm = to_sun4i_pwm_chip(chip);
> u64 clk_rate, tmp;
> @@ -132,7 +132,7 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
> state->duty_cycle = DIV_ROUND_UP_ULL(state->period, 2);
> state->polarity = PWM_POLARITY_NORMAL;
> state->enabled = true;
> - return;
> + return 0;
> }
>
> if ((PWM_REG_PRESCAL(val, pwm->hwpwm) == PWM_PRESCAL_MASK) &&
> @@ -142,7 +142,7 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
> prescaler = prescaler_table[PWM_REG_PRESCAL(val, pwm->hwpwm)];
>
> if (prescaler == 0)
> - return;
> + return 0;
>
> if (val & BIT_CH(PWM_ACT_STATE, pwm->hwpwm))
> state->polarity = PWM_POLARITY_NORMAL;
> @@ -162,6 +162,8 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
>
> tmp = (u64)prescaler * NSEC_PER_SEC * PWM_REG_PRD(val);
> state->period = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
> +
> + return 0;
> }
>
> static int sun4i_pwm_calculate(struct sun4i_pwm_chip *sun4i_pwm,
For sunxi:
Reviewed-by: Andre Przywara
Just one comment: I don't see a sunxi specific patch later in the series,
though it seems we have at least one error error exit (see prescaler == 0
above). Plus potentially another exit if clk_get_rate() (at the very
beginning) fails.
Shall I send a patch for that?
Cheers,
Andre.
Re: [PATCH v2 10/11] dt-bindings: display: convert Arm Mali-DP to DT schema
On Wed, 11 May 2022 13:03:36 +0100
Liviu Dudau wrote:
Hi Liviu,
> On Mon, May 09, 2022 at 02:49:01PM +0100, Andre Przywara wrote:
> > On Fri, 06 May 2022 17:39:53 -0500
> > Rob Herring wrote:
> >
> > > On Fri, 06 May 2022 15:05:32 +0100, Andre Przywara wrote:
> > > > The Arm Mali Display Processor (DP) 5xx/6xx is a series of IP that scans
> > > > out a framebuffer and hands the pixels over to a digital signal encoder.
> > > > It supports multiple layers, scaling and rotation.
> > > >
> > > > Convert the existing DT binding to DT schema.
> > > >
> > > > Signed-off-by: Andre Przywara
> > > > ---
> > > > .../bindings/display/arm,malidp.txt | 68 --
> > > > .../bindings/display/arm,malidp.yaml | 116 ++
> > > > 2 files changed, 116 insertions(+), 68 deletions(-)
> > > > delete mode 100644
> > > > Documentation/devicetree/bindings/display/arm,malidp.txt
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/display/arm,malidp.yaml
> > > >
> > >
> > > 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/
> > >
> > >
> > > display@f08: 'arm,malidp-arqos-value' does not match any of the
> > > regexes: 'pinctrl-[0-9]+'
> > > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dtb
> > > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dtb
> > > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dtb
> > > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dtb
> > > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dtb
> > > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dtb
> > > arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dtb
> > > arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dtb
> >
> > Ah, good point, I missed that directory when testing. I came up with the
> > following change on top:
> >
> > ==
> > diff --git a/Documentation/devicetree/bindings/display/arm,malidp.yaml
> > b/Documentation/devicetree/bindings/display/arm,malidp.yaml
> > index ea7b7100548bf..bc0d3f3ab2b75 100644
> > --- a/Documentation/devicetree/bindings/display/arm,malidp.yaml
> > +++ b/Documentation/devicetree/bindings/display/arm,malidp.yaml
> > @@ -76,6 +76,14 @@ properties:
> > description:
> >integer describing the ARQoS levels of DP500's QoS signaling
> >
> > + arm,malidp-arqos-value:
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +description:
> > + Quality-of-Service value for the display engine FIFOs, to write
> > + into the RQOS register of the DP500.
> > + See the ARM Mali-DP500 TRM for details on the encoding.
> > + If omitted, the RQOS register will not be changed.
> > +
>
> Actually, this needs to replace 'arm,malidp-arqos-high-level'. Commit
> ce6eb0253cba
> ("dt/bindings: display: Add optional property node define for Mali DP500") is
> introducing the wrong property (it mentions 'arm,malidp-arqos-value' in the
> commit
> message). There is no user of 'arm,malidp-arqos-high-level' in the kernel.
Ah, thanks for the report and the background, and sorry for the delay. I
verified that, and sent a patch[1], since this binding here was already
merged.
Cheers,
Andre
[1]
https://lore.kernel.org/linux-arm-kernel/20220609162729.1441760-1-andre.przyw...@arm.com/T/#u
>
> Appologies for signing off on the wrong patch content at that time.
>
> Best regards,
> Liviu
>
> >port:
> > $ref: /schemas/graph.yaml#/properties/port
> > unevaluatedProperties: false
> > ==
> >
> > Cheers,
> > Andre
>
[PATCH] dt-bindings: display: arm,malidp: remove bogus RQOS property
As Liviu pointed out, the arm,malidp-arqos-high-level property
mentioned in the original .txt binding was a mistake, and
arm,malidp-arqos-value needs to take its place.
The binding commit ce6eb0253cba ("dt/bindings: display: Add optional
property node define for Mali DP500") mentions the right name in the
commit message, but has the wrong name in the diff.
Commit d298e6a27a81 ("drm/arm/mali-dp: Add display QoS interface
configuration for Mali DP500") uses the property in the driver, but uses
the shorter name.
Remove the wrong property from the binding, and use the proper name in
the example. The actual property was already documented properly.
Fixes: 2c8b082a3ab1 ("dt-bindings: display: convert Arm Mali-DP to DT schema")
Link:
https://lore.kernel.org/linux-arm-kernel/ynumgeilublhb...@e110455-lin.cambridge.arm.com/
Signed-off-by: Andre Przywara
Reported-by: Liviu Dudau
---
Documentation/devicetree/bindings/display/arm,malidp.yaml | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/arm,malidp.yaml
b/Documentation/devicetree/bindings/display/arm,malidp.yaml
index 795a08ac9f128..2a17ec6fc97c0 100644
--- a/Documentation/devicetree/bindings/display/arm,malidp.yaml
+++ b/Documentation/devicetree/bindings/display/arm,malidp.yaml
@@ -71,11 +71,6 @@ properties:
- description: number of output lines for the green channel (G)
- description: number of output lines for the blue channel (B)
- arm,malidp-arqos-high-level:
-$ref: /schemas/types.yaml#/definitions/uint32
-description:
- integer describing the ARQoS levels of DP500's QoS signaling
-
arm,malidp-arqos-value:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -113,7 +108,7 @@ examples:
clocks = <>, <>, <>, <>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
-arm,malidp-arqos-high-level = <0xd000d000>;
+arm,malidp-arqos-value = <0xd000d000>;
port {
dp0_output: endpoint {
--
2.25.1
Re: [PATCH] MAINTAINERS: rectify entries for ARM DRM DRIVERS after dt conversion
On Wed, 1 Jun 2022 06:17:46 +0200
Lukas Bulwahn wrote:
Hi Lukas,
> The three commits:
>
> 36fd2a65bcaf ("dt-bindings: display: convert Arm HDLCD to DT schema")
> 0f6983509ea1 ("dt-bindings: display: convert Arm Komeda to DT schema")
> 2c8b082a3ab1 ("dt-bindings: display: convert Arm Mali-DP to DT schema")
>
> convert the arm display dt-bindings, arm,*.txt to arm,*.yaml, but miss to
> adjust its reference in MAINTAINERS.
>
> Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about
> broken references.
>
> Repair these file references in ARM HDLCD DRM DRIVER, ARM KOMEDA DRM-KMS
> DRIVER and ARM MALI-DP DRM DRIVER.
>
> Signed-off-by: Lukas Bulwahn
Thanks for taking care!
Acked-by: Andre Przywara
Cheers,
Andre
> ---
> Andre, please ack.
> Rob, Krzysztof, please pick this minor non-urgent clean-up patch in
> your -next dt tree.
>
> MAINTAINERS | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ae685aaf8850..58e751b9346e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1510,7 +1510,7 @@ F: drivers/clocksource/arm_arch_timer.c
> ARM HDLCD DRM DRIVER
> M: Liviu Dudau
> S: Supported
> -F: Documentation/devicetree/bindings/display/arm,hdlcd.txt
> +F: Documentation/devicetree/bindings/display/arm,hdlcd.yaml
> F: drivers/gpu/drm/arm/hdlcd_*
>
> ARM INTEGRATOR, VERSATILE AND REALVIEW SUPPORT
> @@ -1545,7 +1545,7 @@ M: Mihail Atanassov
> L: Mali DP Maintainers
> S: Supported
> T: git git://anongit.freedesktop.org/drm/drm-misc
> -F: Documentation/devicetree/bindings/display/arm,komeda.txt
> +F: Documentation/devicetree/bindings/display/arm,komeda.yaml
> F: Documentation/gpu/komeda-kms.rst
> F: drivers/gpu/drm/arm/display/include/
> F: drivers/gpu/drm/arm/display/komeda/
> @@ -1567,7 +1567,7 @@ M: Brian Starkey
> L: Mali DP Maintainers
> S: Supported
> T: git git://anongit.freedesktop.org/drm/drm-misc
> -F: Documentation/devicetree/bindings/display/arm,malidp.txt
> +F: Documentation/devicetree/bindings/display/arm,malidp.yaml
> F: Documentation/gpu/afbc.rst
> F: drivers/gpu/drm/arm/
>
Re: [PATCH v2 10/11] dt-bindings: display: convert Arm Mali-DP to DT schema
On Fri, 06 May 2022 17:39:53 -0500 Rob Herring wrote: > On Fri, 06 May 2022 15:05:32 +0100, Andre Przywara wrote: > > The Arm Mali Display Processor (DP) 5xx/6xx is a series of IP that scans > > out a framebuffer and hands the pixels over to a digital signal encoder. > > It supports multiple layers, scaling and rotation. > > > > Convert the existing DT binding to DT schema. > > > > Signed-off-by: Andre Przywara > > --- > > .../bindings/display/arm,malidp.txt | 68 -- > > .../bindings/display/arm,malidp.yaml | 116 ++ > > 2 files changed, 116 insertions(+), 68 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/display/arm,malidp.txt > > create mode 100644 > > Documentation/devicetree/bindings/display/arm,malidp.yaml > > > > 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/ > > > display@f08: 'arm,malidp-arqos-value' does not match any of the regexes: > 'pinctrl-[0-9]+' > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dtb > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dtb > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dtb > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dtb > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dtb > arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dtb > arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dtb > arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dtb Ah, good point, I missed that directory when testing. I came up with the following change on top: == diff --git a/Documentation/devicetree/bindings/display/arm,malidp.yaml b/Documentation/devicetree/bindings/display/arm,malidp.yaml index ea7b7100548bf..bc0d3f3ab2b75 100644 --- a/Documentation/devicetree/bindings/display/arm,malidp.yaml +++ b/Documentation/devicetree/bindings/display/arm,malidp.yaml @@ -76,6 +76,14 @@ properties: description: integer describing the ARQoS levels of DP500's QoS signaling + arm,malidp-arqos-value: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + Quality-of-Service value for the display engine FIFOs, to write + into the RQOS register of the DP500. + See the ARM Mali-DP500 TRM for details on the encoding. + If omitted, the RQOS register will not be changed. + port: $ref: /schemas/graph.yaml#/properties/port unevaluatedProperties: false == Cheers, Andre
[PATCH v2 10/11] dt-bindings: display: convert Arm Mali-DP to DT schema
The Arm Mali Display Processor (DP) 5xx/6xx is a series of IP that scans
out a framebuffer and hands the pixels over to a digital signal encoder.
It supports multiple layers, scaling and rotation.
Convert the existing DT binding to DT schema.
Signed-off-by: Andre Przywara
---
.../bindings/display/arm,malidp.txt | 68 --
.../bindings/display/arm,malidp.yaml | 116 ++
2 files changed, 116 insertions(+), 68 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/arm,malidp.txt
create mode 100644 Documentation/devicetree/bindings/display/arm,malidp.yaml
diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt
b/Documentation/devicetree/bindings/display/arm,malidp.txt
deleted file mode 100644
index 7a97a2b48c2a2..0
--- a/Documentation/devicetree/bindings/display/arm,malidp.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-ARM Mali-DP
-
-The following bindings apply to a family of Display Processors sold as
-licensable IP by ARM Ltd. The bindings describe the Mali DP500, DP550 and
-DP650 processors that offer multiple composition layers, support for
-rotation and scaling output.
-
-Required properties:
- - compatible: should be one of
- "arm,mali-dp500"
- "arm,mali-dp550"
- "arm,mali-dp650"
-depending on the particular implementation present in the hardware
- - reg: Physical base address and size of the block of registers used by
-the processor.
- - interrupts: Interrupt list, as defined in
../interrupt-controller/interrupts.txt,
-interrupt client nodes.
- - interrupt-names: name of the engine inside the processor that will
-use the corresponding interrupt. Should be one of "DE" or "SE".
- - clocks: A list of phandle + clock-specifier pairs, one for each entry
-in 'clock-names'
- - clock-names: A list of clock names. It should contain:
- - "pclk": for the APB interface clock
- - "aclk": for the AXI interface clock
- - "mclk": for the main processor clock
- - "pxlclk": for the pixel clock feeding the output PLL of the processor.
- - arm,malidp-output-port-lines: Array of u8 values describing the number
-of output lines per channel (R, G and B).
-
-Required sub-nodes:
- - port: The Mali DP connection to an encoder input port. The connection
-is modelled using the OF graph bindings specified in
-Documentation/devicetree/bindings/graph.txt
-
-Optional properties:
- - memory-region: phandle to a node describing memory (see
-Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
-to be used for the framebuffer; if not present, the framebuffer may
-be located anywhere in memory.
- - arm,malidp-arqos-high-level: integer of u32 value describing the ARQoS
-levels of DP500's QoS signaling.
-
-
-Example:
-
-/ {
- ...
-
- dp0: malidp@6f20 {
- compatible = "arm,mali-dp650";
- reg = <0 0x6f20 0 0x2>;
- memory-region = <_reserved>;
- interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>,
-<0 168 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "DE", "SE";
- clocks = <>, <>, <>, <>;
- clock-names = "pxlclk", "mclk", "aclk", "pclk";
- arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
- arm,malidp-arqos-high-level = <0xd000d000>;
- port {
- dp0_output: endpoint {
- remote-endpoint = <_2_input>;
- };
- };
- };
-
- ...
-};
diff --git a/Documentation/devicetree/bindings/display/arm,malidp.yaml
b/Documentation/devicetree/bindings/display/arm,malidp.yaml
new file mode 100644
index 0..ea7b7100548bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,malidp.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/arm,malidp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Mali Display Processor (Mali-DP) binding
+
+maintainers:
+ - Liviu Dudau
+ - Andre Przywara
+
+description:
+ The following bindings apply to a family of Display Processors sold as
+ licensable IP by ARM Ltd. The bindings describe the Mali DP500, DP550 and
+ DP650 processors that offer multiple composition layers, support for
+ rotation and scaling output.
+
+properties:
+ compatible:
+enum:
+ - arm,mali-dp500
+ - arm,mali-dp550
+ - arm,mali-dp650
+
+ reg:
+maxItems: 1
+
+ interrupts:
+items:
+ - description:
+ The interrupt used by the Display Engine (DE). Can be shared with
+ the interru
[PATCH v2 11/11] dt-bindings: display: convert Arm Komeda to DT schema
The Arm Komeda (aka Mali-D71) is a display controller that scans out a
framebuffer and hands a signal to a digital encoder to generate a DVI
or HDMI signal. It supports up to two pipelines, each frame can be
composed of up to four layers.
Convert the existing DT binding to DT schema.
Signed-off-by: Andre Przywara
---
.../bindings/display/arm,komeda.txt | 78 ---
.../bindings/display/arm,komeda.yaml | 130 ++
2 files changed, 130 insertions(+), 78 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/arm,komeda.txt
create mode 100644 Documentation/devicetree/bindings/display/arm,komeda.yaml
diff --git a/Documentation/devicetree/bindings/display/arm,komeda.txt
b/Documentation/devicetree/bindings/display/arm,komeda.txt
deleted file mode 100644
index 8513695ee47fe..0
--- a/Documentation/devicetree/bindings/display/arm,komeda.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-Device Tree bindings for Arm Komeda display driver
-
-Required properties:
-- compatible: Should be "arm,mali-d71"
-- reg: Physical base address and length of the registers in the system
-- interrupts: the interrupt line number of the device in the system
-- clocks: A list of phandle + clock-specifier pairs, one for each entry
-in 'clock-names'
-- clock-names: A list of clock names. It should contain:
- - "aclk": for the main processor clock
-- #address-cells: Must be 1
-- #size-cells: Must be 0
-- iommus: configure the stream id to IOMMU, Must be configured if want to
-enable iommu in display. for how to configure this node please reference
-devicetree/bindings/iommu/arm,smmu-v3.txt,
-devicetree/bindings/iommu/iommu.txt
-
-Required properties for sub-node: pipeline@nq
-Each device contains one or two pipeline sub-nodes (at least one), each
-pipeline node should provide properties:
-- reg: Zero-indexed identifier for the pipeline
-- clocks: A list of phandle + clock-specifier pairs, one for each entry
-in 'clock-names'
-- clock-names: should contain:
- - "pxclk": pixel clock
-
-- port: each pipeline connect to an encoder input port. The connection is
-modeled using the OF graph bindings specified in
-Documentation/devicetree/bindings/graph.txt
-
-Optional properties:
- - memory-region: phandle to a node describing memory (see
-Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
-to be used for the framebuffer; if not present, the framebuffer may
-be located anywhere in memory.
-
-Example:
-/ {
- ...
-
- dp0: display@c0 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "arm,mali-d71";
- reg = <0xc0 0x2>;
- interrupts = <0 168 4>;
- clocks = <_aclk>;
- clock-names = "aclk";
- iommus = < 0>, < 1>, < 2>, < 3>,
- < 4>, < 5>, < 6>, < 7>,
- < 8>, < 9>;
-
- dp0_pipe0: pipeline@0 {
- clocks = <>;
- clock-names = "pxclk";
- reg = <0>;
-
- port {
- dp0_pipe0_out: endpoint {
- remote-endpoint = <_dvi0_in>;
- };
- };
- };
-
- dp0_pipe1: pipeline@1 {
- clocks = <>;
- clock-names = "pxclk";
- reg = <1>;
-
- port {
- dp0_pipe1_out: endpoint {
- remote-endpoint = <_dvi1_in>;
- };
- };
- };
- };
- ...
-};
diff --git a/Documentation/devicetree/bindings/display/arm,komeda.yaml
b/Documentation/devicetree/bindings/display/arm,komeda.yaml
new file mode 100644
index 0..9f4aade97f10a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,komeda.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/arm,komeda.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Komeda display processor
+
+maintainers:
+ - Liviu Dudau
+ - Andre Przywara
+
+description:
+ The Arm Mali D71 display processor supports up to two displays with up
+ to a 4K resolution each. Each pipeline can be composed of up to four
+ layers. It is typically connected to a digital display connector like HDMI.
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: arm,mali-d32
+ - const: arm,mali-d71
+ - const: arm,mali-d
[PATCH v2 09/11] dt-bindings: display: convert Arm HDLCD to DT schema
The Arm HDLCD is a display controller that scans out a framebuffer and
hands a signal to a digital encoder to generate a DVI or HDMI signal.
Convert the existing DT binding to DT schema.
Signed-off-by: Andre Przywara
---
.../devicetree/bindings/display/arm,hdlcd.txt | 79
.../bindings/display/arm,hdlcd.yaml | 89 +++
2 files changed, 89 insertions(+), 79 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt
create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.yaml
diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.txt
b/Documentation/devicetree/bindings/display/arm,hdlcd.txt
deleted file mode 100644
index 78bc24296f3e4..0
--- a/Documentation/devicetree/bindings/display/arm,hdlcd.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-ARM HDLCD
-
-This is a display controller found on several development platforms produced
-by ARM Ltd and in more modern of its' Fast Models. The HDLCD is an RGB
-streamer that reads the data from a framebuffer and sends it to a single
-digital encoder (DVI or HDMI).
-
-Required properties:
- - compatible: "arm,hdlcd"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: One interrupt used by the display controller to notify the
-interrupt controller when any of the interrupt sources programmed in
-the interrupt mask register have activated.
- - clocks: A list of phandle + clock-specifier pairs, one for each
-entry in 'clock-names'.
- - clock-names: A list of clock names. For HDLCD it should contain:
- - "pxlclk" for the clock feeding the output PLL of the controller.
-
-Required sub-nodes:
- - port: The HDLCD connection to an encoder chip. The connection is modeled
-using the OF graph bindings specified in
-Documentation/devicetree/bindings/graph.txt.
-
-Optional properties:
- - memory-region: phandle to a node describing memory (see
-Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to
be
-used for the framebuffer; if not present, the framebuffer may be located
-anywhere in memory.
-
-
-Example:
-
-/ {
- ...
-
- hdlcd@2b00 {
- compatible = "arm,hdlcd";
- reg = <0 0x2b00 0 0x1000>;
- interrupts = ;
- clocks = <>;
- clock-names = "pxlclk";
- port {
- hdlcd_output: endpoint@0 {
- remote-endpoint = <_enc_input>;
- };
- };
- };
-
- /* HDMI encoder on I2C bus */
- i2c@7ffa {
-
- hdmi-transmitter@70 {
- compatible = ".";
- reg = <0x70>;
- port@0 {
- hdmi_enc_input: endpoint {
- remote-endpoint = <_output>;
- };
-
- hdmi_enc_output: endpoint {
- remote-endpoint = <_1_port>;
- };
- };
- };
-
- };
-
- hdmi1: connector@1 {
- compatible = "hdmi-connector";
- type = "a";
- port {
- hdmi_1_port: endpoint {
- remote-endpoint = <_enc_output>;
- };
- };
- };
-
- ...
-};
diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.yaml
b/Documentation/devicetree/bindings/display/arm,hdlcd.yaml
new file mode 100644
index 0..a2670258c48d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,hdlcd.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/arm,hdlcd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm HDLCD display controller binding
+
+maintainers:
+ - Liviu Dudau
+ - Andre Przywara
+
+description:
+ The Arm HDLCD is a display controller found on several development platforms
+ produced by ARM Ltd and in more modern of its Fast Models. The HDLCD is an
+ RGB streamer that reads the data from a framebuffer and sends it to a single
+ digital encoder (DVI or HDMI).
+
+properties:
+ compatible:
+const: arm,hdlcd
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clock-names:
+const: pxlclk
+
+ clocks:
+maxItems: 1
+description: The input reference for the pixel clock.
+
+ memory-region:
+maxItems: 1
+description:
+ Phandle to a node describing memory to be used for the framebuffer.
+ If not present, the framebuffer may be located anywhere in memory.
+
+ iommus:
+maxItems:
[PATCH v2 08/11] dt-bindings: display: convert PL110/PL111 to DT schema
The Arm PL110 and PL111 are IP blocks that provide a display engine with
an LCD interface, being able to drive a variety of LC panels.
Convert the binding over to DT schema, to the DTs can be automatically
checked.
This still contains the deprecated "arm,pl11x,tft-r0g0b0-pads" property,
because this is used by several DTs in the tree.
Signed-off-by: Andre Przywara
---
.../devicetree/bindings/display/arm,pl11x.txt | 110 ---
.../bindings/display/arm,pl11x.yaml | 174 ++
2 files changed, 174 insertions(+), 110 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/arm,pl11x.txt
create mode 100644 Documentation/devicetree/bindings/display/arm,pl11x.yaml
diff --git a/Documentation/devicetree/bindings/display/arm,pl11x.txt
b/Documentation/devicetree/bindings/display/arm,pl11x.txt
deleted file mode 100644
index 3f977e72a2005..0
--- a/Documentation/devicetree/bindings/display/arm,pl11x.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-* ARM PrimeCell Color LCD Controller PL110/PL111
-
-See also Documentation/devicetree/bindings/arm/primecell.yaml
-
-Required properties:
-
-- compatible: must be one of:
- "arm,pl110", "arm,primecell"
- "arm,pl111", "arm,primecell"
-
-- reg: base address and size of the control registers block
-
-- interrupt-names: either the single entry "combined" representing a
- combined interrupt output (CLCDINTR), or the four entries
- "mbe", "vcomp", "lnbu", "fuf" representing the individual
- CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
-
-- interrupts: contains an interrupt specifier for each entry in
- interrupt-names
-
-- clock-names: should contain "clcdclk" and "apb_pclk"
-
-- clocks: contains phandle and clock specifier pairs for the entries
- in the clock-names property. See
- Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Optional properties:
-
-- memory-region: phandle to a node describing memory (see
- Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
- to be used for the framebuffer; if not present, the framebuffer
- may be located anywhere in the memory
-
-- max-memory-bandwidth: maximum bandwidth in bytes per second that the
- cell's memory interface can handle; if not present, the memory
- interface is fast enough to handle all possible video modes
-
-Required sub-nodes:
-
-- port: describes LCD panel signals, following the common binding
- for video transmitter interfaces; see
- Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Deprecated properties:
- The port's endbpoint subnode had this, now deprecated property
- in the past. Drivers should be able to survive without it:
-
- - arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values,
- defining the way CLD pads are wired up; first value
- contains index of the "CLD" external pin (pad) used
- as R0 (first bit of the red component), second value
- index of the pad used as G0, third value index of the
- pad used as B0, see also "LCD panel signal multiplexing
- details" paragraphs in the PL110/PL111 Technical
- Reference Manuals; this implicitly defines available
- color modes, for example:
- - PL111 TFT 4:4:4 panel:
- arm,pl11x,tft-r0g0b0-pads = <4 15 20>;
- - PL110 TFT (1:)5:5:5 panel:
- arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
- - PL111 TFT (1:)5:5:5 panel:
- arm,pl11x,tft-r0g0b0-pads = <3 11 19>;
- - PL111 TFT 5:6:5 panel:
- arm,pl11x,tft-r0g0b0-pads = <3 10 19>;
- - PL110 and PL111 TFT 8:8:8 panel:
- arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
- - PL110 and PL111 TFT 8:8:8 panel, R & B components swapped:
- arm,pl11x,tft-r0g0b0-pads = <16 8 0>;
-
-
-Example:
-
- clcd@1002 {
- compatible = "arm,pl111", "arm,primecell";
- reg = <0x1002 0x1000>;
- interrupt-names = "combined";
- interrupts = <0 44 4>;
- clocks = <>, <>;
- clock-names = "clcdclk", "apb_pclk";
- max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */
-
- port {
- clcd_pads: endpoint {
- remote-endpoint = <_panel>;
- };
- };
-
- };
-
- panel {
- compatible = "panel-dpi";
-
- port {
-
[PATCH 09/11] dt-bindings: display: convert Arm HDLCD to DT schema
The Arm HDLCD is a display controller that scans out a framebuffer and
hands a signal to a digital encoder to generate a DVI or HDMI signal.
Convert the existing DT binding to DT schema.
Signed-off-by: Andre Przywara
---
.../devicetree/bindings/display/arm,hdlcd.txt | 79
.../bindings/display/arm,hdlcd.yaml | 91 +++
2 files changed, 91 insertions(+), 79 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt
create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.yaml
diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.txt
b/Documentation/devicetree/bindings/display/arm,hdlcd.txt
deleted file mode 100644
index 78bc24296f3e4..0
--- a/Documentation/devicetree/bindings/display/arm,hdlcd.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-ARM HDLCD
-
-This is a display controller found on several development platforms produced
-by ARM Ltd and in more modern of its' Fast Models. The HDLCD is an RGB
-streamer that reads the data from a framebuffer and sends it to a single
-digital encoder (DVI or HDMI).
-
-Required properties:
- - compatible: "arm,hdlcd"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: One interrupt used by the display controller to notify the
-interrupt controller when any of the interrupt sources programmed in
-the interrupt mask register have activated.
- - clocks: A list of phandle + clock-specifier pairs, one for each
-entry in 'clock-names'.
- - clock-names: A list of clock names. For HDLCD it should contain:
- - "pxlclk" for the clock feeding the output PLL of the controller.
-
-Required sub-nodes:
- - port: The HDLCD connection to an encoder chip. The connection is modeled
-using the OF graph bindings specified in
-Documentation/devicetree/bindings/graph.txt.
-
-Optional properties:
- - memory-region: phandle to a node describing memory (see
-Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to
be
-used for the framebuffer; if not present, the framebuffer may be located
-anywhere in memory.
-
-
-Example:
-
-/ {
- ...
-
- hdlcd@2b00 {
- compatible = "arm,hdlcd";
- reg = <0 0x2b00 0 0x1000>;
- interrupts = ;
- clocks = <>;
- clock-names = "pxlclk";
- port {
- hdlcd_output: endpoint@0 {
- remote-endpoint = <_enc_input>;
- };
- };
- };
-
- /* HDMI encoder on I2C bus */
- i2c@7ffa {
-
- hdmi-transmitter@70 {
- compatible = ".";
- reg = <0x70>;
- port@0 {
- hdmi_enc_input: endpoint {
- remote-endpoint = <_output>;
- };
-
- hdmi_enc_output: endpoint {
- remote-endpoint = <_1_port>;
- };
- };
- };
-
- };
-
- hdmi1: connector@1 {
- compatible = "hdmi-connector";
- type = "a";
- port {
- hdmi_1_port: endpoint {
- remote-endpoint = <_enc_output>;
- };
- };
- };
-
- ...
-};
diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.yaml
b/Documentation/devicetree/bindings/display/arm,hdlcd.yaml
new file mode 100644
index 0..1fe8e07334152
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,hdlcd.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/arm,hdlcd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm HDLCD display controller binding
+
+maintainers:
+ - Liviu Dudau
+ - Andre Przywara
+
+description: |+
+ The Arm HDLCD is a display controller found on several development platforms
+ produced by ARM Ltd and in more modern of its Fast Models. The HDLCD is an
+ RGB streamer that reads the data from a framebuffer and sends it to a single
+ digital encoder (DVI or HDMI).
+
+properties:
+ compatible:
+const: arm,hdlcd
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clock-names:
+const: pxlclk
+
+ clocks:
+maxItems: 1
+description: The input reference for the pixel clock.
+
+ memory-region:
+maxItems: 1
+description:
+ Phandle to a node describing memory to be used for the framebuffer.
+ If not present, the framebuffer may be located anywhere in memory.
+
+ iommus:
+maxItems:
[PATCH 11/11] dt-bindings: display: convert Arm Komeda to DT schema
The Arm Komeda (aka Mali-D71) is a display controller that scans out a
framebuffer and hands a signal to a digital encoder to generate a DVI
or HDMI signal. It supports up to two pipelines, each frame can be
composed of up to four layers.
Convert the existing DT binding to DT schema.
Signed-off-by: Andre Przywara
---
.../bindings/display/arm,komeda.txt | 78 ---
.../bindings/display/arm,komeda.yaml | 130 ++
2 files changed, 130 insertions(+), 78 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/arm,komeda.txt
create mode 100644 Documentation/devicetree/bindings/display/arm,komeda.yaml
diff --git a/Documentation/devicetree/bindings/display/arm,komeda.txt
b/Documentation/devicetree/bindings/display/arm,komeda.txt
deleted file mode 100644
index 8513695ee47fe..0
--- a/Documentation/devicetree/bindings/display/arm,komeda.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-Device Tree bindings for Arm Komeda display driver
-
-Required properties:
-- compatible: Should be "arm,mali-d71"
-- reg: Physical base address and length of the registers in the system
-- interrupts: the interrupt line number of the device in the system
-- clocks: A list of phandle + clock-specifier pairs, one for each entry
-in 'clock-names'
-- clock-names: A list of clock names. It should contain:
- - "aclk": for the main processor clock
-- #address-cells: Must be 1
-- #size-cells: Must be 0
-- iommus: configure the stream id to IOMMU, Must be configured if want to
-enable iommu in display. for how to configure this node please reference
-devicetree/bindings/iommu/arm,smmu-v3.txt,
-devicetree/bindings/iommu/iommu.txt
-
-Required properties for sub-node: pipeline@nq
-Each device contains one or two pipeline sub-nodes (at least one), each
-pipeline node should provide properties:
-- reg: Zero-indexed identifier for the pipeline
-- clocks: A list of phandle + clock-specifier pairs, one for each entry
-in 'clock-names'
-- clock-names: should contain:
- - "pxclk": pixel clock
-
-- port: each pipeline connect to an encoder input port. The connection is
-modeled using the OF graph bindings specified in
-Documentation/devicetree/bindings/graph.txt
-
-Optional properties:
- - memory-region: phandle to a node describing memory (see
-Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
-to be used for the framebuffer; if not present, the framebuffer may
-be located anywhere in memory.
-
-Example:
-/ {
- ...
-
- dp0: display@c0 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "arm,mali-d71";
- reg = <0xc0 0x2>;
- interrupts = <0 168 4>;
- clocks = <_aclk>;
- clock-names = "aclk";
- iommus = < 0>, < 1>, < 2>, < 3>,
- < 4>, < 5>, < 6>, < 7>,
- < 8>, < 9>;
-
- dp0_pipe0: pipeline@0 {
- clocks = <>;
- clock-names = "pxclk";
- reg = <0>;
-
- port {
- dp0_pipe0_out: endpoint {
- remote-endpoint = <_dvi0_in>;
- };
- };
- };
-
- dp0_pipe1: pipeline@1 {
- clocks = <>;
- clock-names = "pxclk";
- reg = <1>;
-
- port {
- dp0_pipe1_out: endpoint {
- remote-endpoint = <_dvi1_in>;
- };
- };
- };
- };
- ...
-};
diff --git a/Documentation/devicetree/bindings/display/arm,komeda.yaml
b/Documentation/devicetree/bindings/display/arm,komeda.yaml
new file mode 100644
index 0..c619a0acfb307
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,komeda.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/arm,komeda.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Komeda display processor
+
+maintainers:
+ - Liviu Dudau
+ - Andre Przywara
+
+description: |+
+ The Arm Mali D71 display processor supports up to two displays with up
+ to a 4K resolution each. Each pipeline can be composed of up to four
+ layers. It is typically connected to a digital display connector like HDMI.
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: arm,mali-d32
+ - const: arm,mali-d71
+ - const: arm,mali-d
[PATCH 10/11] dt-bindings: display: convert Arm Mali-DP to DT schema
The Arm Mali Display Processor (DP) 5xx/6xx is a series of IP that scans
out a framebuffer and hands the pixels over to a digital signal encoder.
It supports multiple layers, scaling and rotation.
Convert the existing DT binding to DT schema.
Signed-off-by: Andre Przywara
---
.../bindings/display/arm,malidp.txt | 68 --
.../bindings/display/arm,malidp.yaml | 117 ++
2 files changed, 117 insertions(+), 68 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/arm,malidp.txt
create mode 100644 Documentation/devicetree/bindings/display/arm,malidp.yaml
diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt
b/Documentation/devicetree/bindings/display/arm,malidp.txt
deleted file mode 100644
index 7a97a2b48c2a2..0
--- a/Documentation/devicetree/bindings/display/arm,malidp.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-ARM Mali-DP
-
-The following bindings apply to a family of Display Processors sold as
-licensable IP by ARM Ltd. The bindings describe the Mali DP500, DP550 and
-DP650 processors that offer multiple composition layers, support for
-rotation and scaling output.
-
-Required properties:
- - compatible: should be one of
- "arm,mali-dp500"
- "arm,mali-dp550"
- "arm,mali-dp650"
-depending on the particular implementation present in the hardware
- - reg: Physical base address and size of the block of registers used by
-the processor.
- - interrupts: Interrupt list, as defined in
../interrupt-controller/interrupts.txt,
-interrupt client nodes.
- - interrupt-names: name of the engine inside the processor that will
-use the corresponding interrupt. Should be one of "DE" or "SE".
- - clocks: A list of phandle + clock-specifier pairs, one for each entry
-in 'clock-names'
- - clock-names: A list of clock names. It should contain:
- - "pclk": for the APB interface clock
- - "aclk": for the AXI interface clock
- - "mclk": for the main processor clock
- - "pxlclk": for the pixel clock feeding the output PLL of the processor.
- - arm,malidp-output-port-lines: Array of u8 values describing the number
-of output lines per channel (R, G and B).
-
-Required sub-nodes:
- - port: The Mali DP connection to an encoder input port. The connection
-is modelled using the OF graph bindings specified in
-Documentation/devicetree/bindings/graph.txt
-
-Optional properties:
- - memory-region: phandle to a node describing memory (see
-Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
-to be used for the framebuffer; if not present, the framebuffer may
-be located anywhere in memory.
- - arm,malidp-arqos-high-level: integer of u32 value describing the ARQoS
-levels of DP500's QoS signaling.
-
-
-Example:
-
-/ {
- ...
-
- dp0: malidp@6f20 {
- compatible = "arm,mali-dp650";
- reg = <0 0x6f20 0 0x2>;
- memory-region = <_reserved>;
- interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>,
-<0 168 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "DE", "SE";
- clocks = <>, <>, <>, <>;
- clock-names = "pxlclk", "mclk", "aclk", "pclk";
- arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
- arm,malidp-arqos-high-level = <0xd000d000>;
- port {
- dp0_output: endpoint {
- remote-endpoint = <_2_input>;
- };
- };
- };
-
- ...
-};
diff --git a/Documentation/devicetree/bindings/display/arm,malidp.yaml
b/Documentation/devicetree/bindings/display/arm,malidp.yaml
new file mode 100644
index 0..86b636662f803
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,malidp.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/arm,malidp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Mali Display Processor (Mali-DP) binding
+
+maintainers:
+ - Liviu Dudau
+ - Andre Przywara
+
+description: |+
+ The following bindings apply to a family of Display Processors sold as
+ licensable IP by ARM Ltd. The bindings describe the Mali DP500, DP550 and
+ DP650 processors that offer multiple composition layers, support for
+ rotation and scaling output.
+
+properties:
+ compatible:
+enum:
+ - arm,mali-dp500
+ - arm,mali-dp550
+ - arm,mali-dp650
+
+ reg:
+maxItems: 1
+
+ interrupts:
+items:
+ - description:
+ The interrupt used by the Display Engine (DE). Can be shared with
+ the interru
[PATCH 08/11] dt-bindings: display: convert PL110/PL111 to DT schema
The Arm PL110 and PL111 are IP blocks that provide a display engine with
an LCD interface, being able to drive a variety of LC panels.
Convert the binding over to DT schema, to the DTs can be automatically
checked.
This still contains the deprecated "arm,pl11x,tft-r0g0b0-pads" property,
because this is used by several DTs in the tree.
Signed-off-by: Andre Przywara
---
.../devicetree/bindings/display/arm,pl11x.txt | 110 ---
.../bindings/display/arm,pl11x.yaml | 174 ++
2 files changed, 174 insertions(+), 110 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/arm,pl11x.txt
create mode 100644 Documentation/devicetree/bindings/display/arm,pl11x.yaml
diff --git a/Documentation/devicetree/bindings/display/arm,pl11x.txt
b/Documentation/devicetree/bindings/display/arm,pl11x.txt
deleted file mode 100644
index 3f977e72a2005..0
--- a/Documentation/devicetree/bindings/display/arm,pl11x.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-* ARM PrimeCell Color LCD Controller PL110/PL111
-
-See also Documentation/devicetree/bindings/arm/primecell.yaml
-
-Required properties:
-
-- compatible: must be one of:
- "arm,pl110", "arm,primecell"
- "arm,pl111", "arm,primecell"
-
-- reg: base address and size of the control registers block
-
-- interrupt-names: either the single entry "combined" representing a
- combined interrupt output (CLCDINTR), or the four entries
- "mbe", "vcomp", "lnbu", "fuf" representing the individual
- CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
-
-- interrupts: contains an interrupt specifier for each entry in
- interrupt-names
-
-- clock-names: should contain "clcdclk" and "apb_pclk"
-
-- clocks: contains phandle and clock specifier pairs for the entries
- in the clock-names property. See
- Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Optional properties:
-
-- memory-region: phandle to a node describing memory (see
- Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
- to be used for the framebuffer; if not present, the framebuffer
- may be located anywhere in the memory
-
-- max-memory-bandwidth: maximum bandwidth in bytes per second that the
- cell's memory interface can handle; if not present, the memory
- interface is fast enough to handle all possible video modes
-
-Required sub-nodes:
-
-- port: describes LCD panel signals, following the common binding
- for video transmitter interfaces; see
- Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Deprecated properties:
- The port's endbpoint subnode had this, now deprecated property
- in the past. Drivers should be able to survive without it:
-
- - arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values,
- defining the way CLD pads are wired up; first value
- contains index of the "CLD" external pin (pad) used
- as R0 (first bit of the red component), second value
- index of the pad used as G0, third value index of the
- pad used as B0, see also "LCD panel signal multiplexing
- details" paragraphs in the PL110/PL111 Technical
- Reference Manuals; this implicitly defines available
- color modes, for example:
- - PL111 TFT 4:4:4 panel:
- arm,pl11x,tft-r0g0b0-pads = <4 15 20>;
- - PL110 TFT (1:)5:5:5 panel:
- arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
- - PL111 TFT (1:)5:5:5 panel:
- arm,pl11x,tft-r0g0b0-pads = <3 11 19>;
- - PL111 TFT 5:6:5 panel:
- arm,pl11x,tft-r0g0b0-pads = <3 10 19>;
- - PL110 and PL111 TFT 8:8:8 panel:
- arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
- - PL110 and PL111 TFT 8:8:8 panel, R & B components swapped:
- arm,pl11x,tft-r0g0b0-pads = <16 8 0>;
-
-
-Example:
-
- clcd@1002 {
- compatible = "arm,pl111", "arm,primecell";
- reg = <0x1002 0x1000>;
- interrupt-names = "combined";
- interrupts = <0 44 4>;
- clocks = <>, <>;
- clock-names = "clcdclk", "apb_pclk";
- max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */
-
- port {
- clcd_pads: endpoint {
- remote-endpoint = <_panel>;
- };
- };
-
- };
-
- panel {
- compatible = "panel-dpi";
-
- port {
-
Re: [PATCH] drm/arm: arm hdlcd select DRM_GEM_CMA_HELPER
On Tue, 25 Jan 2022 12:37:38 +
Liviu Dudau wrote:
Hi,
> On Mon, Jan 24, 2022 at 04:24:37PM +, carsten.haitz...@foss.arm.com wrote:
> > From: Carsten Haitzler
> >
> > Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
> >
> > Fixes: 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option")
> >
> > Signed-off-by: Carsten Haitzler
>
> Acked-by: Liviu Dudau
>
> I will add Steven's reviewed-by as well when pushing it.
Did this go anywhere? I see my .config just selecting HDLCD still failing
with -rc5. Any chance this can be taken now, as this is a regression
introduced with -rc1?
Cheers,
Andre
> > ---
> > drivers/gpu/drm/arm/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> > index 58a242871b28..6e3f1d600541 100644
> > --- a/drivers/gpu/drm/arm/Kconfig
> > +++ b/drivers/gpu/drm/arm/Kconfig
> > @@ -6,6 +6,7 @@ config DRM_HDLCD
> > depends on DRM && OF && (ARM || ARM64 || COMPILE_TEST)
> > depends on COMMON_CLK
> > select DRM_KMS_HELPER
> > + select DRM_GEM_CMA_HELPER
> > help
> > Choose this option if you have an ARM High Definition Colour LCD
> > controller.
> > --
> > 2.30.1
> >
>
Re: [PATCH v2] drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device
On Mon, 7 Jun 2021 10:58:36 +0200
Ondrej Jirman wrote:
Hi,
> From: Saravana Kannan
>
> On sunxi boards that use HDMI output, HDMI device probe keeps being
> avoided indefinitely with these repeated messages in dmesg:
>
> platform 1ee.hdmi: probe deferral - supplier 1ef.hdmi-phy
> not ready
>
> There's a fwnode_link being created with fw_devlink=on between hdmi
> and hdmi-phy nodes, because both nodes have 'compatible' property set.
>
> Fw_devlink code assumes that nodes that have compatible property
> set will also have a device associated with them by some driver
> eventually. This is not the case with the current sun8i-hdmi
> driver.
>
> This commit makes sun8i-hdmi-phy into a proper platform device
> and fixes the display pipeline probe on sunxi boards that use HDMI.
>
> More context: https://lkml.org/lkml/2021/5/16/203
>
> Signed-off-by: Saravana Kannan
> Signed-off-by: Ondrej Jirman
Many thanks to both of you for fixing this! I just tested this on a
Pine64-LTS (A64), Pine-H64 (H6) and OrangePi PC2 (H5). On all boards
this patch brings back HDMI video output for me.
Since this is a regression introduced with 5.13-rc1, we should merge
this ASAP.
Tested-by: Andre Przywara
Cheers,
Andre
> ---
> v2: Fix building as a module (phy and hdmi are part of the same module, so
> module init callbacks need to be shared)
>
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 31 ---
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 5 ++--
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 41 ++
> 3 files changed, 66 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> index bbdfd5e26ec88..f75fb157f2ff7 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> @@ -209,7 +209,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
> device *master,
> goto err_disable_clk_tmds;
> }
>
> - ret = sun8i_hdmi_phy_probe(hdmi, phy_node);
> + ret = sun8i_hdmi_phy_get(hdmi, phy_node);
> of_node_put(phy_node);
> if (ret) {
> dev_err(dev, "Couldn't get the HDMI PHY\n");
> @@ -242,7 +242,6 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
> device *master,
>
> cleanup_encoder:
> drm_encoder_cleanup(encoder);
> - sun8i_hdmi_phy_remove(hdmi);
> err_disable_clk_tmds:
> clk_disable_unprepare(hdmi->clk_tmds);
> err_assert_ctrl_reset:
> @@ -263,7 +262,6 @@ static void sun8i_dw_hdmi_unbind(struct device *dev,
> struct device *master,
> struct sun8i_dw_hdmi *hdmi = dev_get_drvdata(dev);
>
> dw_hdmi_unbind(hdmi->hdmi);
> - sun8i_hdmi_phy_remove(hdmi);
> clk_disable_unprepare(hdmi->clk_tmds);
> reset_control_assert(hdmi->rst_ctrl);
> gpiod_set_value(hdmi->ddc_en, 0);
> @@ -320,7 +318,32 @@ static struct platform_driver sun8i_dw_hdmi_pltfm_driver
> = {
> .of_match_table = sun8i_dw_hdmi_dt_ids,
> },
> };
> -module_platform_driver(sun8i_dw_hdmi_pltfm_driver);
> +
> +static int __init sun8i_dw_hdmi_init(void)
> +{
> + int ret;
> +
> + ret = platform_driver_register(_dw_hdmi_pltfm_driver);
> + if (ret)
> + return ret;
> +
> + ret = platform_driver_register(_hdmi_phy_driver);
> + if (ret) {
> + platform_driver_unregister(_dw_hdmi_pltfm_driver);
> + return ret;
> + }
> +
> + return ret;
> +}
> +
> +static void __exit sun8i_dw_hdmi_exit(void)
> +{
> + platform_driver_unregister(_dw_hdmi_pltfm_driver);
> + platform_driver_unregister(_hdmi_phy_driver);
> +}
> +
> +module_init(sun8i_dw_hdmi_init);
> +module_exit(sun8i_dw_hdmi_exit);
>
> MODULE_AUTHOR("Jernej Skrabec ");
> MODULE_DESCRIPTION("Allwinner DW HDMI bridge");
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> index d4b55af0592f8..74f6ed0e25709 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> @@ -195,14 +195,15 @@ struct sun8i_dw_hdmi {
> struct gpio_desc*ddc_en;
> };
>
> +extern struct platform_driver sun8i_hdmi_phy_driver;
> +
> static inline struct sun8i_dw_hdmi *
> encoder_to_sun8i_dw_hdmi(struct drm_encoder *encoder)
> {
> return container_of(encoder, struct sun8i_dw_hdmi, encoder);
> }
>
> -int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node
> *node);
> -void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi);
> +int sun8
[PATCH v3 19/20] dt-bindings: mali-midgard: Allow dma-coherent
Add the boolean dma-coherent property to the list of allowed properties, since some boards (Arm Juno) integrate the GPU this way. Signed-off-by: Andre Przywara --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml index 0407e45eb8c4..5d7165385e1f 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml @@ -87,6 +87,8 @@ properties: "#cooling-cells": const: 2 + dma-coherent: true + required: - compatible - reg -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 16/17] dt-bindings: mali-midgard: Allow dma-coherent
Add the boolean dma-coherent property to the list of allowed properties, since some boards (Arm Juno) integrate the GPU this way. Signed-off-by: Andre Przywara --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml index 0407e45eb8c4..5d7165385e1f 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml @@ -87,6 +87,8 @@ properties: "#cooling-cells": const: 2 + dma-coherent: true + required: - compatible - reg -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/16] dts/dt-bindings: Fix Arm Ltd. ARMv8 "boards"
Date: Mon, 4 May 2020 12:41:55 +0100 Subject: [PATCH 01/16] dt-bindings: mali-midgard: Allow dma-coherent Add the boolean dma-coherent property to the list of allowed properties, since some boards (Arm Juno) integrate the GPU this way. Signed-off-by: Andre Przywara --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml index 0407e45eb8c4..5d7165385e1f 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml @@ -87,6 +87,8 @@ properties: "#cooling-cells": const: 2 + dma-coherent: true + required: - compatible - reg -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 26/26] arm64: dts: allwinner: a64-amarula-relic: Enable Techstar TS8550B MIPI-DSI panel
On Tue, 13 Nov 2018 16:46:33 +0530
Jagan Teki wrote:
Hi,
I couldn't find a schematic for this board, but some things in here
look inconsistent:
> Amarula A64-Relic board by default bound with Techstar TS8550B
> MIPI-DSI panel, add support for it.
>
> DSI panel connected via board DSI port with,
> - DC1SW as AVDD supply
> - DCDC2 as DVDD supply
Are you sure of that? That's typically the CPU power supply. Also I
can't find it below. Should that read DLDO2 instead?
> - DCDC1 as VCC-DSI supply
Can't find this below, either. Is it DLDO1?
> - PD24 gpio for reset pin
> - PD23 gpio for backlight enable pin
>
> Signed-off-by: Jagan Teki
> ---
> .../allwinner/sun50i-a64-amarula-relic.dts| 46
> +++ 1 file changed, 46 insertions(+)
>
> diff --git
> a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts index
> 6cb2b7f0c817..ecc0d8094815 100644 ---
> a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts +++
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts @@ -9,6
> +9,7 @@ #include "sun50i-a64.dtsi"
> #include
> +#include
>
> / {
> model = "Amarula A64-Relic";
> @@ -18,6 +19,14 @@
> serial0 =
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <1 2 4 8 16 32 64 128 512>;
> + default-brightness-level = <2>;
> + enable-gpios = < 3 23 GPIO_ACTIVE_HIGH>; /*
> LCD-BL-EN: PD23 */
> + };
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -30,6 +39,28 @@
> };
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + vcc-dsi-supply = <_dldo1>;
Ah, there we have the SoC DSI power supply I was missing for the
BPi-M64 patch.
But is it DLDO1 or DCDC1, like you wrote above?
> + status = "okay";
> +
> + panel@0 {
> + compatible = "techstar,ts8550b";
> + reg = <0>;
> + avdd-supply = <_dc1sw>;
> + dvdd-supply = <_dldo2>;
> + reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /*
> LCD-RST: PD24 */
> + backlight = <>;
> + };
> +};
> +
> {
> status = "okay";
> };
> @@ -72,6 +103,12 @@
> status = "okay";
> };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin>;
> + status = "okay";
> +};
> +
> _rsb {
> status = "okay";
>
> @@ -107,6 +144,15 @@
> regulator-name = "vcc-pll-avcc";
> };
>
> +_dc1sw {
> + /*
> + * This regulator also indirectly drives the PD pingroup
> GPIOs,
> + * which also controls the power LED.
> + */
Is that true for this board as well or is this just a copy
leftover from the BananaPi-M64? If not, you should loose the
regulator-always-on property.
> + regulator-always-on;
> + regulator-name = "vcc-phy";
Shouldn't this be called "vcc-dsi" or so?
Cheers,
Andre.
> +};
> +
> _dcdc1 {
> regulator-always-on;
> regulator-min-microvolt = <330>;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 25/26] [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Bananapi S070WV20-CT16 DSI panel
On Tue, 13 Nov 2018 16:46:32 +0530
Jagan Teki wrote:
Hi,
> This patch add support for Bananapi S070WV20-CT16 DSI panel to
> BPI-M64 board.
>
> DSI panel connected via board DSI port with,
> - DC1SW as AVDD supply
Are you sure of that? I don't see anything in the schematic to support
this. The only power lines that go to the DSI connector are DCDC1 and
PS. DC1SW is only connected to PortD on the SoC and to the Ethernet PHY.
Is there anything I miss?
> - DCDC1 as DVDD supply
That seems right, but doesn't match with what you write below.
> - PD6 gpio for reset pin
> - PD5 gpio for backlight enable pin
> - PD7 gpio for backlight vdd supply
>
> Signed-off-by: Jagan Teki
> ---
> .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 42
> +++ 1 file changed, 42 insertions(+)
>
> diff --git
> a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts index
> ef1c90401bb2..6cb010e3bbd9 100644 ---
> a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts +++
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts @@ -45,6
> +45,7 @@ #include "sun50i-a64.dtsi"
> #include
> +#include
>
> / {
> model = "BananaPi-M64";
> @@ -56,6 +57,15 @@
> serial1 =
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <1 2 4 8 16 32 64 128 512>;
> + default-brightness-level = <2>;
> + enable-gpios = < 3 5 GPIO_ACTIVE_HIGH>; /*
> LCD-BL-EN: PD5 */
> + power-supply = <_vdd_backlight>;
> + };
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -91,6 +101,15 @@
> };
> };
>
> + reg_vdd_backlight: vdd-backlight {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd-backlight";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 3 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN:
> PD7 */
> + enable-active-high;
> + };
> +
> wifi_pwrseq: wifi_pwrseq {
> compatible = "mmc-pwrseq-simple";
> reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> @@ -101,6 +120,23 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + panel@0 {
> + compatible = "bananapi,s070wv20-ct16-icn6211";
> + reg = <0>;
> + avdd-supply = <_dc1sw>;
As mentioned above, I don't see this on the DSI connector.
> + dvdd-supply = <_dldo1>;
Mmh, this line is connected to the *SoC*, to drive the DSI data lines
or the DPHY, presumably. So I wouldn't expect it in the panel node, but
rather in the DPHY or DSI node. Although I can't find a power-supply
property in those bindings.
Cheers,
Andre.
> + reset-gpios = < 3 6 GPIO_ACTIVE_HIGH>; /*
> LCD-RST: PD6 */
> + backlight = <>;
> + };
> +};
> +
> {
> status = "okay";
> };
> @@ -193,6 +229,12 @@
> status = "okay";
> };
>
> +_pwm {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pwm_pin>;
> + status = "okay";
> +};
> +
> _rsb {
> status = "okay";
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2] drm/xen-front: fix pointer casts
Hi, On 25/05/18 06:32, Oleksandr Andrushchenko wrote: > On 05/23/2018 02:46 PM, Juergen Gross wrote: >> On 23/05/18 13:36, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> Building for a 32-bit target results in warnings from casting >>> between a 32-bit pointer and a 64-bit integer. Fix the warnings >>> by casting those pointers to uintptr_t first. >>> >>> Signed-off-by: Oleksandr Andrushchenko >>> >> Reviewed-by: Juergen Gross > Thank you, applied to drm-misc-next Is this the right branch? Shouldn't this go to drm-misc-fixes instead, so it reaches the tree before the 4.18 release? Just stumbled over the issue when compiling 4.18-rc1 for arm32, so it definitely needs fixing in this cycle. Cheers, Andre. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 24/24] drm/lima: add makefile and kconfig
On 05/23/2018 17:16, Marek Vasut wrote: > On 05/18/2018 11:28 AM, Qiang Yu wrote: >> From: Lima Project Developers >> >> Signed-off-by: Qiang Yu >> Signed-off-by: Neil Armstrong >> Signed-off-by: Simon Shields >> Signed-off-by: Heiko Stuebner >> --- >> drivers/gpu/drm/Kconfig | 2 ++ >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/lima/Kconfig | 9 + >> drivers/gpu/drm/lima/Makefile | 19 +++ >> 4 files changed, 31 insertions(+) >> create mode 100644 drivers/gpu/drm/lima/Kconfig >> create mode 100644 drivers/gpu/drm/lima/Makefile >> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index deeefa7a1773..f00d529ee034 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig" >> >> source "drivers/gpu/drm/tve200/Kconfig" >> >> +source "drivers/gpu/drm/lima/Kconfig" >> + >> # Keep legacy drivers last >> >> menuconfig DRM_LEGACY >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >> index 50093ff4479b..aba686e41d6b 100644 >> --- a/drivers/gpu/drm/Makefile >> +++ b/drivers/gpu/drm/Makefile >> @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB) += mxsfb/ >> obj-$(CONFIG_DRM_TINYDRM) += tinydrm/ >> obj-$(CONFIG_DRM_PL111) += pl111/ >> obj-$(CONFIG_DRM_TVE200) += tve200/ >> +obj-$(CONFIG_DRM_LIMA) += lima/ >> diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig >> new file mode 100644 >> index ..4ce9ac2e8204 >> --- /dev/null >> +++ b/drivers/gpu/drm/lima/Kconfig >> @@ -0,0 +1,9 @@ >> + >> +config DRM_LIMA >> + tristate "LIMA (DRM support for ARM Mali 400/450 GPU)" >> + depends on DRM >> + depends on ARCH_SUNXI || ARCH_ROCKCHIP || ARCH_EXYNOS || ARCH_MESON > > You can add ARCH_ZYNQMP here too , it has Mali 400 MP2. Well, as Qiang Yu already figured, it seems much smarter to not enumerate every possible platform here. More than that, the Kconfig depends should be strictly technical. There is nothing in this driver which is ARM specific, in fact I managed to compile it for x86-64 as well (with some small fix in a random header file). In fact there are x86-64 based SoCs pairing Intel Atom cores with a Mali GPUs: https://en.wikipedia.org/wiki/Rockchip#Tablet_processors_with_integrated_modem So you can get rid of this whole line at all, meaning you don't even need the "depends on ARM || ARM64 || COMPILE_TEST" you have in your gitlab repo. Cheers, Andre. > > -- > Best regards, > Marek Vasut > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: sun4i: fix LPAE warnings
When the sun4i DRM driver is compiled with LPAE enabled, dma_addr_t turns
into a 64-bit type, which causes warnings with some debug printks:
=
In file included from
drivers/gpu/drm/sun4i/sun4i_backend.c:13::
drivers/gpu/drm/sun4i/sun4i_backend.c: In function
'sun4i_backend_update_layer_buffer':
drivers/gpu/drm/sun4i/sun4i_backend.c:193:19: warning:
format '%x' expects argument of type 'unsigned int', but argument 3 has
type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
DRM_DEBUG_DRIVER("Using GEM @ 0x%x\n", gem->paddr);
^
include/drm/drmP.h:207:34: note: in definition of macro
'DRM_DEBUG_DRIVER'
drm_ut_debug_printk(__func__, fmt, ##args); \
.
Use the proper printk format specifier [1] for dma_addr_t which takes
care of those differences.
Signed-off-by: Andre Przywara
[1] Documentation/printk-formats.txt
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index f7a15c1..2568e7d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -190,7 +190,7 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend
*backend,
/* Get the physical address of the buffer in memory */
gem = drm_fb_cma_get_gem_obj(fb, 0);
- DRM_DEBUG_DRIVER("Using GEM @ 0x%x\n", gem->paddr);
+ DRM_DEBUG_DRIVER("Using GEM @ 0x%pad\n", >paddr);
/* Compute the start of the displayed memory */
bpp = drm_format_plane_cpp(fb->pixel_format, 0);
@@ -198,7 +198,7 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend
*backend,
paddr += (state->src_x >> 16) * bpp;
paddr += (state->src_y >> 16) * fb->pitches[0];
- DRM_DEBUG_DRIVER("Setting buffer address to 0x%x\n", paddr);
+ DRM_DEBUG_DRIVER("Setting buffer address to 0x%pad\n", );
/* Write the 32 lower bits of the address (in bits) */
lo_paddr = paddr << 3;
--
2.8.2
[PATCH v2 2/2] drm: sunxi: Add a basic DRM driver for Allwinner DE2
Hi, On 02/02/16 17:19, Jean-Francois Moine wrote: > On Wed, 20 Jan 2016 11:14:38 + > Andre Przywara wrote: > >> I haven't looked at it in detail yet, I just tried to compile it for >> ARM64 to prepare for a test on the Allwinner A64. >> >> So just two things I spotted below: > > Hi André, > > I fixed them in the v3 patch request. Thanks for that. > Have you succeeded to get video on the A64? No, but I haven't tried yet. I am tempted to give it a go, though. I guess this "headless Linux" term has scared some backers, who had more associations with Sleepy Hollow than with a serial terminal ;-) Can you sketch (or point me to) what I need to do? Just a simple-framebuffer DT node? I take it that the driver does not depend on any kind of U-Boot initialisation, but instead takes care of this itself? And would this pave the way for fbturbo also? Please excuse my probably silly questions, I am more of a headless horseman ;-) Cheers, Andre.
[PATCH v2 2/2] drm: sunxi: Add a basic DRM driver for Allwinner DE2
Hi Jean-Francois,
I haven't looked at it in detail yet, I just tried to compile it for
ARM64 to prepare for a test on the Allwinner A64.
So just two things I spotted below:
On 15/01/16 15:54, Jean-Francois Moine wrote:
> In recent SoCs, as the H3, Allwinner uses a new display interface, DE2.
> This patch adds a DRM video driver for this interface.
>
> Signed-off-by: Jean-Francois Moine
> ---
> Changes:
> - remarks from Russell King
> - DT documentation added
> - working resolution change with xrandr
> - removal of the HDMI driver
> ---
> .../devicetree/bindings/display/sunxi.txt | 81
> drivers/gpu/drm/Kconfig| 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/sunxi/Kconfig | 20 +
> drivers/gpu/drm/sunxi/Makefile | 7 +
> drivers/gpu/drm/sunxi/de2_crtc.c | 425 +++
> drivers/gpu/drm/sunxi/de2_crtc.h | 43 ++
> drivers/gpu/drm/sunxi/de2_de.c | 461
> +
> drivers/gpu/drm/sunxi/de2_drm.h| 55 +++
> drivers/gpu/drm/sunxi/de2_drv.c| 376 +
> drivers/gpu/drm/sunxi/de2_plane.c | 114 +
> 11 files changed, 1585 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi.txt
> create mode 100644 drivers/gpu/drm/sunxi/Kconfig
> create mode 100644 drivers/gpu/drm/sunxi/Makefile
> create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
> create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
> create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
> create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi.txt
> b/Documentation/devicetree/bindings/display/sunxi.txt
> new file mode 100644
> index 000..1070bf0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi.txt
> @@ -0,0 +1,81 @@
> +Allwinner sunxi display subsystem
> +=
> +
> +The sunxi display subsystems contain a display controller (DE),
> +one or two LCD controllers (TCON) and their external interfaces.
> +
> +Display controller
> +==
> +
> +Required properties:
> +
> +- compatible: value should be one of the following
> + "allwinner,sun8i-h3-display-engine"
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: must contain
> + gate: for DE activation
> + clock: DE clock
> +
> +- resets: phandle to the reset of the device
> +
> +- ports: phandle's to the LCD ports
> +
> +LCD controller
> +==
> +
> +Required properties:
> +
> +- compatible: value should be one of the following
> + "allwinner,sun8i-h3-lcd"
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: must contain
> + gate: for LCD activation
> + clock: pixel clock
> +
> +- resets: phandle to the reset of the device
> +
> +- port: port node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + de: de-controller at 0100 {
> + compatible = "allwinner,sun8i-h3-display-engine";
> + ...
> + clocks = <_gates 44>, <_clk>;
> + clock-names = "gate", "clock";
> + resets = <_rst 44>;
> + ports = <_p>;
> + };
> +
> + lcd0: lcd-controller at 01c0c000 {
> + compatible = "allwinner,sun8i-h3-lcd";
> + ...
> + clocks = <_gates 35>, <_clk>;
> + clock-names = "gate", "clock";
> + resets = <_rst 35>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + lcd0_p: port {
> + lcd0_ep: endpoint {
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
> +
> + hdmi: hdmi at 01ee {
> + ...
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port {
> + hdmi_ep: endpoint {
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index c4bf9a1..edef0c8 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -266,3 +266,5 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig"
> source "drivers/gpu/drm/imx/Kconfig"
>
> source "drivers/gpu/drm/vc4/Kconfig"
> +
> +source "drivers/gpu/drm/sunxi/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
