On Tue, Jun 2, 2020 at 5:52 AM Maxime Ripard <[email protected]> wrote:
>
> Hi Eric,
>
> On Wed, May 27, 2020 at 09:33:44AM -0700, Eric Anholt wrote:
> > On Wed, May 27, 2020 at 8:49 AM Maxime Ripard <[email protected]> wrote:
> > >
> > > In order to prevent timeouts and stalls in the pipeline, the core clock
> > > needs to be maxed at 500MHz during a modeset on the BCM2711.
> >
> > Like, the whole system's core clock?
>
> Yep, unfortunately...
>
> > How is it reasonable for some device driver to crank the system's core
> > clock up and back down to some fixed-in-the-driver frequency? Sounds
> > like you need some sort of opp thing here.
>
> That frequency is the minimum rate of that clock. However, since other
> devices have similar requirements (unicam in particular) with different
> minimum requirements, we will switch to setting a minimum rate instead
> of enforcing a particular rate, so that patch would be essentially
> s/clk_set_rate/clk_set_min_rate/.

clk_set_min_rate makes a lot more sense to me. r-b with that obvious
change. Thanks!

2020-06-02 20:15:53

by Stefan Wahren

[permalink] [raw]

Subject: Re: [PATCH v3 000/105] drm/vc4: Support BCM2711 Display Pipeline

Hi Maxime,

Am 27.05.20 um 17:47 schrieb Maxime Ripard:
> Hi everyone,
>
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>
> The main differences are that there's two HDMI controllers and that there's
> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> have only 3 FIFOs. Both of those differences are breaking a bunch of
> expectations in the driver, so we first need a good bunch of cleanup and
> reworks to introduce support for the new controllers.
>
> Similarly, the HDMI controller has all its registers shuffled and split in
> multiple controllers now, so we need a bunch of changes to support this as
> well.
>
> Only the HDMI support is enabled for now (even though the DPI output has
> been tested too).
>
> This is based on the firmware clocks series sent separately:
> https://lore.kernel.org/lkml/cover.662a8d401787ef33780d91252a352de91dc4be10.1590594293.git-series.maxime@cerno.tech/
>
> Let me know if you have any comments
> Maxime
>
> Cc: [email protected]
> Cc: [email protected]
> Cc: Kamal Dasu <[email protected]>
> Cc: [email protected]
> Cc: Michael Turquette <[email protected]>
> Cc: Philipp Zabel <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: Stephen Boyd <[email protected]>
>
> Changes from v2:
> - Rebased on top of next-20200526
i assume this is the reason why this series doesn't completely apply
against drm-misc-next.

2020-06-03 09:46:18

Hi Maxime,

On Wed, 2020-05-27 at 17:47 +0200, Maxime Ripard wrote:
> The HDMI block has a block that controls clocks and reset signals to the
> HDMI0 and HDMI1 controllers.

Why not having two separate drivers?

> Let's expose that through a clock driver implementing a clock and reset
> provider.
>
> Cc: Michael Turquette <[email protected]>
> Cc: Stephen Boyd <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Reviewed-by: Stephen Boyd <[email protected]>
> Signed-off-by: Maxime Ripard <[email protected]>
> ---
> drivers/clk/bcm/Kconfig | 11 +++-
> drivers/clk/bcm/Makefile | 1 +-
> drivers/clk/bcm/clk-bcm2711-dvp.c | 127 +++++++++++++++++++++++++++++++-
> 3 files changed, 139 insertions(+)
> create mode 100644 drivers/clk/bcm/clk-bcm2711-dvp.c
>
> diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
> index 8c83977a7dc4..784f12c72365 100644
> --- a/drivers/clk/bcm/Kconfig
> +++ b/drivers/clk/bcm/Kconfig
> @@ -1,4 +1,15 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +
> +config CLK_BCM2711_DVP
> + tristate "Broadcom BCM2711 DVP support"
> + depends on ARCH_BCM2835 ||COMPILE_TEST
> + depends on COMMON_CLK
> + default ARCH_BCM2835
> + select RESET_SIMPLE
> + help
> + Enable common clock framework support for the Broadcom BCM2711
> + DVP Controller.
> +
> config CLK_BCM2835
> bool "Broadcom BCM2835 clock support"
> depends on ARCH_BCM2835 || ARCH_BRCMSTB || COMPILE_TEST
> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> index 0070ddf6cdd2..2c1349062147 100644
> --- a/drivers/clk/bcm/Makefile
> +++ b/drivers/clk/bcm/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_CLK_BCM_KONA) += clk-kona-setup.o
> obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
> obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o
> obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o
> clk-iproc-asiu.o
> +obj-$(CONFIG_CLK_BCM2835) += clk-bcm2711-dvp.o
> obj-$(CONFIG_CLK_BCM2835) += clk-bcm2835.o
> obj-$(CONFIG_CLK_BCM2835) += clk-bcm2835-aux.o
> obj-$(CONFIG_CLK_RASPBERRYPI) += clk-raspberrypi.o
> diff --git a/drivers/clk/bcm/clk-bcm2711-dvp.c b/drivers/clk/bcm/clk-bcm2711-
> dvp.c
> new file mode 100644
> index 000000000000..c1c4b5857d32
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm2711-dvp.c
> @@ -0,0 +1,127 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +// Copyright 2020 Cerno
> +
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset-controller.h>
> +#include <linux/reset/reset-simple.h>
> +
> +#define DVP_HT_RPI_SW_INIT 0x04
> +#define DVP_HT_RPI_MISC_CONFIG 0x08
> +
> +#define NR_CLOCKS 2
> +#define NR_RESETS 6
> +
> +struct clk_dvp {
> + struct clk_hw_onecell_data *data;
> + struct reset_simple_data reset;
> +};
> +
> +static const struct clk_parent_data clk_dvp_parent = {
> + .index = 0,
> +};
> +
> +static int clk_dvp_probe(struct platform_device *pdev)
> +{
> + struct clk_hw_onecell_data *data;
> + struct resource *res;
> + struct clk_dvp *dvp;
> + void __iomem *base;
> + int ret;
> +
> + dvp = devm_kzalloc(&pdev->dev, sizeof(*dvp), GFP_KERNEL);
> + if (!dvp)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, dvp);
> +
> + dvp->data = devm_kzalloc(&pdev->dev,
> + struct_size(dvp->data, hws, NR_CLOCKS),
> + GFP_KERNEL);
> + if (!dvp->data)
> + return -ENOMEM;
> + data = dvp->data;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, res);

I think the cool function to use these days is
devm_platform_get_and_ioremap_resource().

Regards,
Nicolas

> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + dvp->reset.rcdev.owner = THIS_MODULE;
> + dvp->reset.rcdev.nr_resets = NR_RESETS;
> + dvp->reset.rcdev.ops = &reset_simple_ops;
> + dvp->reset.rcdev.of_node = pdev->dev.of_node;
> + dvp->reset.membase = base + DVP_HT_RPI_SW_INIT;
> + spin_lock_init(&dvp->reset.lock);
> +
> + ret = reset_controller_register(&dvp->reset.rcdev);
> + if (ret)
> + return ret;
> +
> + data->hws[0] = clk_hw_register_gate_parent_data(&pdev->dev,
> + "hdmi0-108MHz",
> + &clk_dvp_parent, 0,
> + base +
> DVP_HT_RPI_MISC_CONFIG, 3,
> + CLK_GATE_SET_TO_DISABLE,
> + &dvp->reset.lock);
> + if (IS_ERR(data->hws[0])) {
> + ret = PTR_ERR(data->hws[0]);
> + goto unregister_reset;
> + }
> +
> + data->hws[1] = clk_hw_register_gate_parent_data(&pdev->dev,
> + "hdmi1-108MHz",
> + &clk_dvp_parent, 0,
> + base +
> DVP_HT_RPI_MISC_CONFIG, 4,
> + CLK_GATE_SET_TO_DISABLE,
> + &dvp->reset.lock);
> + if (IS_ERR(data->hws[1])) {
> + ret = PTR_ERR(data->hws[1]);
> + goto unregister_clk0;
> + }
> +
> + data->num = NR_CLOCKS;
> + ret = of_clk_add_hw_provider(pdev->dev.of_node, of_clk_hw_onecell_get,

> + data);
> + if (ret)
> + goto unregister_clk1;
> +
> + return 0;
> +
> +unregister_clk1:
> + clk_hw_unregister_gate(data->hws[1]);
> +
> +unregister_clk0:
> + clk_hw_unregister_gate(data->hws[0]);
> +
> +unregister_reset:
> + reset_controller_unregister(&dvp->reset.rcdev);
> + return ret;
> +};
> +
> +static int clk_dvp_remove(struct platform_device *pdev)
> +{
> + struct clk_dvp *dvp = platform_get_drvdata(pdev);
> + struct clk_hw_onecell_data *data = dvp->data;
> +
> + clk_hw_unregister_gate(data->hws[1]);
> + clk_hw_unregister_gate(data->hws[0]);
> + reset_controller_unregister(&dvp->reset.rcdev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id clk_dvp_dt_ids[] = {
> + { .compatible = "brcm,brcm2711-dvp", },
> + { /* sentinel */ }
> +};
> +
> +static struct platform_driver clk_dvp_driver = {
> + .probe = clk_dvp_probe,
> + .remove = clk_dvp_remove,
> + .driver = {
> + .name = "brcm2711-dvp",
> + .of_match_table = clk_dvp_dt_ids,
> + },
> +};
> +module_platform_driver(clk_dvp_driver);

Attachments:

signature.asc (499.00 B)
This is a digitally signed message part

2020-06-05 14:40:18

by Maxime Ripard

[permalink] [raw]

Subject: Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders

Hi Stefan,

On Wed, Jun 03, 2020 at 07:32:30PM +0200, Stefan Wahren wrote:
> Am 02.06.20 um 17:54 schrieb Maxime Ripard:
> > On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote:
> >> On Wed, May 27, 2020 at 8:51 AM Maxime Ripard <[email protected]> wrote:
> >>> the vc4_hdmi driver has some custom structures to hold the data it needs to
> >>> associate with the drm_encoder and drm_connector structures.
> >>>
> >>> However, it allocates them separately from the vc4_hdmi structure which
> >>> makes it more complicated than it needs to be.
> >>>
> >>> Move those structures to be contained by vc4_hdmi and update the code
> >>> accordingly.
> >>
> >>> @@ -1220,7 +1219,7 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
> >>> struct drm_device *drm = dev_get_drvdata(master);
> >>> struct vc4_dev *vc4 = drm->dev_private;
> >>> struct vc4_hdmi *hdmi;
> >>> - struct vc4_hdmi_encoder *vc4_hdmi_encoder;
> >>> + struct drm_encoder *encoder;
> >>> struct device_node *ddc_node;
> >>> u32 value;
> >>> int ret;
> >>> @@ -1229,14 +1228,10 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
> >>> if (!hdmi)
> >>> return -ENOMEM;
> >>>
> >>> - vc4_hdmi_encoder = devm_kzalloc(dev, sizeof(*vc4_hdmi_encoder),
> >>> - GFP_KERNEL);
> >>> - if (!vc4_hdmi_encoder)
> >>> - return -ENOMEM;
> >>> - vc4_hdmi_encoder->base.type = VC4_ENCODER_TYPE_HDMI0;
> >>> - hdmi->encoder = &vc4_hdmi_encoder->base.base;
> >>> -
> >>> hdmi->pdev = pdev;
> >>> + encoder = &hdmi->encoder.base.base;
> >>> + encoder->base.type = VC4_ENCODER_TYPE_HDMI0;
> >> Wait, does this patch build?
> > All those patches were build tested, so yep
> >
> >> setting struct drm_encoder->base.type = VC4_* seems very wrong, when
> >> previously we were setting struct vc4_hdmi_encoder->base.type (struct
> >> vc4_encoder->type).
> > So the structure layout now is that vc4_hdmi embeds vc4_hdmi_encoder as
> > encoder. So &hdmi->encoder is a pointer to vc4_hdmi_encoder.
> > vc4_hdmi_encoder's base is since that patch a struct vc4_encoder. and
> > vc4_encoder's base is a drm_encoder.
> >
> > so encoder being a drm_encoder is correct there.
> >
> > However, drm_encoder's base is drm_mode_object that does have a type
> > field, which is an uint32_t, which will accept a VC4_ENCODER_TYPE_* just
> > fine...
> >
> > Now, drm_encoder_init will then kick in and call drm_mode_object_add
> > which will override it to a proper value and since the clock select bit
> > in the PV is the same for both HDMI0 and HDMI1, everything works just
> > fine...
> >
> > Good catch, I'll fix it. And I guess it's a good indication we don't
> > need a separate HDMI0 and HDMI1 encoder type.
> >
> FWIW this is the first patch which breaks X on my Raspberry Pi 3 B.
>
> Here are the bisect results:
>
> 587d6e4a529a8d807a5c0bae583dd432d77064d6 bad (black screen, no heartbeat)
>
> b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8 good
>
> 2c6a651cac6359cb0244a40d3b7a14e72918f169 good
>
> 1705c3cb40906863ec0d24ee5ea5092f5ee2e994 bad (black screen, but heartbeat)
>
> 601527fea6bb226abd088a864e74b25368218e87 good
>
> 2165607ede34d229d0cbce916c70c7fb6c0337be good
>
> f094f388fc2df848227e2ae648df2c97872df42b good
>
> 020de18840a1075b2671736c6cc2e451030fad74 bad (black screen, but heartbeat)
>
> 4c4da3823e4d1a8189e96a59a79451fff372f70b good
>
> 020de18840a1075b2671736c6cc2e451030fad74 is the first bad commit
> commit 020de18840a1075b2671736c6cc2e451030fad74
> Author: Maxime Ripard <[email protected]>
> Date:?? Mon Jan 6 17:17:29 2020 +0100
>
> ??? drm/vc4: hdmi: rework connectors and encoders
> ???
> ??? the vc4_hdmi driver has some custom structures to hold the data it
> needs to
> ??? associate with the drm_encoder and drm_connector structures.
> ???
> ??? However, it allocates them separately from the vc4_hdmi structure which
> ??? makes it more complicated than it needs to be.
> ???
> ??? Move those structures to be contained by vc4_hdmi and update the code
> ??? accordingly.
> ???
> ??? Signed-off-by: Maxime Ripard <[email protected]>

So it looks like there was two issues on the Pi3. The first one was
causing the timeouts (and therefore likely the black screen but
heartbeat case you had) and I've fixed it.

However, I can indeed reproduce the case with the black screen / no
heartbeat you mentionned. My bisection however returns that it's the
patch "drm/vc4: hdmi: Implement finer-grained hooks" that is at fault.
I've pushed my updated branch, if you have some spare time, it would be
great if you could confirm it on your Pi.

Thanks!
Maxime

Attachments:

(No filename) (4.77 kB)
signature.asc (235.00 B)
Download all attachments

2020-06-05 17:48:23

On Fri, 2020-06-05 at 19:43 +0200, Maxime Ripard wrote:
> Hi Nicolas,
>
> On Thu, Jun 04, 2020 at 07:26:07PM +0200, Nicolas Saenz Julienne wrote:
> > On Wed, 2020-05-27 at 17:47 +0200, Maxime Ripard wrote:
> > > The HDMI block has a block that controls clocks and reset signals to the
> > > HDMI0 and HDMI1 controllers.
> >
> > Why not having two separate drivers?
>
> They share the same address space, so it wouldn't really make sense to
> split it into two drivers and an MFD, especially when the clock/reset
> association is fairly common.

Fair enough.

>
> > > Let's expose that through a clock driver implementing a clock and reset
> > > provider.
> > >
> > > Cc: Michael Turquette <[email protected]>
> > > Cc: Stephen Boyd <[email protected]>
> > > Cc: Rob Herring <[email protected]>
> > > Cc: [email protected]
> > > Cc: [email protected]
> > > Reviewed-by: Stephen Boyd <[email protected]>
> > > Signed-off-by: Maxime Ripard <[email protected]>
> > > ---
> > > drivers/clk/bcm/Kconfig | 11 +++-
> > > drivers/clk/bcm/Makefile | 1 +-
> > > drivers/clk/bcm/clk-bcm2711-dvp.c | 127 +++++++++++++++++++++++++++++++-
> > > 3 files changed, 139 insertions(+)
> > > create mode 100644 drivers/clk/bcm/clk-bcm2711-dvp.c
> > >
> > > diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
> > > index 8c83977a7dc4..784f12c72365 100644
> > > --- a/drivers/clk/bcm/Kconfig
> > > +++ b/drivers/clk/bcm/Kconfig
> > > @@ -1,4 +1,15 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > > +
> > > +config CLK_BCM2711_DVP
> > > + tristate "Broadcom BCM2711 DVP support"
> > > + depends on ARCH_BCM2835 ||COMPILE_TEST
> > > + depends on COMMON_CLK
> > > + default ARCH_BCM2835
> > > + select RESET_SIMPLE
> > > + help
> > > + Enable common clock framework support for the Broadcom BCM2711
> > > + DVP Controller.
> > > +
> > > config CLK_BCM2835
> > > bool "Broadcom BCM2835 clock support"
> > > depends on ARCH_BCM2835 || ARCH_BRCMSTB || COMPILE_TEST
> > > diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> > > index 0070ddf6cdd2..2c1349062147 100644
> > > --- a/drivers/clk/bcm/Makefile
> > > +++ b/drivers/clk/bcm/Makefile
> > > @@ -6,6 +6,7 @@ obj-$(CONFIG_CLK_BCM_KONA) += clk-kona-setup.o
> > > obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
> > > obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o
> > > obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o
> > > clk-iproc-asiu.o
> > > +obj-$(CONFIG_CLK_BCM2835) += clk-bcm2711-dvp.o
> > > obj-$(CONFIG_CLK_BCM2835) += clk-bcm2835.o
> > > obj-$(CONFIG_CLK_BCM2835) += clk-bcm2835-aux.o
> > > obj-$(CONFIG_CLK_RASPBERRYPI) += clk-raspberrypi.o
> > > diff --git a/drivers/clk/bcm/clk-bcm2711-dvp.c b/drivers/clk/bcm/clk-
> > > bcm2711-
> > > dvp.c
> > > new file mode 100644
> > > index 000000000000..c1c4b5857d32
> > > --- /dev/null
> > > +++ b/drivers/clk/bcm/clk-bcm2711-dvp.c
> > > @@ -0,0 +1,127 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +// Copyright 2020 Cerno
> > > +
> > > +#include <linux/clk-provider.h>
> > > +#include <linux/module.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/reset-controller.h>
> > > +#include <linux/reset/reset-simple.h>
> > > +
> > > +#define DVP_HT_RPI_SW_INIT 0x04
> > > +#define DVP_HT_RPI_MISC_CONFIG 0x08
> > > +
> > > +#define NR_CLOCKS 2
> > > +#define NR_RESETS 6
> > > +
> > > +struct clk_dvp {
> > > + struct clk_hw_onecell_data *data;
> > > + struct reset_simple_data reset;
> > > +};
> > > +
> > > +static const struct clk_parent_data clk_dvp_parent = {
> > > + .index = 0,
> > > +};
> > > +
> > > +static int clk_dvp_probe(struct platform_device *pdev)
> > > +{
> > > + struct clk_hw_onecell_data *data;
> > > + struct resource *res;
> > > + struct clk_dvp *dvp;
> > > + void __iomem *base;
> > > + int ret;
> > > +
> > > + dvp = devm_kzalloc(&pdev->dev, sizeof(*dvp), GFP_KERNEL);
> > > + if (!dvp)
> > > + return -ENOMEM;
> > > + platform_set_drvdata(pdev, dvp);
> > > +
> > > + dvp->data = devm_kzalloc(&pdev->dev,
> > > + struct_size(dvp->data, hws, NR_CLOCKS),
> > > + GFP_KERNEL);
> > > + if (!dvp->data)
> > > + return -ENOMEM;
> > > + data = dvp->data;
> > > +
> > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > + base = devm_ioremap_resource(&pdev->dev, res);
> >
> > I think the cool function to use these days is
> > devm_platform_get_and_ioremap_resource().
>
> i'll change it, thanks!

Reviewed-by: Nicolas Saenz Julienne <[email protected]>

Regards,
Nicolas

Attachments:

signature.asc (499.00 B)
This is a digitally signed message part

2020-06-06 08:08:53

by Stefan Wahren

[permalink] [raw]

Subject: Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders

Hi Maxime,

Am 05.06.20 um 16:35 schrieb Maxime Ripard:
> Hi Stefan,
>
> On Wed, Jun 03, 2020 at 07:32:30PM +0200, Stefan Wahren wrote:
>> Am 02.06.20 um 17:54 schrieb Maxime Ripard:
>>> On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote:
>>>> On Wed, May 27, 2020 at 8:51 AM Maxime Ripard <[email protected]> wrote:
>>>>> the vc4_hdmi driver has some custom structures to hold the data it needs to
>>>>> associate with the drm_encoder and drm_connector structures.
>>>>>
>>>>> However, it allocates them separately from the vc4_hdmi structure which
>>>>> makes it more complicated than it needs to be.
>>>>>
>>>>> Move those structures to be contained by vc4_hdmi and update the code
>>>>> accordingly.
>>>>> @@ -1220,7 +1219,7 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
>>>>> struct drm_device *drm = dev_get_drvdata(master);
>>>>> struct vc4_dev *vc4 = drm->dev_private;
>>>>> struct vc4_hdmi *hdmi;
>>>>> - struct vc4_hdmi_encoder *vc4_hdmi_encoder;
>>>>> + struct drm_encoder *encoder;
>>>>> struct device_node *ddc_node;
>>>>> u32 value;
>>>>> int ret;
>>>>> @@ -1229,14 +1228,10 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
>>>>> if (!hdmi)
>>>>> return -ENOMEM;
>>>>>
>>>>> - vc4_hdmi_encoder = devm_kzalloc(dev, sizeof(*vc4_hdmi_encoder),
>>>>> - GFP_KERNEL);
>>>>> - if (!vc4_hdmi_encoder)
>>>>> - return -ENOMEM;
>>>>> - vc4_hdmi_encoder->base.type = VC4_ENCODER_TYPE_HDMI0;
>>>>> - hdmi->encoder = &vc4_hdmi_encoder->base.base;
>>>>> -
>>>>> hdmi->pdev = pdev;
>>>>> + encoder = &hdmi->encoder.base.base;
>>>>> + encoder->base.type = VC4_ENCODER_TYPE_HDMI0;
>>>> Wait, does this patch build?
>>> All those patches were build tested, so yep
>>>
>>>> setting struct drm_encoder->base.type = VC4_* seems very wrong, when
>>>> previously we were setting struct vc4_hdmi_encoder->base.type (struct
>>>> vc4_encoder->type).
>>> So the structure layout now is that vc4_hdmi embeds vc4_hdmi_encoder as
>>> encoder. So &hdmi->encoder is a pointer to vc4_hdmi_encoder.
>>> vc4_hdmi_encoder's base is since that patch a struct vc4_encoder. and
>>> vc4_encoder's base is a drm_encoder.
>>>
>>> so encoder being a drm_encoder is correct there.
>>>
>>> However, drm_encoder's base is drm_mode_object that does have a type
>>> field, which is an uint32_t, which will accept a VC4_ENCODER_TYPE_* just
>>> fine...
>>>
>>> Now, drm_encoder_init will then kick in and call drm_mode_object_add
>>> which will override it to a proper value and since the clock select bit
>>> in the PV is the same for both HDMI0 and HDMI1, everything works just
>>> fine...
>>>
>>> Good catch, I'll fix it. And I guess it's a good indication we don't
>>> need a separate HDMI0 and HDMI1 encoder type.
>>>
>> FWIW this is the first patch which breaks X on my Raspberry Pi 3 B.
>>
>> Here are the bisect results:
>>
>> 587d6e4a529a8d807a5c0bae583dd432d77064d6 bad (black screen, no heartbeat)
>>
>> b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8 good
>>
>> 2c6a651cac6359cb0244a40d3b7a14e72918f169 good
>>
>> 1705c3cb40906863ec0d24ee5ea5092f5ee2e994 bad (black screen, but heartbeat)
>>
>> 601527fea6bb226abd088a864e74b25368218e87 good
>>
>> 2165607ede34d229d0cbce916c70c7fb6c0337be good
>>
>> f094f388fc2df848227e2ae648df2c97872df42b good
>>
>> 020de18840a1075b2671736c6cc2e451030fad74 bad (black screen, but heartbeat)
>>
>> 4c4da3823e4d1a8189e96a59a79451fff372f70b good
>>
>> 020de18840a1075b2671736c6cc2e451030fad74 is the first bad commit
>> commit 020de18840a1075b2671736c6cc2e451030fad74
>> Author: Maxime Ripard <[email protected]>
>> Date:?? Mon Jan 6 17:17:29 2020 +0100
>>
>> ??? drm/vc4: hdmi: rework connectors and encoders
>> ???
>> ??? the vc4_hdmi driver has some custom structures to hold the data it
>> needs to
>> ??? associate with the drm_encoder and drm_connector structures.
>> ???
>> ??? However, it allocates them separately from the vc4_hdmi structure which
>> ??? makes it more complicated than it needs to be.
>> ???
>> ??? Move those structures to be contained by vc4_hdmi and update the code
>> ??? accordingly.
>> ???
>> ??? Signed-off-by: Maxime Ripard <[email protected]>
> So it looks like there was two issues on the Pi3. The first one was
> causing the timeouts (and therefore likely the black screen but
> heartbeat case you had) and I've fixed it.
>
> However, I can indeed reproduce the case with the black screen / no
> heartbeat you mentionned. My bisection however returns that it's the
> patch "drm/vc4: hdmi: Implement finer-grained hooks" that is at fault.
> I've pushed my updated branch, if you have some spare time, it would be
> great if you could confirm it on your Pi.

yesterday i checked out your latest rpi4-kms branch, but i was still
facing similiar issues with my Raspberry Pi 3 and multi_v7_defconfig
(heartbeat stops, splashscreen freeze, heartbeat is abnormal fast). So i
tried to bisect but the offending commit didn't cause an issue the
second time.

By accident i noticed that a simple reboot seems to hang for at least 8
minutes (using b0523c7b1c9d0edcd the base of your branch). This usually
take a few seconds. So i consider this base on linux-next as too
unstable for reliable testing.

Is it possible to rebase this on something more stable like linux-5.7 or
at least drm-misc-next? This should avoid chasing unrelated issues.

Regards
Stefan

>
> Thanks!
> Maxime

2020-06-08 23:04:24

by Rob Herring (Arm)

[permalink] [raw]

Subject: Re: [PATCH v3 104/105] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings

On Tue, Jun 2, 2020 at 9:08 AM Maxime Ripard <[email protected]> wrote:
>
> Hi Rob,
>
> On Fri, May 29, 2020 at 12:18:33PM -0600, Rob Herring wrote:
> > On Wed, May 27, 2020 at 05:49:14PM +0200, Maxime Ripard wrote:
> > > The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> > > bindings, especially since the registers have been shuffled around in more
> > > register ranges.
> > >
> > > Cc: Rob Herring <[email protected]>
> > > Cc: [email protected]
> > > Signed-off-by: Maxime Ripard <[email protected]>
> > > ---
> > > Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> > > 1 file changed, 109 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > > new file mode 100644
> > > index 000000000000..6091fe3d315b
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > > @@ -0,0 +1,109 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> >
> > Dual license...
> >
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/display/brcm,bcm2711-hdmi.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> > > +
> > > +maintainers:
> > > + - Eric Anholt <[email protected]>
> > > +
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - brcm,bcm2711-hdmi0
> > > + - brcm,bcm2711-hdmi1
> >
> > What's the difference between the 2 blocks?
>
> The register layout and the lane mapping in the PHY change a bit.
>
> > > +
> > > + reg:
> > > + items:
> > > + - description: HDMI controller register range
> > > + - description: DVP register range
> > > + - description: HDMI PHY register range
> > > + - description: Rate Manager register range
> > > + - description: Packet RAM register range
> > > + - description: Metadata RAM register range
> > > + - description: CSC register range
> > > + - description: CEC register range
> > > + - description: HD register range
> > > +
> > > + reg-names:
> > > + items:
> > > + - const: hdmi
> > > + - const: dvp
> > > + - const: phy
> > > + - const: rm
> > > + - const: packet
> > > + - const: metadata
> > > + - const: csc
> > > + - const: cec
> > > + - const: hd
> > > +
> > > + clocks:
> > > + description: The HDMI state machine clock
> > > +
> > > + clock-names:
> > > + const: hdmi
> > > +
> > > + ddc:
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/phandle
> > > + description: >
> > > + Phandle of the I2C controller used for DDC EDID probing
> >
> > Goes in the connector.
> >
> > And isn't the standard name ddc-i2c-bus?
> >
> > > +
> > > + hpd-gpios:
> > > + description: >
> > > + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> > > + as an interrupt/status bit in the HDMI controller itself)
> >
> > Goes in the connector.
>
> If this was an entirely new binding, I would agree, but this is not
> really the case here.
>
> We discussed it already for the v2, and this binding is essentially the
> same one than the bcm2835 HDMI controller.
>
> I initially sent a patch adding conditionnals for the clocks and regs
> differences too, and you asked to split the binding into a separate file
> to simplify it a bit.

Ah... Best to assume I don't remember what happened last week. ;)

> Supporting both the old binding, and the new one based on the connector
> is going to make the code significantly more complicated, and I'm not
> really sure why we would here.

I'm not really sure I agree on the complexity, but that can be a
discussion for another day.

Reviewed-by: Rob Herring <[email protected]>

Rob

2020-06-10 20:18:59

by Maxime Ripard

[permalink] [raw]

Subject: Re: [PATCH v3 066/105] drm/vc4: txp: Turn the TXP into a CRTC of its own

Hi Emil,

On Thu, May 28, 2020 at 04:51:31PM +0100, Emil Velikov wrote:
> Have you considered splitting the series into several parts and
> focusing on merging one at a time?
> IIRC this the longest series _ever_ submitted to dri-devel, plus it
> seems to be growing with each revision.
>
> Due to the sheer volume, it's likely to miss various points - large or
> small (like below).

Yeah, I know, I wasn't really happy about it either :/ I already removed
some parts of it to reduce it, but I'll try to be more aggressive.

> On Thu, 28 May 2020 at 08:47, Maxime Ripard <[email protected]> wrote:
>
> > +static int vc4_txp_enable_vblank(struct drm_crtc *crtc)
> > +{
> > + return 0;
> > +}
> > +
> > +static void vc4_txp_disable_vblank(struct drm_crtc *crtc) {}
> > +
> Core should handle if these are NULL, so the stubs should not be needed.

I'm really not sure actually. In the general case, you'll want to have
vblank functions, since it doesn't really make sense to have a driver
without it.

We could argue that with writeback, it might be optional like being done
here, but you don't really know if you're going to use a writeback
connector in the CRTC at initialisation time, and all the other
writeback encoders actually seem to use a real CRTC that can output to a
real encoder, and therefore has some proper vblank handling too.

So yeah, it really looks like the check is valid, and that driver is
just the odd case.

Maxime

Attachments:

(No filename) (1.45 kB)
signature.asc (235.00 B)
Download all attachments

2020-06-11 13:49:18

On Sun, Jun 14, 2020 at 06:16:56PM +0200, Stefan Wahren wrote:
> Am 11.06.20 um 15:34 schrieb Maxime Ripard:
> > Hi Stefan,
> >
> > On Sat, Jun 06, 2020 at 10:06:12AM +0200, Stefan Wahren wrote:
> >> Hi Maxime,
> >>
> >> Am 05.06.20 um 16:35 schrieb Maxime Ripard:
> >>> Hi Stefan,
> >>>
> >>> On Wed, Jun 03, 2020 at 07:32:30PM +0200, Stefan Wahren wrote:
> >>>> Am 02.06.20 um 17:54 schrieb Maxime Ripard:
> >>>> FWIW this is the first patch which breaks X on my Raspberry Pi 3 B.
> >>>>
> >>>> Here are the bisect results:
> >>>>
> >>>> 587d6e4a529a8d807a5c0bae583dd432d77064d6 bad (black screen, no heartbeat)
> >>>>
> >>>> b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8 good
> >>>>
> >>>> 2c6a651cac6359cb0244a40d3b7a14e72918f169 good
> >>>>
> >>>> 1705c3cb40906863ec0d24ee5ea5092f5ee2e994 bad (black screen, but heartbeat)
> >>>>
> >>>> 601527fea6bb226abd088a864e74b25368218e87 good
> >>>>
> >>>> 2165607ede34d229d0cbce916c70c7fb6c0337be good
> >>>>
> >>>> f094f388fc2df848227e2ae648df2c97872df42b good
> >>>>
> >>>> 020de18840a1075b2671736c6cc2e451030fad74 bad (black screen, but heartbeat)
> >>>>
> >>>> 4c4da3823e4d1a8189e96a59a79451fff372f70b good
> >>>>
> >>>> 020de18840a1075b2671736c6cc2e451030fad74 is the first bad commit
> >>>> commit 020de18840a1075b2671736c6cc2e451030fad74
> >>>> Author: Maxime Ripard <[email protected]>
> >>>> Date:?? Mon Jan 6 17:17:29 2020 +0100
> >>>>
> >>>> ??? drm/vc4: hdmi: rework connectors and encoders
> >>>> ???
> >>>> ??? the vc4_hdmi driver has some custom structures to hold the data it
> >>>> needs to
> >>>> ??? associate with the drm_encoder and drm_connector structures.
> >>>> ???
> >>>> ??? However, it allocates them separately from the vc4_hdmi structure which
> >>>> ??? makes it more complicated than it needs to be.
> >>>> ???
> >>>> ??? Move those structures to be contained by vc4_hdmi and update the code
> >>>> ??? accordingly.
> >>>> ???
> >>>> ??? Signed-off-by: Maxime Ripard <[email protected]>
> >>> So it looks like there was two issues on the Pi3. The first one was
> >>> causing the timeouts (and therefore likely the black screen but
> >>> heartbeat case you had) and I've fixed it.
> >>>
> >>> However, I can indeed reproduce the case with the black screen / no
> >>> heartbeat you mentionned. My bisection however returns that it's the
> >>> patch "drm/vc4: hdmi: Implement finer-grained hooks" that is at fault.
> >>> I've pushed my updated branch, if you have some spare time, it would be
> >>> great if you could confirm it on your Pi.
> >> yesterday i checked out your latest rpi4-kms branch, but i was still
> >> facing similiar issues with my Raspberry Pi 3 and multi_v7_defconfig
> >> (heartbeat stops, splashscreen freeze, heartbeat is abnormal fast). So i
> >> tried to bisect but the offending commit didn't cause an issue the
> >> second time.
> >>
> >> By accident i noticed that a simple reboot seems to hang for at least 8
> >> minutes (using b0523c7b1c9d0edcd the base of your branch). This usually
> >> take a few seconds. So i consider this base on linux-next as too
> >> unstable for reliable testing.
> >>
> >> Is it possible to rebase this on something more stable like linux-5.7 or
> >> at least drm-misc-next? This should avoid chasing unrelated issues.
> > I've rebased it on 5.7 here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms-5.7
> >
> > And it looks to be indeed an issue coming from next. That branch can
> > start the desktop just fine on an RPi3 here. It would be great if you
> > could confirm on your end.
> >
> > Thanks!
> > Maxime
>
> thank you very much. The good news are that the "black screen, but
> heartbeat" issue and reboot hang are gone. Unfortunately the "no
> heartbeat" issue is still there.
>
> Here are more details about the issue. It doesn't occur everytime. I
> would guess the probability is about 40 percent, which made bisecting
> much harder.

Are you sure about that 40% reliability? I found out that the culprit
was that the commit we mentionned was actually running atomic_disable
before our own custom callbacks, meaning that we would run the custom
callbacks with the clocks and the power domain shut down, resulting in a
stall.

I was seeing it all the time when X was shutting down the display, but
maybe you were changing the resolution between the framebuffer console
or something, and since the power domain is shut down asynchronously, it
wasn't running fast enough for the next enable to come up and re-enable
it again?

> It is reproducible on my 2 Raspberry Pi 3 B Rev 1.2. It is
> also seems independent from the display because the problem occured on
> my Computer display and my TV.

But only on HDMI, right?

I've pushed a new branch with that fix.

Maxime

Attachments:

(No filename) (4.75 kB)
signature.asc (235.00 B)
Download all attachments

2020-06-16 19:14:09

by Stefan Wahren

[permalink] [raw]

Subject: Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders

Hi Maxime,

Am 16.06.20 um 14:30 schrieb Maxime Ripard:
> On Sun, Jun 14, 2020 at 06:16:56PM +0200, Stefan Wahren wrote:
>> Am 11.06.20 um 15:34 schrieb Maxime Ripard:
>>> Hi Stefan,
>>>
>>> On Sat, Jun 06, 2020 at 10:06:12AM +0200, Stefan Wahren wrote:
>>>> Hi Maxime,
>>>>
>>>> Am 05.06.20 um 16:35 schrieb Maxime Ripard:
>>>>> Hi Stefan,
>>>>>
>>>>> On Wed, Jun 03, 2020 at 07:32:30PM +0200, Stefan Wahren wrote:
>>>>>> Am 02.06.20 um 17:54 schrieb Maxime Ripard:
>>>>>> FWIW this is the first patch which breaks X on my Raspberry Pi 3 B.
>>>>>>
>>>>>> Here are the bisect results:
>>>>>>
>>>>>> 587d6e4a529a8d807a5c0bae583dd432d77064d6 bad (black screen, no heartbeat)
>>>>>>
>>>>>> b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8 good
>>>>>>
>>>>>> 2c6a651cac6359cb0244a40d3b7a14e72918f169 good
>>>>>>
>>>>>> 1705c3cb40906863ec0d24ee5ea5092f5ee2e994 bad (black screen, but heartbeat)
>>>>>>
>>>>>> 601527fea6bb226abd088a864e74b25368218e87 good
>>>>>>
>>>>>> 2165607ede34d229d0cbce916c70c7fb6c0337be good
>>>>>>
>>>>>> f094f388fc2df848227e2ae648df2c97872df42b good
>>>>>>
>>>>>> 020de18840a1075b2671736c6cc2e451030fad74 bad (black screen, but heartbeat)
>>>>>>
>>>>>> 4c4da3823e4d1a8189e96a59a79451fff372f70b good
>>>>>>
>>>>>> 020de18840a1075b2671736c6cc2e451030fad74 is the first bad commit
>>>>>> commit 020de18840a1075b2671736c6cc2e451030fad74
>>>>>> Author: Maxime Ripard <[email protected]>
>>>>>> Date:?? Mon Jan 6 17:17:29 2020 +0100
>>>>>>
>>>>>> ??? drm/vc4: hdmi: rework connectors and encoders
>>>>>> ???
>>>>>> ??? the vc4_hdmi driver has some custom structures to hold the data it
>>>>>> needs to
>>>>>> ??? associate with the drm_encoder and drm_connector structures.
>>>>>> ???
>>>>>> ??? However, it allocates them separately from the vc4_hdmi structure which
>>>>>> ??? makes it more complicated than it needs to be.
>>>>>> ???
>>>>>> ??? Move those structures to be contained by vc4_hdmi and update the code
>>>>>> ??? accordingly.
>>>>>> ???
>>>>>> ??? Signed-off-by: Maxime Ripard <[email protected]>
>>>>> So it looks like there was two issues on the Pi3. The first one was
>>>>> causing the timeouts (and therefore likely the black screen but
>>>>> heartbeat case you had) and I've fixed it.
>>>>>
>>>>> However, I can indeed reproduce the case with the black screen / no
>>>>> heartbeat you mentionned. My bisection however returns that it's the
>>>>> patch "drm/vc4: hdmi: Implement finer-grained hooks" that is at fault.
>>>>> I've pushed my updated branch, if you have some spare time, it would be
>>>>> great if you could confirm it on your Pi.
>>>> yesterday i checked out your latest rpi4-kms branch, but i was still
>>>> facing similiar issues with my Raspberry Pi 3 and multi_v7_defconfig
>>>> (heartbeat stops, splashscreen freeze, heartbeat is abnormal fast). So i
>>>> tried to bisect but the offending commit didn't cause an issue the
>>>> second time.
>>>>
>>>> By accident i noticed that a simple reboot seems to hang for at least 8
>>>> minutes (using b0523c7b1c9d0edcd the base of your branch). This usually
>>>> take a few seconds. So i consider this base on linux-next as too
>>>> unstable for reliable testing.
>>>>
>>>> Is it possible to rebase this on something more stable like linux-5.7 or
>>>> at least drm-misc-next? This should avoid chasing unrelated issues.
>>> I've rebased it on 5.7 here:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms-5.7
>>>
>>> And it looks to be indeed an issue coming from next. That branch can
>>> start the desktop just fine on an RPi3 here. It would be great if you
>>> could confirm on your end.
>>>
>>> Thanks!
>>> Maxime
>> thank you very much. The good news are that the "black screen, but
>> heartbeat" issue and reboot hang are gone. Unfortunately the "no
>> heartbeat" issue is still there.
>>
>> Here are more details about the issue. It doesn't occur everytime. I
>> would guess the probability is about 40 percent, which made bisecting
>> much harder.
> Are you sure about that 40% reliability?
it's more a gut feeling than a statistical analyze. It's definitely not
100% in my setup.
> I found out that the culprit
> was that the commit we mentionned was actually running atomic_disable
> before our own custom callbacks, meaning that we would run the custom
> callbacks with the clocks and the power domain shut down, resulting in a
> stall.
>
> I was seeing it all the time when X was shutting down the display, but
> maybe you were changing the resolution between the framebuffer console
> or something, and since the power domain is shut down asynchronously, it
> wasn't running fast enough for the next enable to come up and re-enable
> it again?
>
>> It is reproducible on my 2 Raspberry Pi 3 B Rev 1.2. It is
>> also seems independent from the display because the problem occured on
>> my Computer display and my TV.
> But only on HDMI, right?
I only tested it with HDMI displays. All tests without any display were
always successful.
>
> I've pushed a new branch with that fix.

I tested 8 times in row without any issue. You got it.

Thanks
Stefan

>
> Maxime

2020-06-17 20:27:14

by Rob Herring

[permalink] [raw]

Subject: Re: [PATCH v3 006/105] dt-bindings: display: Convert VC4 bindings to schemas

On Wed, May 27, 2020 at 9:49 AM Maxime Ripard <[email protected]> wrote:
>
> The BCM283x SoCs have a display pipeline composed of several controllers
> with device tree bindings that are supported by Linux.
>
> Now that we have the DT validation in place, let's split into separate
> files and convert the device tree bindings for those controllers to
> schemas.
>
> This is just a 1:1 conversion though, and some bindings were incomplete so
> it results in example validation warnings that are going to be addressed in
> the following patches.
>
> Cc: Rob Herring <[email protected]>
> Cc: [email protected]
> Signed-off-by: Maxime Ripard <[email protected]>
> ---
> Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 174 +------------------------------------------------------------------------
> Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml | 66 +++++++++++++++++++++++++++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml | 73 ++++++++++++++++++++++++++++++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml | 75 +++++++++++++++++++++++++++++++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml | 37 +++++++++++++++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml | 40 +++++++++++++++++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml | 37 +++++++++++++++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml | 42 +++++++++++++++++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml | 34 ++++++++++++++-
> Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml | 44 ++++++++++++++++++-
> MAINTAINERS | 2 +-
> 11 files changed, 449 insertions(+), 175 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
> create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml

Not sure why my checks didn't catch this, but now linux-next has these warnings:

/builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.example.dt.yaml:
panel: compatible: Additional items are not allowed ('simple-panel'
was unexpected)
/builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.example.dt.yaml:
panel: compatible: ['ontat,yx700wv03', 'simple-panel'] is too long
/builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.example.dt.yaml:
panel: 'power-supply' is a required property