Re: [linux-sunxi] Help for 1-wire on Olimex's A64-OLinuXino-2Ge8G-IND: "pin already requested"

2023-10-30 Thread Maxime Ripard
On Mon, Oct 30, 2023 at 04:43:28PM +0100, Ilario Gelmetti wrote:
> So, the final DTS file looks like this:
> 
> ```
> /dts-v1/;
> /plugin/;
> 
> / {
>   compatible = "allwinner,sun50i-a64",
>  "olimex,a64-olinuxino";
>   description = "Enable 1-Wire port";
> 
>   fragment@0 {
>   target-path="/";
>   __overlay__ {
>   onewire {
>   compatible = "w1-gpio";
>   pinctrl-names = "default";
>   gpios = < 1 0 16>;
>   /* 1: B of PB0; 0: 0 of PB0;
>   16 = (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)
>   = (0 bitwise OR 16)
>   0 in the bit 0 means GPIO_ACTIVE_HIGH
>   1 in the bit 4 = 16 means GPIO_PULL_UP
>   0b1 = 16 */
>   status = "okay";
>   };
>   };
>   };
> };
> ```

A syntax probably more straightforward would be

/dts-v1/;
/plugin/;

#include 

&{/} {
onewire {
compatible = "w1-gpio";
gpios = < 1 0 GPIO_PULL_UP>;
status = "okay";
};
};

> It has been compiled with:
> 
> ```
> dtc -I dts -O dtb sun50i-a64-w1-gpio.dts -o sun50i-a64-w1-gpio.dtbo
> ```

And if you put that file under

> ```
> # cat /sys/kernel/debug/gpio
> gpiochip1: GPIOs 0-255, parent: platform/1c20800.pinctrl, 1c20800.pinctrl:
>  gpio-32  (|onewire ) out hi
>  gpio-166 (|cd  ) in  lo ACTIVE LOW
>  gpio-201 (|usb1-vbus   ) out hi
>  gpio-230 (|usb0_vbus_det   ) in  lo IRQ
>  gpio-233 (|usb0_id_det ) in  hi IRQ
> 
> gpiochip0: GPIOs 352-383, parent: platform/1f02c00.pinctrl, 1f02c00.pinctrl:
> 
> gpiochip2: GPIOs 510-511, parent: platform/axp20x-gpio, axp20x-gpio, can
> sleep:
> ```
> 
> It is surprising to me that it works even if the pin 32 (PB0 on Allwinner
> A64) is marked as output :)

The GPIO controller doesn't support simultaneous input and output and
1-wire needs to do both so it flips back and forth between input and
output.

> > > [] Driver for 1-wire Dallas network protocol.
> > > [] sun50i-a64-pinctrl 1c20800.pinctrl: pin PB0 already requested by
> > > onewire_device; cannot claim for 1c20800.pinctrl:32
> > > [] sun50i-a64-pinctrl 1c20800.pinctrl: pin-32 (1c20800.pinctrl:32)
> > > status -22
> > > [] w1-gpio onewire_device: gpio_request (pin) failed
> > > [] w1-gpio: probe of onewire_device failed with error -22
> > 
> > The problem is that the GPIO reference and the pinctrl reference for the
> > same pin conflict. In this case, the only thing you need the pinctrl
> > reference for is the pull-up, which you can achieve with a GPIO flag.
> > However, for the more general case, you may need to apply some other
> > pinconf setting to a GPIO pin, so we may need to fix this.
>
> For me, it is surprising how other people do not have my same issue.
> For example, in the instructions on the wiki [7], in the DTS from Armbian
> [8] and in the one used by RaspberryPi (on Broadcom) [9] they all use the
> same pin in two fragments. I tried using all of these and always got the
> "already requested by" error.

It also depends on the general design of the GPIO controller. Ours
doesn't support both GPIO and some other feature at the same time, they
are exclusive, some do.

The GPIO framework support both though, and by default will allow to
request a GPIO and another pin muxing at the same time. This was fixed
in 2017, so the wiki might be older than that and have never been
updated. armbian is probably in the same case.

The RaspberryPi driver might have a bug or a different design that
allows what we can't do.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/pio6en53vvtseg634zuafjjf4sbqdutctj7vunrgdjungpdzc2%40zsyhes5eedfa.


signature.asc
Description: PGP signature


[linux-sunxi] Re: sun4i CCU CCF vs CSI0 question (Re: [PATCH] doc sunxi: update CCU wiki page link in clocks.rst)

2023-02-07 Thread Maxime Ripard
On Sun, Feb 05, 2023 at 09:50:22PM +0200, Oleg Verych wrote:
> Hello!
> 
> On 1/17/23, Oleg Verych  wrote:
> > Update wiki page link to the Allwinner sunXi SoC Clock Control Module.
> >
> > Signed-off-by: Oleg Verych 
> > ---
> > Hi!
> >
> > Can I ask additional question to those in the file?
> 
> Q:
> > How is it possible to setup PLL7 to particular frequency and select
> > it as a source to CSI0 via CCM_CSI0_CLK[1]?
> 
> A:
> by setting clock source and frequency via CCF[2] in a camera device as:
> 
> ```
>   ov5640: camera@3c {
>   compatible = "ovti,ov5640";
>   reg = <0x3c>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_clk_pin>;
>   clocks = < CLK_CSI0>;
>   clock-names = "xclk";
> 
>   assigned-clocks = < CLK_CSI0>, < 17>; /* 17 = 
> CLK_PLL_VIDEO1 * /

You don't need the second clock.

>   assigned-clock-rates = <3200>;
>   assigned-clock-parents = < 17>;
> ...
>   port {
>   ov5640_to_csi0: endpoint {
> ...
> 
> ```
> [2] 
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/clock/clock.yaml

I'm not sure why you're trying to do that in the first place, but please
note that this isn't a guarantee in any way. It could change at any
point in time after probe has been called.

> Set of other related questions:
> 
> Q: When trying to setup main CSI0 clock to 32MHz from example above,
> it is not possible to get integer mode value:
> 
> sun4i_csi_probe mclk: 31578948 Hz
> 
> Why it is so, while PLL7 can be configured to (3*(9 + 23)) = 96 MHz
> which then can be divided by (2 + 1) using CCM_CSI0_CLK [1] /
> CSI0_CLK_REG [A20_User_Manual_v1.4_20150510.pdf p.84]?

I think what happens with your DT bits is that CLK_CSI0 and PLL_VIDEO1
will be set to 32MHz, in that order.

> Q: Initial value for CSI0 ISP clock is not as hardcoded in
> `sun4i_csi_runtime_resume()`. Is it correct to hardcode the value for
> resume? E.g.[3]:
> ```
>   clk_prepare_enable(csi->ram_clk);
> >>clk_set_rate(csi->isp_clk, 8000);
>   clk_prepare_enable(csi->isp_clk);
> ```
> [3] 
> https://elixir.bootlin.com/linux/v6.1/source/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c#L303

I guess? What's wrong with it?

> Q: Is there a good guide / how-to somewhere on how to suspend/resume
> A20-processor based devices, e.g. for `sun4i_csi_runtime_resume()`
> testing?

runtime PM is not related to suspend/resume. It will start and stop the
device whenever it's actually used instead of keeping it on all the
time.

If you start a capture and it works, then you've tested runtime PM

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20230207090648.ncmptkr7g36j5fkt%40houat.


Re: [linux-sunxi] A20 SOM EVB: NAND -> U-Boot -> SATA

2022-06-02 Thread Maxime Ripard


On Fri, May 27, 2022 at 10:08:16AM -0700, Oranż Metylowy wrote:
> Yes, it doesn't work, at least for me. I tried it a million times.

If you're using an A20, this is likely to be due to:
https://lore.kernel.org/u-boot/20210624120540.7oyhdmerjndsylbq@gilmour/

However, I must emphathize that using an MLC NAND is a terrible idea
with the current state of UBI and UBIFS, and really shouldn't be
encouraged.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20220602095728.6gjetzzv3f5en472%40penduick.


[linux-sunxi] Re: [PATCH v6 1/6] drm: sun4i: dsi: Drop DRM bind race with bridge attach

2022-02-04 Thread Maxime Ripard
On Mon, Jan 17, 2022 at 09:12:37PM +0530, Jagan Teki wrote:
> On Mon, Dec 13, 2021 at 10:32 PM Maxime Ripard  wrote:
> >
> > On Fri, Dec 10, 2021 at 04:47:06PM +0530, Jagan Teki wrote:
> > > Existing host driver will keep looking for DRM pointer in
> > > sun6i_dsi_attach and defers even if the particular DSI device
> > > is found for the first time. Meanwhile it triggers the bind
> > > callback and gets the DRM pointer and then continues the
> > > sun6i_dsi_attach.
> > >
> > > This makes a deadlock situation if sun6i_dsi_attach is trying
> > > to find the bridge.
> >
> > I'm not sure what you mean by deadlock here, there's no lock involved?
> 
> deadlock parse here for general understanding, where bind is trying to
> attach bridge but drm pointer is not available that point and drm
> pointer will available only when bind done. This is what I'm calling
> as deadlock here.

Have you read:
https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20220202085936.ogxhpl7u42lubhdd%40houat.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH RESEND v3] arm64: dts: allwinner: a64: olinuxino: Enable audio

2022-01-12 Thread Maxime Ripard
Hi,

On Tue, Jan 11, 2022 at 09:08:23PM +0100, Philip Rinn wrote:
> Enable the audio hardware on the Olimex A64-OLinuXino board family.
> Tested on the A64-OLinuXino-2Ge8G-IND variant.
> 
> Signed-off-by: Philip Rinn 
> 
> ---
> 
> 
> Changes in v2: added missing  {...} part
> Changes in v3: removed HDMI audio part as requested by Jernej Škrabec
> 
>  arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts| 30 
> +++
> 
>  1 file changed, 30 insertions(+)
> 
> 
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> 
> index ec7e2c0e82c1..6f2674bb1b7f 100644
> 
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> 
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts

Your mailer scrambled the patch completely, please use git send-email

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20220112084831.cwu6qcvxoygvfcyy%40houat.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v6 3/6] drm: sun4i: dsi: Add bridge support

2021-12-13 Thread Maxime Ripard
On Fri, Dec 10, 2021 at 04:47:08PM +0530, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output, those
> can have an option to connect the DSI host by means of interface
> bridge converter.
> 
> This DSI to non-DSI interface bridge converter would require
> DSI Host to handle drm bridge functionalities in order to
> communicate interface bridge.
> 
> This patch adds support for bridge functionalities in Allwinner
> DSI controller.
> 
> Supporting down-stream bridge makes few changes in the driver.
> 
> - It drops drm_connector and related operations as drm_bridge_attach
>   creates connector during attachment.
> 
> - It drop panel pointer and iterate the bridge, so-that it can operate
>   the normal bridge and panel_bridge in constitutive callbacks.
> 
> - It uses devm_drm_of_get_bridge for panel or bridge lookup. It uses
>   port 0 and endpoint 0 to support I2C-based bridges eventhough the
>   usual Allwinner DSI OF graph doesn't require this for panel and
>   non-I2C based downstream bridges.
> 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v6:
> - support donwstream bridge
> - drop bridge conversion
> - devm_drm_of_get_bridge() require child lookup
> https://patchwork.kernel.org/project/dri-devel/cover/20211207054747.461029-1-ja...@amarulasolutions.com/
> Changes for v5:
> - add atomic APIs
> - find host and device variant DSI devices.
> Changes for v4, v3:
> - none
> 
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 83 ++
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |  9 +--
>  2 files changed, 33 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 9cf91dcac3f2..f1d612bf1a0b 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -21,6 +21,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -720,6 +721,7 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   struct mipi_dsi_device *device = dsi->device;
>   union phy_configure_opts opts = { };
>   struct phy_configure_opts_mipi_dphy *cfg = _dphy;
> + struct drm_bridge *iter;
>   u16 delay;
>   int err;
>  
> @@ -769,8 +771,10 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   phy_configure(dsi->dphy, );
>   phy_power_on(dsi->dphy);
>  
> - if (dsi->panel)
> - drm_panel_prepare(dsi->panel);
> + list_for_each_entry(iter, >bridge_chain, chain_node) {
> + if (iter->funcs->pre_enable)
> + iter->funcs->pre_enable(iter);
> + }

Like we discussed in the previous version already, this is unnecessary,
just like the poking at bridge_chain in the encoder.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20211213171757.bxu57eaqawmp5kwh%40houat.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v6 2/6] drm: sun4i: dsi: Add component only once DSI device attached

2021-12-13 Thread Maxime Ripard
On Fri, Dec 10, 2021 at 04:47:07PM +0530, Jagan Teki wrote:
> Having component_add for running all drm bind callbacks returns
> error or unbound due to chain of DSI devices connected across
> bridge topology on a display pipeline.

I'm not sure what that means?

> In a typical bridge oriented display pipeline where the host is
> connected to the bridge converter and that indeed connected to
> a panel.
> 
> DRM => SUN6I DSI Host => Chipone ICN6211 => BananaPi Panel
> 
> The bridge converter is looking for a panel to probe first and
> then attach the host. The host attach is looking for a bridge
> converter to probe and preserve bridge pointer, at this movement

  ^ moment ?

> the host is trying to bind the all callbacks and one of the bind
> callback in the DSI host is trying to find the bridge using the
> bridge pointer in sun6i_dsi_attach call.
> 
> chipone_probe().start
> drm_of_find_panel_or_bridge
> mipi_dsi_attach
>  sun6i_dsi_attach
>  drm_of_find_panel_or_bridge
> chipone_probe().done
> 
> sun6i_dsi_probe().start
> mipi_dsi_host_register
> component_add
> sun6i_dsi_probe().done
> 
> However, the movement when panel defers the probe, will make the
> bridge converter defer the host attach call which eventually found
> a NULL bridge pointer during DSI component bind callback.
> 
> So, in order to prevent this scenario of binding invalid bridge,
> wait for DSI devices on the pipeline to probe first and start the
> binding process by moving component_add in host probe to attach call.
> 
> chipone_probe().start
> drm_of_find_panel_or_bridge
> mipi_dsi_attach
>  sun6i_dsi_attach
>  drm_of_find_panel_or_bridge
> component_add
> chipone_probe().done
> 
> sun6i_dsi_probe().start
> mipi_dsi_host_register
> sun6i_dsi_probe().done
> 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v6:
> - none
> Changes for v5:
> - new patch
> 
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 120 +
>  1 file changed, 61 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 4bdcce8f1d84..9cf91dcac3f2 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -959,11 +959,63 @@ static int sun6i_dsi_dcs_read(struct sun6i_dsi *dsi,
>   return 1;
>  }
>  
> +static int sun6i_dsi_bind(struct device *dev, struct device *master,
> +  void *data)
> +{
> + struct drm_device *drm = data;
> + struct sun6i_dsi *dsi = dev_get_drvdata(dev);
> + int ret;
> +
> + drm_encoder_helper_add(>encoder,
> +_dsi_enc_helper_funcs);
> + ret = drm_simple_encoder_init(drm, >encoder,
> +   DRM_MODE_ENCODER_DSI);
> + if (ret) {
> + dev_err(dsi->dev, "Couldn't initialise the DSI encoder\n");
> + return ret;
> + }
> + dsi->encoder.possible_crtcs = BIT(0);
> +
> + drm_connector_helper_add(>connector,
> +  _dsi_connector_helper_funcs);
> + ret = drm_connector_init(drm, >connector,
> +  _dsi_connector_funcs,
> +  DRM_MODE_CONNECTOR_DSI);
> + if (ret) {
> + dev_err(dsi->dev,
> + "Couldn't initialise the DSI connector\n");
> + goto err_cleanup_connector;
> + }
> +
> + drm_connector_attach_encoder(>connector, >encoder);
> +
> + return 0;
> +
> +err_cleanup_connector:
> + drm_encoder_cleanup(>encoder);
> + return ret;
> +}
> +
> +static void sun6i_dsi_unbind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct sun6i_dsi *dsi = dev_get_drvdata(dev);
> +
> + drm_encoder_cleanup(>encoder);
> +}
> +
> +static const struct component_ops sun6i_dsi_ops = {
> + .bind   = sun6i_dsi_bind,
> + .unbind = sun6i_dsi_unbind,
> +};

Just use a forward declaration there, it will make the patch more
straightforward.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20211213170515.2xzx52pedqcjqiyy%40houat.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v6 1/6] drm: sun4i: dsi: Drop DRM bind race with bridge attach

2021-12-13 Thread Maxime Ripard
On Fri, Dec 10, 2021 at 04:47:06PM +0530, Jagan Teki wrote:
> Existing host driver will keep looking for DRM pointer in
> sun6i_dsi_attach and defers even if the particular DSI device
> is found for the first time. Meanwhile it triggers the bind
> callback and gets the DRM pointer and then continues the
> sun6i_dsi_attach.
> 
> This makes a deadlock situation if sun6i_dsi_attach is trying
> to find the bridge.

I'm not sure what you mean by deadlock here, there's no lock involved?

> If interface bridge is trying to call host attach, then host
> sun6i_dsi_attach is trying to find bridge and defers the
> interface bridge even if it found the bridge as bind callback
> does not complete at the movement. So, this sun6i_dsi_attach
> defers interface bridge and triggers the bind callback and
> tries to attach the bridge with a bridge pointer which is not
> available at the moment.
>
> Eventually these callbacks are triggered recursively, as
> sun6i_dsi_attach defers interface bridge and bind callback
> defers sun6i_dsi_attach due to invalid bridge ponter.

^ pointer

> 
> This patch prevents this situation by probing all DSI devices
> on the pipeline first and then triggers the bind callback by
> dropping exing DRM binding logic.

   ^ existing I guess?

> 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v6:
> - none
> Changes for v5:
> - new patch
> 
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +-
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |  1 -
>  2 files changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 527c7b2474da..4bdcce8f1d84 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -967,14 +967,10 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
>  
>   if (IS_ERR(panel))
>   return PTR_ERR(panel);
> - if (!dsi->drm || !dsi->drm->registered)
> - return -EPROBE_DEFER;
>  
>   dsi->panel = panel;
>   dsi->device = device;
>  
> - drm_kms_helper_hotplug_event(dsi->drm);
> -
>   dev_info(host->dev, "Attached device %s\n", device->name);
>  
>   return 0;
> @@ -988,8 +984,6 @@ static int sun6i_dsi_detach(struct mipi_dsi_host *host,
>   dsi->panel = NULL;
>   dsi->device = NULL;
>  
> - drm_kms_helper_hotplug_event(dsi->drm);
> -
>   return 0;
>  }
>  
> @@ -1077,8 +1071,6 @@ static int sun6i_dsi_bind(struct device *dev, struct 
> device *master,
>  
>   drm_connector_attach_encoder(>connector, >encoder);
>  
> - dsi->drm = drm;
> -
>   return 0;
>  
>  err_cleanup_connector:
> @@ -1091,7 +1083,7 @@ static void sun6i_dsi_unbind(struct device *dev, struct 
> device *master,
>  {
>   struct sun6i_dsi *dsi = dev_get_drvdata(dev);
>  
> - dsi->drm = NULL;
> + drm_encoder_cleanup(>encoder);
>  }
>  
>  static const struct component_ops sun6i_dsi_ops = {
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> index c863900ae3b4..61e88ea6044d 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> @@ -29,7 +29,6 @@ struct sun6i_dsi {
>  
>   struct device   *dev;
>   struct mipi_dsi_device  *device;
> - struct drm_device   *drm;
>   struct drm_panel*panel;
>  };
>  
> -- 
> 2.25.1
> 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20211213170223.fx5656vjk3fwizbg%40houat.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v6 0/6] drm: sun4i: dsi: Bridge support

2021-12-13 Thread Maxime Ripard
Hi,

On Fri, Dec 10, 2021 at 04:47:05PM +0530, Jagan Teki wrote:
> This series add bridge support for Allwinner DSI controller.
> 
> In addition to previous version, this series add bridge support
> only not doing any bridge conversion at the moment.
> 
> Previous version changes [1].
> 
> Patch 1: Drop the DRM bind race while attaching bridges
> 
> Patch 2: Move component_add into sun6i_dsi_attach
> 
> Patch 3: Add Bridge driver
> 
> Patch 4: Add mode_set API
> 
> Patch 5: Enable DSI Panel
> 
> Patch 6: Enable DSI Bridge
> 
> Patch 7: Enable DSI Bridge (I2C)

It would be worth mentioning that we can't apply this patch until the
one for drm_of_find_panel_or_bridge has landed? Otherwise, we're going
to break every user so far.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20211213170049.wblzxs2y2xdzsgzh%40houat.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

2021-11-26 Thread Maxime Ripard
On Thu, Nov 25, 2021 at 09:44:14PM +0530, Jagan Teki wrote:
> On Thu, Nov 25, 2021 at 9:40 PM Maxime Ripard  wrote:
> >
> > On Thu, Nov 25, 2021 at 07:55:41PM +0530, Jagan Teki wrote:
> > > Hi,
> > >
> > > On Thu, Nov 25, 2021 at 7:45 PM Maxime Ripard  wrote:
> > > >
> > > > On Wed, Nov 24, 2021 at 12:02:47AM +0530, Jagan Teki wrote:
> > > > > > > > > > + dsi->panel = of_drm_find_panel(remote);
> > > > > > > > > > + if (IS_ERR(dsi->panel)) {
> > > > > > > > > > + dsi->panel = NULL;
> > > > > > > > > > +
> > > > > > > > > > + dsi->next_bridge = of_drm_find_bridge(remote);
> > > > > > > > > > + if (IS_ERR(dsi->next_bridge)) {
> > > > > > > > > > + dev_err(dsi->dev, "failed to find 
> > > > > > > > > > bridge\n");
> > > > > > > > > > + return PTR_ERR(dsi->next_bridge);
> > > > > > > > > > + }
> > > > > > > > > > + } else {
> > > > > > > > > > + dsi->next_bridge = NULL;
> > > > > > > > > > + }
> > > > > > > > > > +
> > > > > > > > > > + of_node_put(remote);
> > > > > > > > >
> > > > > > > > > Using devm_drm_of_get_bridge would greatly simplify the driver
> > > > > > > >
> > > > > > > > I'm aware of this and this would break the existing sunxi dsi 
> > > > > > > > binding,
> > > > > > > > we are not using ports based pipeline in dsi node. Of-course 
> > > > > > > > you have
> > > > > > > > pointed the same before, please check below
> > > > > > > > https://patchwork.kernel.org/project/dri-devel/patch/20210322140152.101709-2-ja...@amarulasolutions.com/
> > > > > > >
> > > > > > > Then drm_of_find_panel_or_bridge needs to be adjusted to handle 
> > > > > > > the DSI
> > > > > > > bindings and look for a panel or bridge not only through the OF 
> > > > > > > graph,
> > > > > > > but also on the child nodes
> > > > > >
> > > > > > Okay. I need to check this.
> > > > >
> > > > > devm_drm_of_get_bridge is not working with legacy binding like the one
> > > > > used in sun6i dsi
> > > >
> > > > There's nothing legacy about it.
> > >
> > > What I'm mean legacy here with current binding used in sun6i-dsi like 
> > > this.
> > >
> > >  {
> > >   vcc-dsi-supply = <_dcdc1>; /* VCC-DSI */
> > >   status = "okay";
> > >
> > >  panel@0 {
> > >compatible = "bananapi,s070wv20-ct16-icn6211";
> > >reg = <0>;
> > >reset-gpios = <_pio 0 5 GPIO_ACTIVE_HIGH>; /*
> > > LCD-RST: PL5 */
> > >   enable-gpios = < 1 7 GPIO_ACTIVE_HIGH>; /*
> > > LCD-PWR-EN: PB7 */
> > >   backlight = <>;
> > > };
> > > };
> >
> > Yes, I know, it's the generic DSI binding. It's still not legacy.
> >
> > > devm_drm_of_get_bridge cannot find the device with above binding and
> > > able to find the device with below binding.
> > >
> > >  {
> > >vcc-dsi-supply = <_dcdc1>; /* VCC-DSI */
> > >status = "okay";
> > >
> > >   ports {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > >dsi_out: port@0 {
> > >reg = <0>;
> > >
> > >   dsi_out_bridge: endpoint {
> > > remote-endpoint = <_out_dsi>;
> > >   };
> > >};
> > >   };
> > >
> > >   panel@0 {
> > >  compatible = "bananapi,s070wv20-ct16-icn6211";
> > >  reg = <0>;
> > >  reset-gp

[linux-sunxi] Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

2021-11-25 Thread Maxime Ripard
On Thu, Nov 25, 2021 at 07:55:41PM +0530, Jagan Teki wrote:
> Hi,
> 
> On Thu, Nov 25, 2021 at 7:45 PM Maxime Ripard  wrote:
> >
> > On Wed, Nov 24, 2021 at 12:02:47AM +0530, Jagan Teki wrote:
> > > > > > > > + dsi->panel = of_drm_find_panel(remote);
> > > > > > > > + if (IS_ERR(dsi->panel)) {
> > > > > > > > + dsi->panel = NULL;
> > > > > > > > +
> > > > > > > > + dsi->next_bridge = of_drm_find_bridge(remote);
> > > > > > > > + if (IS_ERR(dsi->next_bridge)) {
> > > > > > > > + dev_err(dsi->dev, "failed to find 
> > > > > > > > bridge\n");
> > > > > > > > + return PTR_ERR(dsi->next_bridge);
> > > > > > > > + }
> > > > > > > > + } else {
> > > > > > > > + dsi->next_bridge = NULL;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + of_node_put(remote);
> > > > > > >
> > > > > > > Using devm_drm_of_get_bridge would greatly simplify the driver
> > > > > >
> > > > > > I'm aware of this and this would break the existing sunxi dsi 
> > > > > > binding,
> > > > > > we are not using ports based pipeline in dsi node. Of-course you 
> > > > > > have
> > > > > > pointed the same before, please check below
> > > > > > https://patchwork.kernel.org/project/dri-devel/patch/20210322140152.101709-2-ja...@amarulasolutions.com/
> > > > >
> > > > > Then drm_of_find_panel_or_bridge needs to be adjusted to handle the 
> > > > > DSI
> > > > > bindings and look for a panel or bridge not only through the OF graph,
> > > > > but also on the child nodes
> > > >
> > > > Okay. I need to check this.
> > >
> > > devm_drm_of_get_bridge is not working with legacy binding like the one
> > > used in sun6i dsi
> >
> > There's nothing legacy about it.
> 
> What I'm mean legacy here with current binding used in sun6i-dsi like this.
> 
>  {
>   vcc-dsi-supply = <_dcdc1>; /* VCC-DSI */
>   status = "okay";
> 
>  panel@0 {
>compatible = "bananapi,s070wv20-ct16-icn6211";
>reg = <0>;
>reset-gpios = <_pio 0 5 GPIO_ACTIVE_HIGH>; /*
> LCD-RST: PL5 */
>   enable-gpios = < 1 7 GPIO_ACTIVE_HIGH>; /*
> LCD-PWR-EN: PB7 */
>   backlight = <>;
> };
> };

Yes, I know, it's the generic DSI binding. It's still not legacy.

> devm_drm_of_get_bridge cannot find the device with above binding and
> able to find the device with below binding.
> 
>  {
>vcc-dsi-supply = <_dcdc1>; /* VCC-DSI */
>status = "okay";
> 
>   ports {
> #address-cells = <1>;
> #size-cells = <0>;
> 
>dsi_out: port@0 {
>reg = <0>;
> 
>   dsi_out_bridge: endpoint {
> remote-endpoint = <_out_dsi>;
>   };
>};
>   };
> 
>   panel@0 {
>  compatible = "bananapi,s070wv20-ct16-icn6211";
>  reg = <0>;
>  reset-gpios = <_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
>  enable-gpios = < 1 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PB7 */
>  backlight = <>;
> 
>   port {
> bridge_out_dsi: endpoint {
> remote-endpoint = <_out_bridge>;
> };
> };
>};
> };

Yes, I know, and that's because ...

> >
> > > https://patchwork.kernel.org/project/dri-devel/patch/20211122065223.88059-6-ja...@amarulasolutions.com/
> > >
> > > dsi->next_bridge = devm_drm_of_get_bridge(dsi->dev, dsi->dev->of_node, 0, 
> > > 0);
> > > if (IS_ERR(dsi->next_bridge))
> > >return PTR_ERR(dsi->next_bridge);
> > >
> > > It is only working if we have ports on the pipeline, something like this
> > > https://patchwork.kernel.org/project/dri-devel/patch/20210214194102.126146-8-ja...@amarulasolutions.com/
> > >
> > > Please have a look and let me know if I miss anything?
> >
> > Yes, you're missing the answer you quoted earlier:
> 
> Yes, I'm trying to resolve the comment one after another. Will get back.

... You've ignored that comment.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20211125161026.ndfygaa6c4nnst4i%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

2021-11-25 Thread Maxime Ripard
On Wed, Nov 24, 2021 at 12:02:47AM +0530, Jagan Teki wrote:
> > > > > > + dsi->panel = of_drm_find_panel(remote);
> > > > > > + if (IS_ERR(dsi->panel)) {
> > > > > > + dsi->panel = NULL;
> > > > > > +
> > > > > > + dsi->next_bridge = of_drm_find_bridge(remote);
> > > > > > + if (IS_ERR(dsi->next_bridge)) {
> > > > > > + dev_err(dsi->dev, "failed to find bridge\n");
> > > > > > + return PTR_ERR(dsi->next_bridge);
> > > > > > + }
> > > > > > + } else {
> > > > > > + dsi->next_bridge = NULL;
> > > > > > + }
> > > > > > +
> > > > > > + of_node_put(remote);
> > > > >
> > > > > Using devm_drm_of_get_bridge would greatly simplify the driver
> > > >
> > > > I'm aware of this and this would break the existing sunxi dsi binding,
> > > > we are not using ports based pipeline in dsi node. Of-course you have
> > > > pointed the same before, please check below
> > > > https://patchwork.kernel.org/project/dri-devel/patch/20210322140152.101709-2-ja...@amarulasolutions.com/
> > >
> > > Then drm_of_find_panel_or_bridge needs to be adjusted to handle the DSI
> > > bindings and look for a panel or bridge not only through the OF graph,
> > > but also on the child nodes
> >
> > Okay. I need to check this.
> 
> devm_drm_of_get_bridge is not working with legacy binding like the one
> used in sun6i dsi

There's nothing legacy about it.

> https://patchwork.kernel.org/project/dri-devel/patch/20211122065223.88059-6-ja...@amarulasolutions.com/
> 
> dsi->next_bridge = devm_drm_of_get_bridge(dsi->dev, dsi->dev->of_node, 0, 0);
> if (IS_ERR(dsi->next_bridge))
>return PTR_ERR(dsi->next_bridge);
> 
> It is only working if we have ports on the pipeline, something like this
> https://patchwork.kernel.org/project/dri-devel/patch/20210214194102.126146-8-ja...@amarulasolutions.com/
> 
> Please have a look and let me know if I miss anything?

Yes, you're missing the answer you quoted earlier:

> > > Then drm_of_find_panel_or_bridge needs to be adjusted to handle the DSI
> > > bindings and look for a panel or bridge not only through the OF graph,
> > > but also on the child nodes

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20211125141516.oymscgs3xcjqmgce%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

2021-11-22 Thread Maxime Ripard
On Mon, Nov 22, 2021 at 08:01:47PM +0530, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 7:39 PM Maxime Ripard  wrote:
> >
> > On Mon, Nov 22, 2021 at 07:21:57PM +0530, Jagan Teki wrote:
> > > > It's perfectly valid to dereference the pointer in atomic_enable, and
> > > > that patch would consume memory for no particular reason.
> > >
> > > Again, I'm not pointing any mistake in dereference and certainly not
> > > understand about what memory consumption issue here.
> >
> > You add a struct drm_display_mode field to struct sun6i_dsi. It
> > increases the size of struct sun6i_dsi of sizeof(struct
> > drm_display_mode).
> >
> > > I'm doing it here since I'm doing it via mode_set in other drivers. No
> > > problem for me either way.
> >
> > But *why* are you doing so?
> >
> > There might be a valid reason in other drivers, but there's none here
> > (that you mentioned at least).
> 
> The reason is to use existing bridge function instead of dereference
> ie what I've mentioned. I don't have any other reasons.

This discussion is going in circles. Unless you have a reason other than
"because we can", NAK for the reasons already stated above.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20211122150610.mvltgil3yquli4qp%40gilmour.


[linux-sunxi] Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

2021-11-22 Thread Maxime Ripard
On Mon, Nov 22, 2021 at 07:49:26PM +0530, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 7:35 PM Maxime Ripard  wrote:
> > On Mon, Nov 22, 2021 at 07:18:13PM +0530, Jagan Teki wrote:
> > > On Mon, Nov 22, 2021 at 3:37 PM Maxime Ripard  wrote:
> > > >
> > > > On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> > > > > Some display panels would come up with a non-DSI output, those
> > > > > can have an option to connect the DSI host by means of interface
> > > > > bridge converter.
> > > > >
> > > > > This DSI to non-DSI interface bridge converter would requires
> > > > > DSI Host to handle drm bridge functionalities in order to DSI
> > > > > Host to Interface bridge.
> > > >
> > > > In order to do this you would need to use the DRM bridge API...
> > >
> > > Sorry, which bridge API do you mean?
> >
> > Any variant of of_drm_find_bridge, and drm_bridge_attach. Just like
> > we're doing in sun4i_rgb.c
> 
> Yes, we have drm_bridge_attach in bind and bridge_function.attach
> calls in this patch and of_drm_find_bridge in sun6i_mipi_dsi_attach.
> Not sure which API's I've missed.

None, that's my point, you don't need anything else in order to do what
you wanted to achieve.

> >
> > > > > This patch convert the existing to a drm bridge driver with a
> > > > > built-in encoder support for compatibility with existing
> > > > > component drivers.
> > > >
> > > > ... but changing the encoder driver to a bridge is completely
> > > > unnecessary to do so. Why did you need to make that change?
> > >
> > > Idea of this series is to convert the driver to bridge and use the
> > > latest bridge function from the v1 series.
> >
> > Ok, but it's not at all what you mention in your commit log? You don't
> > need any of that in order to support a bridge downstream.
> 
> I've mentioned "Converting to bridge driver" and thought it has
> meaning of converting encoder related function to bridge functions as
> well. Not think about specific description to describe on commit
> message. Will update this.

But you provided no reason to do so. The only one you did mention was
that you wanted to support downstream bridges, but you don't need to
convert the DSI driver to a bridge in order to do that.

> > > > > Signed-off-by: Jagan Teki 
> > > > >
> > > > > ---
> > > > > Changes for v5:
> > > > > - add atomic APIs
> > > > > - find host and device variant DSI devices.
> > > > > Changes for v4, v3:
> > > > > - none
> > > > >
> > > > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 
> > > > > -
> > > > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
> > > > >  2 files changed, 96 insertions(+), 23 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > > index 43d9c9e5198d..a6a272b55f77 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > > @@ -21,6 +21,7 @@
> > > > >
> > > > >  #include 
> > > > >  #include 
> > > > > +#include 
> > > > >  #include 
> > > > >  #include 
> > > > >  #include 
> > > > > @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi 
> > > > > *dsi,
> > > > >   return 0;
> > > > >  }
> > > > >
> > > > > -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> > > > > +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> > > > > +struct drm_bridge_state 
> > > > > *old_bridge_state)
> > > > >  {
> > > > > - struct drm_display_mode *mode = 
> > > > > >crtc->state->adjusted_mode;
> > > > > - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > > > > + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> > > > > + struct drm_display_mode *mode = 
> > > > > >encoder->crtc->state->adjusted_mode;
> > > > >   struct mipi_dsi_device *device = dsi->device;
> > > > > 

[linux-sunxi] Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

2021-11-22 Thread Maxime Ripard
On Mon, Nov 22, 2021 at 07:21:57PM +0530, Jagan Teki wrote:
> > It's perfectly valid to dereference the pointer in atomic_enable, and
> > that patch would consume memory for no particular reason.
> 
> Again, I'm not pointing any mistake in dereference and certainly not
> understand about what memory consumption issue here.

You add a struct drm_display_mode field to struct sun6i_dsi. It
increases the size of struct sun6i_dsi of sizeof(struct
drm_display_mode).

> I'm doing it here since I'm doing it via mode_set in other drivers. No
> problem for me either way.

But *why* are you doing so?

There might be a valid reason in other drivers, but there's none here
(that you mentioned at least).

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20211122140929.22cmvnxxapp752ic%40gilmour.


[linux-sunxi] Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

2021-11-22 Thread Maxime Ripard
On Mon, Nov 22, 2021 at 07:18:13PM +0530, Jagan Teki wrote:
> Hi Maxime,
> 
> On Mon, Nov 22, 2021 at 3:37 PM Maxime Ripard  wrote:
> >
> > On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> > > Some display panels would come up with a non-DSI output, those
> > > can have an option to connect the DSI host by means of interface
> > > bridge converter.
> > >
> > > This DSI to non-DSI interface bridge converter would requires
> > > DSI Host to handle drm bridge functionalities in order to DSI
> > > Host to Interface bridge.
> >
> > In order to do this you would need to use the DRM bridge API...
> 
> Sorry, which bridge API do you mean?

Any variant of of_drm_find_bridge, and drm_bridge_attach. Just like
we're doing in sun4i_rgb.c

> > > This patch convert the existing to a drm bridge driver with a
> > > built-in encoder support for compatibility with existing
> > > component drivers.
> >
> > ... but changing the encoder driver to a bridge is completely
> > unnecessary to do so. Why did you need to make that change?
> 
> Idea of this series is to convert the driver to bridge and use the
> latest bridge function from the v1 series.

Ok, but it's not at all what you mention in your commit log? You don't
need any of that in order to support a bridge downstream.

> >
> > > Signed-off-by: Jagan Teki 
> > >
> > > ---
> > > Changes for v5:
> > > - add atomic APIs
> > > - find host and device variant DSI devices.
> > > Changes for v4, v3:
> > > - none
> > >
> > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
> > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
> > >  2 files changed, 96 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > index 43d9c9e5198d..a6a272b55f77 100644
> > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > @@ -21,6 +21,7 @@
> > >
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
> > >   return 0;
> > >  }
> > >
> > > -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> > > +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> > > +struct drm_bridge_state 
> > > *old_bridge_state)
> > >  {
> > > - struct drm_display_mode *mode = 
> > > >crtc->state->adjusted_mode;
> > > - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> > > + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> > > + struct drm_display_mode *mode = 
> > > >encoder->crtc->state->adjusted_mode;
> > >   struct mipi_dsi_device *device = dsi->device;
> > >   union phy_configure_opts opts = { };
> > >   struct phy_configure_opts_mipi_dphy *cfg = _dphy;
> > > @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct 
> > > drm_encoder *encoder)
> > >   if (dsi->panel)
> > >   drm_panel_prepare(dsi->panel);
> > >
> > > + if (dsi->next_bridge)
> > > + 
> > > dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> > > old_bridge_state);
> > > +
> >
> > Please use the proper helpers.
> 
> If we use bridge_functions we need to take atomic functions as
> precedence as the next bridge functions might convert atomic calls.

We've had this discussion over and over again, but this is something
that needs to be documented and / or in your commit log.

You must not deviate from the standard (and expected) behavior without
any kind of justification.

> >
> > >   /*
> > >* FIXME: This should be moved after the switch to HS mode.
> > >*
> > > @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct 
> > > drm_encoder *encoder)
> > >   if (dsi->panel)
> > >   drm_panel_enable(dsi->panel);
> > >
> > > + if (dsi->next_bridge)
> > > + dsi->next_bridge->funcs->atomic_enable(dsi->next_bridge, 
> > > old_bridge_state);
> > > +
> >
> > Ditto
> >
> > &

[linux-sunxi] Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

2021-11-22 Thread Maxime Ripard
On Mon, Nov 22, 2021 at 06:35:58PM +0530, Jagan Teki wrote:
> On Mon, Nov 22, 2021 at 3:38 PM Maxime Ripard  wrote:
> >
> > On Mon, Nov 22, 2021 at 12:22:20PM +0530, Jagan Teki wrote:
> > > Get the display mode settings via mode_set bridge function
> > > instead of explicitly de-reference.
> >
> > What's wrong with dereferencing the mode?
> 
> Nothing wrong with dereferencing, however we have built-in API to that job.

That's not an API though?

It's perfectly valid to dereference the pointer in atomic_enable, and
that patch would consume memory for no particular reason.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20211122132847.ds4gtk2unq3fkagy%40gilmour.


[linux-sunxi] Re: [PATCH v5 4/7] drm: sun4i: dsi: Add mode_set function

2021-11-22 Thread Maxime Ripard
On Mon, Nov 22, 2021 at 12:22:20PM +0530, Jagan Teki wrote:
> Get the display mode settings via mode_set bridge function
> instead of explicitly de-reference.

What's wrong with dereferencing the mode?

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20211122100759.qw6lvwb33ciemg2y%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver

2021-11-22 Thread Maxime Ripard
On Mon, Nov 22, 2021 at 12:22:19PM +0530, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output, those
> can have an option to connect the DSI host by means of interface
> bridge converter.
> 
> This DSI to non-DSI interface bridge converter would requires
> DSI Host to handle drm bridge functionalities in order to DSI
> Host to Interface bridge.

In order to do this you would need to use the DRM bridge API...

> This patch convert the existing to a drm bridge driver with a
> built-in encoder support for compatibility with existing
> component drivers.

... but changing the encoder driver to a bridge is completely
unnecessary to do so. Why did you need to make that change?

> Signed-off-by: Jagan Teki 
>
> ---
> Changes for v5:
> - add atomic APIs
> - find host and device variant DSI devices.
> Changes for v4, v3:
> - none
> 
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 112 -
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |   7 ++
>  2 files changed, 96 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 43d9c9e5198d..a6a272b55f77 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -21,6 +21,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -713,10 +714,11 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
>   return 0;
>  }
>  
> -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> +static void sun6i_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
> +struct drm_bridge_state 
> *old_bridge_state)
>  {
> - struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> + struct drm_display_mode *mode = 
> >encoder->crtc->state->adjusted_mode;
>   struct mipi_dsi_device *device = dsi->device;
>   union phy_configure_opts opts = { };
>   struct phy_configure_opts_mipi_dphy *cfg = _dphy;
> @@ -772,6 +774,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   if (dsi->panel)
>   drm_panel_prepare(dsi->panel);
>  
> + if (dsi->next_bridge)
> + dsi->next_bridge->funcs->atomic_pre_enable(dsi->next_bridge, 
> old_bridge_state);
> +

Please use the proper helpers.

>   /*
>* FIXME: This should be moved after the switch to HS mode.
>*
> @@ -787,6 +792,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   if (dsi->panel)
>   drm_panel_enable(dsi->panel);
>  
> + if (dsi->next_bridge)
> + dsi->next_bridge->funcs->atomic_enable(dsi->next_bridge, 
> old_bridge_state);
> +

Ditto

>   sun6i_dsi_start(dsi, DSI_START_HSC);
>  
>   udelay(1000);
> @@ -794,15 +802,19 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   sun6i_dsi_start(dsi, DSI_START_HSD);
>  }
>  
> -static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
> +static void sun6i_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
> + struct drm_bridge_state 
> *old_bridge_state)
>  {
> - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
>  
>   DRM_DEBUG_DRIVER("Disabling DSI output\n");
>  
>   if (dsi->panel) {
>   drm_panel_disable(dsi->panel);
>   drm_panel_unprepare(dsi->panel);
> + } else if (dsi->next_bridge) {
> + dsi->next_bridge->funcs->atomic_disable(dsi->next_bridge, 
> old_bridge_state);
> + dsi->next_bridge->funcs->atomic_post_disable(dsi->next_bridge, 
> old_bridge_state);

Ditto

>   }
>  
>   phy_power_off(dsi->dphy);
> @@ -842,9 +854,25 @@ static const struct drm_connector_funcs 
> sun6i_dsi_connector_funcs = {
>   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
>  };
>  
> -static const struct drm_encoder_helper_funcs sun6i_dsi_enc_helper_funcs = {
> - .disable= sun6i_dsi_encoder_disable,
> - .enable = sun6i_dsi_encoder_enable,
> +static int sun6i_dsi_bridge_attach(struct drm_bridge *bridge,
> +enum drm_bridge_attach_flags flags)
> +{
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> +
> + if (dsi->next_bridge)
> + return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
> +  NULL, 0);
> +
> + return 0;
> +}
> +
> +static const struct drm_bridge_funcs sun6i_dsi_bridge_funcs = {
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state   = drm_atomic_helper_bridge_destroy_state,
> + .atomic_reset   = drm_atomic_helper_bridge_reset,
> + .atomic_enable

[linux-sunxi] Re: (subset) [PATCH v2 25/52] dt-bindings: interconnect: sunxi: Add R40 MBUS compatible

2021-10-15 Thread Maxime Ripard
On Wed, 1 Sep 2021 11:18:25 +0200, Maxime Ripard wrote:
> The R40 MBUS compatible was introduced recently but it was never
> documented.
> 
> 

Applied to sunxi/linux.git (sunxi/dt-for-5.16).

Thanks!
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/163428528489.12562.8542930736846466237.b4-ty%40cerno.tech.


[linux-sunxi] Re: [PATCH v2 29/52] dt-bindings: mfd: Convert X-Powers AXP binding to a schema

2021-09-14 Thread Maxime Ripard
On Mon, Sep 06, 2021 at 10:02:26AM +0100, Lee Jones wrote:
> On Fri, 03 Sep 2021, Rob Herring wrote:
> 
> > On Wed, 01 Sep 2021 11:18:29 +0200, Maxime Ripard wrote:
> > > The X-Powers AXP PMICs are supported by Linux thanks to its device tree
> > > binding.
> > > 
> > > Now that we have the DT validation in place, let's convert the device
> > > tree bindings for that driver over to a YAML schema.
> > > 
> > > Cc: Chen-Yu Tsai 
> > > Cc: Lee Jones 
> > > Signed-off-by: Maxime Ripard 
> > > 
> > > ---
> > > 
> > > Changes from v1:
> > >   - Add GPIO example
> > >   - Remove the limitation on regulator-ramp-delay
> > > ---
> > >  .../i2c/allwinner,sun6i-a31-p2wi.yaml |   2 +-
> > >  .../devicetree/bindings/mfd/axp20x.txt| 273 
> > >  .../bindings/mfd/x-powers,axp152.yaml | 400 ++
> > >  3 files changed, 401 insertions(+), 274 deletions(-)
> > >  delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
> > > 
> > 
> > Reviewed-by: Rob Herring 
> > 
> > Note that the gpio child schema needs to be applied with this one.
> 
> Not sure I'm in possession of that.

So, how do you want to merge that? Through the DT tree?

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210914071208.7xalrr2qskzdncgs%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 52/52] arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:24:48PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:52 CEST je Maxime Ripard napisal(a):
> > Neither the binding nor the driver make any use of the wakeup-source
> > property for the AXP803. Remove it.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906134143.4cp3pwg7g5exjiun%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 51/52] arm64: dts: allwinner: teres-i: Add missing reg

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:14:34PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:51 CEST je Maxime Ripard napisal(a):
> > The anx6345 bridge mandates that the input port is named port@0. Since
> > we have a unit-address, this implies that we need a reg property with
> > the same value, but it was found to be missing in the Teres-I device
> > tree. Make sure it's there.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906134124.mery3wv5lwkafz56%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 50/52] arm64: dts: allwinner: pinetab: Change regulator node name to avoid warning

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:14:08PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:50 CEST je Maxime Ripard napisal(a):
> > The fixed regulator clock name has a unit address, but no reg property,
> > which generates a warning in DTC. Change its name to remove its useless
> > unit address.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906134108.c6n5bxivuzwjrp7l%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 49/52] arm64: dts: allwinner: a100: Fix thermal zone node name

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:13:46PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:49 CEST je Maxime Ripard napisal(a):
> > The thermal zones one the A100 are called $device-thermal-zone.
> > 
> > However, the thermal zone binding explicitly requires that zones are
> > called *-thermal. Let's fix it.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906134047.ua4qyiahml4ij7av%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 48/52] arm64: dts: allwinner: h6: Fix de3 parent clocks ordering

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:13:25PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:48 CEST je Maxime Ripard napisal(a):
> > While it doesn't really matter from a functional point of view in this
> > driver's case, it's usually a good practice to list the clocks in a
> > driver in the same driver across all its users.
> > 
> > The H6 is using the inverse order than all the other users, so let's
> > make it consistent.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906134019.mzm5pz7cika37npg%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 46/52] ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:12:27PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:46 CEST je Maxime Ripard napisal(a):
> > The dumb-vga-dac and adi,adv7123 compatibles are not supposed to be used
> > together according to the binding.
> > 
> > Since the corpro gm7123 is a drop-in replacement for the adv7123, let's
> > remove dumb-vga-dac from our compatible list.
> > 
> > Reviewed-by: Chen-Yu Tsai 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906133920.py5hzrahylqzo6lb%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 45/52] ARM: dts: tbs711: Fix touchscreen compatible

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:11:58PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:45 CEST je Maxime Ripard napisal(a):
> > The edt,edt-ft5x06 compatible has never been a valid compatible
> > according to the binding. Let's change for one that is.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906133858.rxf226hoiqwmm27a%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 43/52] ARM: dts: sunxi: Fix the SPI NOR node names

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:06:45PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:43 CEST je Maxime Ripard napisal(a):
> > According to the SPI NOR bindings, the flash node names are supposed to
> > be flash@. Let's fix our users to use that new scheme.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906133828.vtxjm2ltk4e5frne%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 42/52] ARM: dts: sunxi: Fix OPPs node name

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:05:58PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:42 CEST je Maxime Ripard napisal(a):
> > The operating-points-v2 nodes are named inconsistently, but mostly
> > either opp_table0 or gpu-opp-table.  However, the underscore is an
> > invalid character for a node name and the thermal zone binding
> > explicitly requires that zones are called opp-table-*. Let's fix it.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906133801.ao2jqa7q7v27ygvt%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 41/52] ARM: dts: sunxi: Fix OPP arrays

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:04:59PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:41 CEST je Maxime Ripard napisal(a):
> > Even though it translates to the same thing down to the binary level, we
> > should have an array of 2 number cells to describe each OPP, which in
> > turns create a validation warning.
> > 
> > Let's fix this.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906133734.eonud3qgzgpmhc24%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 40/52] ARM: dts: sunxi: Rename gpio pinctrl names

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:03:11PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:40 CEST je Maxime Ripard napisal(a):
> > We've had a pinctrl node name convention for a while now, let's follow
> > it for the AXP pinctrl nodes as well.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906133711.hiylg4kijnai6eln%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 39/52] ARM: dts: sunxi: Rename power-supply names

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:02:44PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:39 CEST je Maxime Ripard napisal(a):
> > The name of our PMIC power supply names conflict with the generic
> > regulator supply check that matches anything called *-supply, including
> > the nodes, and then makes sure it's a phandle.
> > 
> > A node is obviously not a phandle, so let's change our power supplies
> > names to avoid any conflict.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Acked-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906133648.n2uz6tp34n74xexu%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 35/52] dt-bindings: sunxi: Add Allwinner A80 PRCM Binding

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:01:17PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:35 CEST je Maxime Ripard napisal(a):
> > Even though we've used the A80 PRCM driver for some time and a number of
> > boards using it already, we never had a binding for it. Let's add it
> > based on what the driver expects and the boards are providing.
> > 
> > Reviewed-by: Rob Herring 
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906133613.3ougu5t5b5norqe2%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 34/52] dt-bindings: sunxi: Add CPU Configuration Controller Binding

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 11:00:25PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:34 CEST je Maxime Ripard napisal(a):
> > Even though we've used the CPU configuration driver for some time and a
> > number of boards using it already, we never had a binding for it. Let's
> > add it based on what the driver expects and the boards are providing.
> > 
> > Reviewed-by: Rob Herring 
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906133552.c6gdtvu633elgcpd%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 09/52] dt-bindings: clocks: Fix typo in the H6 compatible

2021-09-06 Thread Maxime Ripard
On Sun, Sep 05, 2021 at 10:50:32PM +0200, Jernej Škrabec wrote:
> Dne sreda, 01. september 2021 ob 11:18:09 CEST je Maxime Ripard napisal(a):
> > Even though both the driver and the device trees all use the
> > allwinner,sun50i-h6-de3-clk, we documented the compatible as
> > allwinner,sun50i-h6-de2-clk in the binding. Let's fix this.
> > 
> > Reviewed-by: Rob Herring 
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Jernej Skrabec 

Applied, thanks
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210906133440.q3x25ally4rfnbjv%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding

2021-09-03 Thread Maxime Ripard
Hi Mark,

On Wed, Sep 01, 2021 at 03:39:50PM +0100, Mark Brown wrote:
> On Wed, Sep 01, 2021 at 11:18:01AM +0200, Maxime Ripard wrote:
> > Even though we had the wm8978 driver for some time and a number of
> > boards using it already, we never had a binding for it. Let's add it
> > based on what the driver expects and the boards are providing.
> 
> What's the story with dependencies here?  I don't have a cover letter or
> anything and there seem to be a bunch of tangentially related patches in
> a series here.

There's no dependency, you can pick the ASoC patches safely

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210903103706.jhyn4ancyfr6bjcy%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] [PATCH v2 52/52] arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC

2021-09-01 Thread Maxime Ripard
Neither the binding nor the driver make any use of the wakeup-source
property for the AXP803. Remove it.

Signed-off-by: Maxime Ripard 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
index 52e032f7fb68..aef571acd67f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -208,7 +208,6 @@ axp803: pmic@3a3 {
reg = <0x3a3>;
interrupt-parent = <_intc>;
interrupts = ;
-   wakeup-source;
};
 };
 
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-53-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 51/52] arm64: dts: allwinner: teres-i: Add missing reg

2021-09-01 Thread Maxime Ripard
The anx6345 bridge mandates that the input port is named port@0. Since
we have a unit-address, this implies that we need a reg property with
the same value, but it was found to be missing in the Teres-I device
tree. Make sure it's there.

Signed-off-by: Maxime Ripard 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
index 45e1abdf70a0..52e032f7fb68 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -139,6 +139,8 @@ ports {
#size-cells = <0>;
 
port@0 {
+   reg = <0>;
+
anx6345_in: endpoint {
remote-endpoint = <_out_anx6345>;
};
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-52-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 50/52] arm64: dts: allwinner: pinetab: Change regulator node name to avoid warning

2021-09-01 Thread Maxime Ripard
The fixed regulator clock name has a unit address, but no reg property,
which generates a warning in DTC. Change its name to remove its useless
unit address.

Signed-off-by: Maxime Ripard 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index 7ef96f9ff7ae..6a4af14718f5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -77,7 +77,7 @@ speaker_amp: audio-amplifier {
sound-name-prefix = "Speaker Amp";
};
 
-   vdd_bl: regulator@0 {
+   vdd_bl: regulator {
compatible = "regulator-fixed";
regulator-name = "bl-3v3";
regulator-min-microvolt = <330>;
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-51-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 48/52] arm64: dts: allwinner: h6: Fix de3 parent clocks ordering

2021-09-01 Thread Maxime Ripard
While it doesn't really matter from a functional point of view in this
driver's case, it's usually a good practice to list the clocks in a
driver in the same driver across all its users.

The H6 is using the inverse order than all the other users, so let's
make it consistent.

Signed-off-by: Maxime Ripard 
---
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 30d396e8c762..46ed529a4dc2 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -119,10 +119,10 @@ bus@100 {
display_clocks: clock@0 {
compatible = "allwinner,sun50i-h6-de3-clk";
reg = <0x0 0x1>;
-   clocks = < CLK_DE>,
-< CLK_BUS_DE>;
-   clock-names = "mod",
- "bus";
+   clocks = < CLK_BUS_DE>,
+< CLK_DE>;
+   clock-names = "bus",
+ "mod";
resets = < RST_BUS_DE>;
#clock-cells = <1>;
#reset-cells = <1>;
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-49-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 49/52] arm64: dts: allwinner: a100: Fix thermal zone node name

2021-09-01 Thread Maxime Ripard
The thermal zones one the A100 are called $device-thermal-zone.

However, the thermal zone binding explicitly requires that zones are
called *-thermal. Let's fix it.

Signed-off-by: Maxime Ripard 
---
 arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
index cc321c04f121..f6d7d7f7fdab 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
@@ -343,19 +343,19 @@ r_i2c1: i2c@7081800 {
};
 
thermal-zones {
-   cpu-thermal-zone {
+   cpu-thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
thermal-sensors = < 0>;
};
 
-   ddr-thermal-zone {
+   ddr-thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
thermal-sensors = < 2>;
};
 
-   gpu-thermal-zone {
+   gpu-thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
thermal-sensors = < 1>;
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-50-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 47/52] arm64: dts: allwinner: h5: Fix GPU thermal zone node name

2021-09-01 Thread Maxime Ripard
The GPU thermal zone is named gpu_thermal. However, the underscore is
an invalid character for a node name and the thermal zone binding
explicitly requires that zones are called *-thermal. Let's fix it.

Signed-off-by: Maxime Ripard 
---
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index 578a63dedf46..9988e87ea7b3 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -217,7 +217,7 @@ cpu-hot-limit {
};
};
 
-   gpu_thermal {
+   gpu-thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
thermal-sensors = < 1>;
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-48-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 46/52] ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible

2021-09-01 Thread Maxime Ripard
The dumb-vga-dac and adi,adv7123 compatibles are not supposed to be used
together according to the binding.

Since the corpro gm7123 is a drop-in replacement for the adv7123, let's
remove dumb-vga-dac from our compatible list.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts 
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 1fe251ea94bc..c8ca8cb7f5c9 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -87,7 +87,7 @@ vga_con_in: endpoint {
};
 
vga-dac {
-   compatible = "corpro,gm7123", "adi,adv7123", "dumb-vga-dac";
+   compatible = "corpro,gm7123", "adi,adv7123";
vdd-supply = <_dcdc1>;
 
ports {
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-47-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 45/52] ARM: dts: tbs711: Fix touchscreen compatible

2021-09-01 Thread Maxime Ripard
The edt,edt-ft5x06 compatible has never been a valid compatible
according to the binding. Let's change for one that is.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts 
b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index 7fe2a584ddf9..a7d4ca308990 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -169,7 +169,7 @@  {
status = "okay";
 
touchscreen@38 {
-   compatible = "edt,edt-ft5x06";
+   compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <_pio>;
interrupts = <0 7 IRQ_TYPE_EDGE_FALLING>; /* PL7 */
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-46-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 44/52] ARM: dts: v3s: Remove useless DMA properties

2021-09-01 Thread Maxime Ripard
The crypto engine binding doesn't allow for any DMA property, yet the
v3s define some. Remove them.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index b30bc1a25ebb..44382e36e825 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -285,8 +285,6 @@ crypto@1c15000 {
interrupts = ;
clocks = < CLK_BUS_CE>, < CLK_CE>;
clock-names = "ahb", "mod";
-   dmas = < 16>, < 16>;
-   dma-names = "rx", "tx";
resets = < RST_BUS_CE>;
reset-names = "ahb";
};
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-45-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 42/52] ARM: dts: sunxi: Fix OPPs node name

2021-09-01 Thread Maxime Ripard
The operating-points-v2 nodes are named inconsistently, but mostly
either opp_table0 or gpu-opp-table.  However, the underscore is an
invalid character for a node name and the thermal zone binding
explicitly requires that zones are called opp-table-*. Let's fix it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a33.dtsi  | 4 ++--
 arch/arm/boot/dts/sun8i-a83t.dtsi | 4 ++--
 arch/arm/boot/dts/sun8i-h3.dtsi   | 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi  | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi  | 2 +-
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 2beddbb3c518..b3d1bdfb5118 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -46,7 +46,7 @@
 #include 
 
 / {
-   cpu0_opp_table: opp_table0 {
+   cpu0_opp_table: opp-table-cpu {
compatible = "operating-points-v2";
opp-shared;
 
@@ -164,7 +164,7 @@ iio-hwmon {
io-channels = <>;
};
 
-   mali_opp_table: gpu-opp-table {
+   mali_opp_table: opp-table-gpu {
compatible = "operating-points-v2";
 
opp-14400 {
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index ac97eac91349..82fdb04122ca 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -200,7 +200,7 @@ de: display-engine {
status = "disabled";
};
 
-   cpu0_opp_table: opp_table0 {
+   cpu0_opp_table: opp-table-cluster0 {
compatible = "operating-points-v2";
opp-shared;
 
@@ -253,7 +253,7 @@ opp-12 {
};
};
 
-   cpu1_opp_table: opp_table1 {
+   cpu1_opp_table: opp-table-cluster1 {
compatible = "operating-points-v2";
opp-shared;
 
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 4e89701df91f..ae4f933abb89 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -44,7 +44,7 @@
 #include 
 
 / {
-   cpu0_opp_table: opp_table0 {
+   cpu0_opp_table: opp-table-cpu {
compatible = "operating-points-v2";
opp-shared;
 
@@ -112,7 +112,7 @@ cpu3: cpu@3 {
};
};
 
-   gpu_opp_table: gpu-opp-table {
+   gpu_opp_table: opp-table-gpu {
compatible = "operating-points-v2";
 
opp-12000 {
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi
index 578c37490d90..e39db51eb448 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi
@@ -4,7 +4,7 @@
  */
 
 / {
-   cpu0_opp_table: opp_table0 {
+   cpu0_opp_table: opp-table-cpu {
compatible = "operating-points-v2";
opp-shared;
 
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi
index b2657201957e..1afad8b437d7 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi
@@ -2,7 +2,7 @@
 // Copyright (C) 2020 Chen-Yu Tsai 
 
 / {
-   cpu_opp_table: cpu-opp-table {
+   cpu_opp_table: opp-table-cpu {
compatible = "operating-points-v2";
opp-shared;
 
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi
index 8c6e8536b69f..0baf0f8e4d27 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi
@@ -3,7 +3,7 @@
 // Copyright (C) 2020 Clément Péron 
 
 / {
-   cpu_opp_table: cpu-opp-table {
+   cpu_opp_table: opp-table-cpu {
compatible = "allwinner,sun50i-h6-operating-points";
nvmem-cells = <_speed_grade>;
opp-shared;
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-43-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 43/52] ARM: dts: sunxi: Fix the SPI NOR node names

2021-09-01 Thread Maxime Ripard
According to the SPI NOR bindings, the flash node names are supposed to
be flash@. Let's fix our users to use that new scheme.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-v3-sl631.dtsi | 2 +-
 arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi  | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-v3-sl631.dtsi 
b/arch/arm/boot/dts/sun8i-v3-sl631.dtsi
index e0d2a31efc7f..6f93f8c49f84 100644
--- a/arch/arm/boot/dts/sun8i-v3-sl631.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3-sl631.dtsi
@@ -115,7 +115,7 @@ _ldo2 {
  {
status = "okay";
 
-   spi-flash@0 {
+   flash@0 {
reg = <0>;
compatible = "jedec,spi-nor";
spi-max-frequency = <5000>;
diff --git a/arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi 
b/arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi
index 204fba3614f9..50d328c2a84d 100644
--- a/arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi
+++ b/arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi
@@ -156,7 +156,7 @@ _pio {
  {
status = "okay";
 
-   spiflash@0 {
+   flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <5000>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
index 097a5511523a..c519d9fa6967 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
@@ -343,7 +343,7 @@  {
  {
status = "okay";
 
-   spi-flash@0 {
+   flash@0 {
compatible = "mxicy,mx25l1606e", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <8000>;
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-44-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 41/52] ARM: dts: sunxi: Fix OPP arrays

2021-09-01 Thread Maxime Ripard
Even though it translates to the same thing down to the binary level, we
should have an array of 2 number cells to describe each OPP, which in
turns create a validation warning.

Let's fix this.

Signed-off-by: Maxime Ripard 
---
 .../arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 11 +++--
 arch/arm/boot/dts/sun4i-a10.dtsi  | 11 +++--
 arch/arm/boot/dts/sun5i-a13.dtsi  | 15 +++
 arch/arm/boot/dts/sun6i-a31.dtsi  | 44 +--
 arch/arm/boot/dts/sun7i-a20-bananapi.dts  | 17 ---
 arch/arm/boot/dts/sun7i-a20.dtsi  | 34 +++---
 6 files changed, 61 insertions(+), 71 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts 
b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
index ad0e25af45be..83d283cf6633 100644
--- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
@@ -91,12 +91,11 @@  {
/*
 * The A10-Lime is known to be unstable when running at 1008 MHz
 */
-   operating-points = <
-   /* kHzuV */
-   912000  135
-   864000  130
-   624000  125
-   >;
+   operating-points =
+   /* kHzuV */
+   <912000 135>,
+   <864000 130>,
+   <624000 125>;
 };
 
  {
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 1c5a666c54b5..51a6464aab9a 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -115,13 +115,12 @@ cpu0: cpu@0 {
reg = <0x0>;
clocks = < CLK_CPU>;
clock-latency = <244144>; /* 8 32k periods */
-   operating-points = <
+   operating-points =
/* kHzuV */
-   1008000 140
-   912000  135
-   864000  130
-   624000  125
-   >;
+   <1008000 140>,
+   <912000 135>,
+   <864000 130>,
+   <624000 125>;
#cooling-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 7075e10911d5..3325ab07094a 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -102,15 +102,14 @@  {
 
  {
clock-latency = <244144>; /* 8 32k periods */
-   operating-points = <
+   operating-points =
/* kHzuV */
-   1008000 140
-   912000  135
-   864000  130
-   624000  120
-   576000  120
-   432000  120
-   >;
+   <1008000 140>,
+   <912000 135>,
+   <864000 130>,
+   <624000 120>,
+   <576000 120>,
+   <432000 120>;
#cooling-cells = <2>;
 };
 
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index a31f9072bf79..715d74854449 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -105,13 +105,12 @@ cpu0: cpu@0 {
reg = <0>;
clocks = < CLK_CPU>;
clock-latency = <244144>; /* 8 32k periods */
-   operating-points = <
+   operating-points =
/* kHzuV */
-   1008000 120
-   864000  120
-   72  110
-   48  100
-   >;
+   <1008000 120>,
+   <864000 120>,
+   <72 110>,
+   <48 100>;
#cooling-cells = <2>;
};
 
@@ -121,13 +120,12 @@ cpu1: cpu@1 {
reg = <1>;
clocks = < CLK_CPU>;
clock-latency = <244144>; /* 8 32k periods */
-   operating-points = <
+   operating-points =
/* kHzuV */
-   1008000 120
-   864000  120
-   72  110
-   48  100
- 

[linux-sunxi] [PATCH v2 40/52] ARM: dts: sunxi: Rename gpio pinctrl names

2021-09-01 Thread Maxime Ripard
We've had a pinctrl node name convention for a while now, let's follow
it for the AXP pinctrl nodes as well.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/axp81x.dtsi | 4 ++--
 arch/arm64/boot/dts/allwinner/axp803.dtsi | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
index 63fb9811b453..b93387b0c1c3 100644
--- a/arch/arm/boot/dts/axp81x.dtsi
+++ b/arch/arm/boot/dts/axp81x.dtsi
@@ -63,12 +63,12 @@ axp_gpio: gpio {
gpio-controller;
#gpio-cells = <2>;
 
-   gpio0_ldo: gpio0-ldo {
+   gpio0_ldo: gpio0-ldo-pin {
pins = "GPIO0";
function = "ldo";
};
 
-   gpio1_ldo: gpio1-ldo {
+   gpio1_ldo: gpio1-ldo-pin {
pins = "GPIO1";
function = "ldo";
};
diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi 
b/arch/arm64/boot/dts/allwinner/axp803.dtsi
index 61402057e107..578ef368e2b4 100644
--- a/arch/arm64/boot/dts/allwinner/axp803.dtsi
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -26,12 +26,12 @@ axp_gpio: gpio {
gpio-controller;
#gpio-cells = <2>;
 
-   gpio0_ldo: gpio0-ldo {
+   gpio0_ldo: gpio0-ldo-pin {
pins = "GPIO0";
function = "ldo";
};
 
-   gpio1_ldo: gpio1-ldo {
+   gpio1_ldo: gpio1-ldo-pin {
pins = "GPIO1";
function = "ldo";
};
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-41-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 38/52] dt-bindings: w1: Convert 1-Wire GPIO binding to a schema

2021-09-01 Thread Maxime Ripard
Bitbanged 1-Wire buses are supported by Linux thanks to their device
tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: Daniel Mack 
Cc: Evgeniy Polyakov 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Changed additionalproperties to make sure all the other items in the
schema are nodes
---
 .../devicetree/bindings/w1/w1-gpio.txt| 27 
 .../devicetree/bindings/w1/w1-gpio.yaml   | 44 +++
 2 files changed, 44 insertions(+), 27 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.txt
 create mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.yaml

diff --git a/Documentation/devicetree/bindings/w1/w1-gpio.txt 
b/Documentation/devicetree/bindings/w1/w1-gpio.txt
deleted file mode 100644
index 3d6554eac240..
--- a/Documentation/devicetree/bindings/w1/w1-gpio.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-w1-gpio devicetree bindings
-
-Required properties:
-
- - compatible: "w1-gpio"
- - gpios: one or two GPIO specs:
-   - the first one is used as data I/O pin
-   - the second one is optional. If specified, it is used as
- enable pin for an external pin pullup.
-
-Optional properties:
-
- - linux,open-drain: if specified, the data pin is considered in
-open-drain mode.
-
-Also refer to the generic w1.txt document.
-
-Examples:
-
-   onewire {
-   compatible = "w1-gpio";
-   gpios = < 0 GPIO_ACTIVE_HIGH>;
-
-   battery {
-   // ...
-   };
-   };
diff --git a/Documentation/devicetree/bindings/w1/w1-gpio.yaml 
b/Documentation/devicetree/bindings/w1/w1-gpio.yaml
new file mode 100644
index ..7ba1c2fd4722
--- /dev/null
+++ b/Documentation/devicetree/bindings/w1/w1-gpio.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/w1/w1-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bitbanged GPIO 1-Wire Bus Device Tree Bindings
+
+maintainers:
+  - Daniel Mack 
+
+properties:
+  compatible:
+const: w1-gpio
+
+  gpios:
+minItems: 1
+maxItems: 2
+items:
+  - description: Data I/O pin
+  - description: Enable pin for an external pull-up resistor
+
+  linux,open-drain:
+type: boolean
+description: >
+  If specified, the data pin is considered in open-drain mode.
+
+required:
+  - compatible
+  - gpios
+
+additionalProperties:
+  type: object
+
+examples:
+  - |
+#include 
+
+onewire {
+compatible = "w1-gpio";
+gpios = < 0 GPIO_ACTIVE_HIGH>;
+};
+
+...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-39-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 39/52] ARM: dts: sunxi: Rename power-supply names

2021-09-01 Thread Maxime Ripard
The name of our PMIC power supply names conflict with the generic
regulator supply check that matches anything called *-supply, including
the nodes, and then makes sure it's a phandle.

A node is obviously not a phandle, so let's change our power supplies
names to avoid any conflict.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/axp209.dtsi | 6 +++---
 arch/arm/boot/dts/axp22x.dtsi | 6 +++---
 arch/arm/boot/dts/axp81x.dtsi | 6 +++---
 arch/arm64/boot/dts/allwinner/axp803.dtsi | 6 +++---
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 0d9ff12bdf28..ca240cd6f6c3 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -53,7 +53,7 @@  {
interrupt-controller;
#interrupt-cells = <1>;
 
-   ac_power_supply: ac-power-supply {
+   ac_power_supply: ac-power {
compatible = "x-powers,axp202-ac-power-supply";
status = "disabled";
};
@@ -69,7 +69,7 @@ axp_gpio: gpio {
#gpio-cells = <2>;
};
 
-   battery_power_supply: battery-power-supply {
+   battery_power_supply: battery-power {
compatible = "x-powers,axp209-battery-power-supply";
status = "disabled";
};
@@ -112,7 +112,7 @@ reg_ldo5: ldo5 {
};
};
 
-   usb_power_supply: usb-power-supply {
+   usb_power_supply: usb-power {
compatible = "x-powers,axp202-usb-power-supply";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/axp22x.dtsi
index 65a07a67aca9..a020c12b2884 100644
--- a/arch/arm/boot/dts/axp22x.dtsi
+++ b/arch/arm/boot/dts/axp22x.dtsi
@@ -52,7 +52,7 @@  {
interrupt-controller;
#interrupt-cells = <1>;
 
-   ac_power_supply: ac-power-supply {
+   ac_power_supply: ac-power {
compatible = "x-powers,axp221-ac-power-supply";
status = "disabled";
};
@@ -62,7 +62,7 @@ axp_adc: adc {
#io-channel-cells = <1>;
};
 
-   battery_power_supply: battery-power-supply {
+   battery_power_supply: battery-power {
compatible = "x-powers,axp221-battery-power-supply";
status = "disabled";
};
@@ -163,7 +163,7 @@ reg_drivevbus: drivevbus {
};
};
 
-   usb_power_supply: usb_power_supply {
+   usb_power_supply: usb-power {
compatible = "x-powers,axp221-usb-power-supply";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
index 1dfeeceabf4c..63fb9811b453 100644
--- a/arch/arm/boot/dts/axp81x.dtsi
+++ b/arch/arm/boot/dts/axp81x.dtsi
@@ -48,7 +48,7 @@  {
interrupt-controller;
#interrupt-cells = <1>;
 
-   ac_power_supply: ac-power-supply {
+   ac_power_supply: ac-power {
compatible = "x-powers,axp813-ac-power-supply";
status = "disabled";
};
@@ -74,7 +74,7 @@ gpio1_ldo: gpio1-ldo {
};
};
 
-   battery_power_supply: battery-power-supply {
+   battery_power_supply: battery-power {
compatible = "x-powers,axp813-battery-power-supply";
status = "disabled";
};
@@ -172,7 +172,7 @@ reg_drivevbus: drivevbus {
};
};
 
-   usb_power_supply: usb-power-supply {
+   usb_power_supply: usb-power {
compatible = "x-powers,axp813-usb-power-supply";
};
 };
diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi 
b/arch/arm64/boot/dts/allwinner/axp803.dtsi
index 10e9186a76bf..61402057e107 100644
--- a/arch/arm64/boot/dts/allwinner/axp803.dtsi
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -10,7 +10,7 @@  {
interrupt-controller;
#interrupt-cells = <1>;
 
-   ac_power_supply: ac-power-supply {
+   ac_power_supply: ac-power {
compatible = "x-powers,axp803-ac-power-supply",
 "x-powers,axp813-ac-power-supply";
status = "disabled";
@@ -37,7 +37,7 @@ gpio1_ldo: gpio1-ldo {
};
};
 
-   battery_power_supply: battery-power-supply {
+   battery_power_supply: battery-power {
compatible = "x-powers,axp803-battery-power-supply",
 "x-powers,axp813-battery-power-supply";
status = "disabled";
@@ -147,7 +147,7 @@ reg_drivevbus: drivevbus {
};
};
 
-   usb_power_supply: usb-power-supply {
+   usb_power_supply: usb-power {

[linux-sunxi] [PATCH v2 37/52] dt-bindings: usb: dwc3: Fix usb-phy check

2021-09-01 Thread Maxime Ripard
The original binding was allowing any combination of usb2-phy and
usb3-phy in the phys and phy-names properties.

However, the current binding enforces that those properties must be a
list of usb2-phy and usb3-phy, with exactly one element, effectively
making usb2-phy the only value being valid.

Let's rework the properties description to allow either one or two
element picked with values either usb2-phy or usb3-phy. The rest of the
tooling makes sure that we don't get any duplicate value, so this should
be what we want.

Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml 
b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index 078fb7889593..c1c970073681 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -73,15 +73,15 @@ properties:
 
   phys:
 minItems: 1
-items:
-  - description: USB2/HS PHY
-  - description: USB3/SS PHY
+maxItems: 2
 
   phy-names:
 minItems: 1
+maxItems: 2
 items:
-  - const: usb2-phy
-  - const: usb3-phy
+  enum:
+- usb2-phy
+- usb3-phy
 
   resets:
 minItems: 1
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-38-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 36/52] dt-bindings: usb: Convert SMSC USB3503 binding to a schema

2021-09-01 Thread Maxime Ripard
The SMSC USB3503 USB Hub Controller is supported by Linux thanks to
its device tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: Dongjin Kim 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Added maximum number of items for clocks and gpios
  - Fixed the example node name
---
 .../devicetree/bindings/usb/smsc,usb3503.yaml | 108 ++
 .../devicetree/bindings/usb/usb3503.txt   |  39 ---
 2 files changed, 108 insertions(+), 39 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/smsc,usb3503.yaml
 delete mode 100644 Documentation/devicetree/bindings/usb/usb3503.txt

diff --git a/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml 
b/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml
new file mode 100644
index ..39228a506b93
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/smsc,usb3503.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SMSC USB3503 High-Speed Hub Controller Device Tree Bindings
+
+maintainers:
+  - Dongjin Kim 
+
+properties:
+  compatible:
+enum:
+  - smsc,usb3503
+  - smsc,usb3503a
+
+  reg:
+maxItems: 1
+
+  connect-gpios:
+maxItems: 1
+description: >
+  GPIO for connect
+
+  intn-gpios:
+maxItems: 1
+description: >
+  GPIO for interrupt
+
+  reset-gpios:
+maxItems: 1
+description: >
+  GPIO for reset
+
+  disabled-ports:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+maxItems: 3
+items:
+  minimum: 1
+  maximum: 3
+description: >
+  Specifies the ports unused using their port number. Do not describe this
+  property if all ports have to be enabled.
+
+  initial-mode:
+enum: [1, 2]
+description: >
+  Specifies initial mode. 1 for Hub mode, 2 for standby mode.
+
+  clocks:
+maxItems: 1
+description: >
+  Clock used for driving REFCLK signal. If not provided the driver assumes
+  that clock signal is always available, its rate is specified by REF_SEL
+  pins and a value from the primary reference clock frequencies table is
+  used.
+
+  clock-names:
+const: refclk
+
+  refclk-frequency:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: >
+  Frequency of the REFCLK signal as defined by REF_SEL pins. If not
+  provided, driver will not set rate of the REFCLK signal and assume that a
+  value from the primary reference clock frequencies table is used.
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+  i2c {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  usb-hub@8 {
+  compatible = "smsc,usb3503";
+  reg = <0x08>;
+  connect-gpios = < 0 1>;
+  disabled-ports = <2 3>;
+  intn-gpios = < 4 1>;
+  reset-gpios = < 5 1>;
+  initial-mode = <1>;
+  clocks = < 80>;
+  clock-names = "refclk";
+  };
+  };
+
+  - |
+  #include 
+
+  usb-hub {
+  /* I2C is not connected */
+  compatible = "smsc,usb3503";
+  initial-mode = <1>; /* initialize in HUB mode */
+  disabled-ports = <1>;
+  intn-gpios = < 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+  reset-gpios = < 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
+  connect-gpios = < 4 17 GPIO_ACTIVE_HIGH>; /* PE17 */
+  refclk-frequency = <1920>;
+  };
+
+...
diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt 
b/Documentation/devicetree/bindings/usb/usb3503.txt
deleted file mode 100644
index 057dd384d473..
--- a/Documentation/devicetree/bindings/usb/usb3503.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-SMSC USB3503 High-Speed Hub Controller
-
-Required properties:
-- compatible: Should be "smsc,usb3503" or "smsc,usb3503a".
-
-Optional properties:
-- reg: Specifies the i2c slave address, it is required and should be 0x08
-   if I2C is used.
-- connect-gpios: Should specify GPIO for connect.
-- disabled-ports: Should specify the ports unused.
-   '1' or '2' or '3' are available for this property to describe the port
-   number. 1~3 property values are possible to be described.
-   Do not describe this property if all ports have to be enabled.
-- intn-gpios: Should specify GPIO for interrupt.
-- reset-gpios: Should specify GPIO for reset.
-- initial-mode: Should specify initial mode.
-(1 for HUB mode, 2 for STANDBY mode)
-- refclk: Clock used for driving REFCLK signal (optio

[linux-sunxi] [PATCH v2 34/52] dt-bindings: sunxi: Add CPU Configuration Controller Binding

2021-09-01 Thread Maxime Ripard
Even though we've used the CPU configuration driver for some time and a
number of boards using it already, we never had a binding for it. Let's
add it based on what the driver expects and the boards are providing.

Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 .../sunxi/allwinner,sun6i-a31-cpuconfig.yaml  | 38 +++
 1 file changed, 38 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml

diff --git 
a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml
 
b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml
new file mode 100644
index ..f3878e0b3cc4
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner CPU Configuration Controller Device Tree Bindings
+
+maintainers:
+  - Chen-Yu Tsai 
+  - Maxime Ripard 
+
+properties:
+  compatible:
+enum:
+  - allwinner,sun6i-a31-cpuconfig
+  - allwinner,sun8i-a23-cpuconfig
+  - allwinner,sun8i-a83t-cpucfg
+  - allwinner,sun8i-a83t-r-cpucfg
+  - allwinner,sun9i-a80-cpucfg
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+  cpucfg@1f01c00 {
+  compatible = "allwinner,sun6i-a31-cpuconfig";
+  reg = <0x01f01c00 0x300>;
+  };
+
+...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-35-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 35/52] dt-bindings: sunxi: Add Allwinner A80 PRCM Binding

2021-09-01 Thread Maxime Ripard
Even though we've used the A80 PRCM driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.

Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 .../arm/sunxi/allwinner,sun9i-a80-prcm.yaml   | 33 +++
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml

diff --git 
a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml 
b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml
new file mode 100644
index ..668aadbfe4c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/sunxi/allwinner,sun9i-a80-prcm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A80 PRCM Device Tree Bindings
+
+maintainers:
+  - Chen-Yu Tsai 
+  - Maxime Ripard 
+
+properties:
+  compatible:
+const: allwinner,sun9i-a80-prcm
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+  prcm@8001400 {
+  compatible = "allwinner,sun9i-a80-prcm";
+  reg = <0x08001400 0x200>;
+  };
+
+...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-36-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 33/52] dt-bindings: regulator: Convert SY8106A binding to a schema

2021-09-01 Thread Maxime Ripard
The Silergy SY8106A is a regulator controlled through i2c supported by
Linux with a matching device tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: Icenowy Zheng 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Ondrej Jirman 
Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 .../bindings/regulator/silergy,sy8106a.yaml   | 52 +++
 .../bindings/regulator/sy8106a-regulator.txt  | 23 
 2 files changed, 52 insertions(+), 23 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml
 delete mode 100644 
Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml 
b/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml
new file mode 100644
index ..a52a67c869b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/silergy,sy8106a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silergy SY8106A Voltage Regulator Device Tree Bindings
+
+maintainers:
+  - Ondrej Jirman 
+
+allOf:
+  - $ref: regulator.yaml#
+
+properties:
+  compatible:
+const: silergy,sy8106a
+
+  reg:
+maxItems: 1
+
+  silergy,fixed-microvolt:
+description: >
+  The voltage when I2C regulating is disabled (set by external resistor
+  like a fixed voltage)
+
+required:
+  - compatible
+  - reg
+  - silergy,fixed-microvolt
+
+unevaluatedProperties: false
+
+examples:
+  - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+regulator@65 {
+compatible = "silergy,sy8106a";
+reg = <0x65>;
+regulator-name = "sy8106a-vdd";
+silergy,fixed-microvolt = <120>;
+regulator-min-microvolt = <100>;
+regulator-max-microvolt = <140>;
+regulator-boot-on;
+regulator-always-on;
+};
+};
+
+...
diff --git a/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt 
b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
deleted file mode 100644
index 39a8ca73f572..
--- a/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-SY8106A Voltage regulator
-
-Required properties:
-- compatible: Must be "silergy,sy8106a"
-- reg: I2C slave address - must be <0x65>
-- silergy,fixed-microvolt - the voltage when I2C regulating is disabled (set
-  by external resistor like a fixed voltage)
-
-Any property defined as part of the core regulator binding, defined in
-./regulator.txt, can also be used.
-
-Example:
-
-   sy8106a {
-   compatible = "silergy,sy8106a";
-   reg = <0x65>;
-   regulator-name = "sy8106a-vdd";
-   silergy,fixed-microvolt = <120>;
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <140>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-34-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 32/52] dt-bindings: net: wireless: Convert ESP ESP8089 binding to a schema

2021-09-01 Thread Maxime Ripard
The ESP8089 Wireless Chip is supported by Linux (through an out-of-tree
driver) thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: "David S. Miller" 
Cc: de Goede 
Cc: Jakub Kicinski 
Cc: Kalle Valo 
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 .../bindings/net/wireless/esp,esp8089.txt | 30 -
 .../bindings/net/wireless/esp,esp8089.yaml| 43 +++
 2 files changed, 43 insertions(+), 30 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt
 create mode 100644 
Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml

diff --git a/Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt 
b/Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt
deleted file mode 100644
index 6830c4786f8a..
--- a/Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Espressif ESP8089 wireless SDIO devices
-
-This node provides properties for controlling the ESP8089 wireless device.
-The node is expected to be specified as a child node to the SDIO controller
-that connects the device to the system.
-
-Required properties:
-
- - compatible : Should be "esp,esp8089".
-
-Optional properties:
- - esp,crystal-26M-en: Integer value for the crystal_26M_en firmware parameter
-
-Example:
-
- {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   vmmc-supply = <_dldo1>;
-   mmc-pwrseq = <_pwrseq>;
-   bus-width = <4>;
-   non-removable;
-
-   esp8089: sdio_wifi@1 {
-   compatible = "esp,esp8089";
-   reg = <1>;
-   esp,crystal-26M-en = <2>;
-   };
-};
diff --git a/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml 
b/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
new file mode 100644
index ..284ef45add99
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/esp,esp8089.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Espressif ESP8089 Device Tree Bindings
+
+maintainers:
+  - Hans de Goede 
+
+properties:
+  compatible:
+const: esp,esp8089
+
+  reg:
+maxItems: 1
+
+  esp,crystal-26M-en:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: >
+  Value for the crystal_26M_en firmware parameter
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+  mmc {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  wifi@1 {
+  compatible = "esp,esp8089";
+  reg = <1>;
+  esp,crystal-26M-en = <2>;
+  };
+  };
+
+...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-33-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 31/52] dt-bindings: net: dwmac: Fix typo in the R40 compatible

2021-09-01 Thread Maxime Ripard
Even though both the driver and the device trees all use the
allwinner,sun8i-r40-gmac compatible, we documented the compatible as
allwinner,sun8i-r40-emac in the binding. Let's fix this.

Cc: Alexandre Torgue 
Cc: "David S. Miller" 
Cc: Giuseppe Cavallaro 
Cc: Jakub Kicinski 
Cc: Jose Abreu 
Cc: net...@vger.kernel.org
Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml  | 4 ++--
 Documentation/devicetree/bindings/net/snps,dwmac.yaml   | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml 
b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 7f2578d48e3f..9919d1912cc1 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -15,7 +15,7 @@ properties:
 oneOf:
   - const: allwinner,sun8i-a83t-emac
   - const: allwinner,sun8i-h3-emac
-  - const: allwinner,sun8i-r40-emac
+  - const: allwinner,sun8i-r40-gmac
   - const: allwinner,sun8i-v3s-emac
   - const: allwinner,sun50i-a64-emac
   - items:
@@ -91,7 +91,7 @@ allOf:
 compatible:
   contains:
 enum:
-  - allwinner,sun8i-r40-emac
+  - allwinner,sun8i-r40-gmac
 
 then:
   properties:
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 42689b7d03a2..3de8bca418f0 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -49,7 +49,7 @@ properties:
 - allwinner,sun7i-a20-gmac
 - allwinner,sun8i-a83t-emac
 - allwinner,sun8i-h3-emac
-- allwinner,sun8i-r40-emac
+- allwinner,sun8i-r40-gmac
 - allwinner,sun8i-v3s-emac
 - allwinner,sun50i-a64-emac
 - loongson,ls2k-dwmac
@@ -316,7 +316,7 @@ allOf:
   - allwinner,sun7i-a20-gmac
   - allwinner,sun8i-a83t-emac
   - allwinner,sun8i-h3-emac
-  - allwinner,sun8i-r40-emac
+  - allwinner,sun8i-r40-gmac
   - allwinner,sun8i-v3s-emac
   - allwinner,sun50i-a64-emac
   - ingenic,jz4775-mac
@@ -364,7 +364,7 @@ allOf:
   - allwinner,sun7i-a20-gmac
   - allwinner,sun8i-a83t-emac
   - allwinner,sun8i-h3-emac
-  - allwinner,sun8i-r40-emac
+  - allwinner,sun8i-r40-gmac
   - allwinner,sun8i-v3s-emac
   - allwinner,sun50i-a64-emac
   - loongson,ls2k-dwmac
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-32-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 30/52] dt-bindings: mmc: Convert MMC Card binding to a schema

2021-09-01 Thread Maxime Ripard
MMC Cards can have an optional Device Tree binding to add
non-discoverable properties.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Some of these properties were already described in the MMC controller
binding, even though they are not generic and do not apply to any
device, so we took the occasion to fix this.

Cc: linux-...@vger.kernel.org
Cc: Ulf Hansson 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Fixed additionalProperties
---
 .../devicetree/bindings/mmc/mmc-card.txt  | 30 
 .../devicetree/bindings/mmc/mmc-card.yaml | 48 +++
 .../bindings/mmc/mmc-controller.yaml  |  6 ---
 3 files changed, 48 insertions(+), 36 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yaml

diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt 
b/Documentation/devicetree/bindings/mmc/mmc-card.txt
deleted file mode 100644
index 8d2d71758907..
--- a/Documentation/devicetree/bindings/mmc/mmc-card.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-mmc-card / eMMC bindings
-
-
-This documents describes the devicetree bindings for a mmc-host controller
-child node describing a mmc-card / an eMMC, see "Use of Function subnodes"
-in mmc.txt
-
-Required properties:
--compatible : Must be "mmc-card"
--reg: Must be <0>
-
-Optional properties:
--broken-hpi : Use this to indicate that the mmc-card has a broken hpi
-  implementation, and that hpi should not be used
-
-Example:
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
-   vmmc-supply = <_vcc3v3>;
-   bus-width = <8>;
-   non-removable;
-
-   mmccard: mmccard@0 {
-   reg = <0>;
-   compatible = "mmc-card";
-   broken-hpi;
-   };
-};
diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml 
b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
new file mode 100644
index ..b17d454442b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/mmc-card.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MMC Card / eMMC Generic Device Tree Bindings
+
+maintainers:
+  - Ulf Hansson 
+
+description: |
+  This documents describes the devicetree bindings for a mmc-host controller
+  child node describing a mmc-card / an eMMC.
+
+properties:
+  compatible:
+const: mmc-card
+
+  reg:
+const: 0
+
+  broken-hpi:
+$ref: /schemas/types.yaml#/definitions/flag
+description:
+  Use this to indicate that the mmc-card has a broken hpi
+  implementation, and that hpi should not be used.
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+mmc {
+#address-cells = <1>;
+#size-cells = <0>;
+
+card@0 {
+compatible = "mmc-card";
+reg = <0>;
+broken-hpi;
+};
+};
+
+...
diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml 
b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
index 25ac8e200970..513f3c8758aa 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
@@ -333,12 +333,6 @@ patternProperties:
   subnode describes. A value of 0 denotes the memory SD
   function, values from 1 to 7 denote the SDIO functions.
 
-  broken-hpi:
-$ref: /schemas/types.yaml#/definitions/flag
-description:
-  Use this to indicate that the mmc-card has a broken hpi
-  implementation, and that hpi should not be used.
-
 required:
   - reg
 
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-31-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 29/52] dt-bindings: mfd: Convert X-Powers AXP binding to a schema

2021-09-01 Thread Maxime Ripard
The X-Powers AXP PMICs are supported by Linux thanks to its device tree
binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: Chen-Yu Tsai 
Cc: Lee Jones 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Add GPIO example
  - Remove the limitation on regulator-ramp-delay
---
 .../i2c/allwinner,sun6i-a31-p2wi.yaml |   2 +-
 .../devicetree/bindings/mfd/axp20x.txt| 273 
 .../bindings/mfd/x-powers,axp152.yaml | 400 ++
 3 files changed, 401 insertions(+), 274 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml

diff --git 
a/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml 
b/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml
index 6097e8ac46c1..1b03810d4b4d 100644
--- a/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml
+++ b/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml
@@ -55,7 +55,7 @@ examples:
 #size-cells = <0>;
 
 axp221: pmic@68 {
-compatible = "x-powers,axp221";
+/* compatible = "x-powers,axp221"; */
 reg = <0x68>;
 };
 };
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
deleted file mode 100644
index 2b53dcc0ea61..
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ /dev/null
@@ -1,273 +0,0 @@
-AXP family PMIC device tree bindings
-
-The axp20x family current members :
-axp152 (X-Powers)
-axp202 (X-Powers)
-axp209 (X-Powers)
-axp221 (X-Powers)
-axp223 (X-Powers)
-axp803 (X-Powers)
-axp806 (X-Powers)
-axp809 (X-Powers)
-axp813 (X-Powers)
-
-The AXP813 is 2 chips packaged into 1. The 2 chips do not share anything
-other than the packaging. Pins are routed separately. As such they should
-be treated as separate entities. The other half is an AC100 RTC/codec
-combo chip. Please see ./ac100.txt for its bindings.
-
-Required properties:
-- compatible: should be one of:
-* "x-powers,axp152"
-* "x-powers,axp202"
-* "x-powers,axp209"
-* "x-powers,axp221"
-* "x-powers,axp223"
-* "x-powers,axp803"
-* "x-powers,axp806"
-* "x-powers,axp805", "x-powers,axp806"
-* "x-powers,axp305", "x-powers,axp805", "x-powers,axp806"
-* "x-powers,axp809"
-* "x-powers,axp813"
-- reg: The I2C slave address or RSB hardware address for the AXP chip
-- interrupt-controller: The PMIC has its own internal IRQs
-- #interrupt-cells: Should be set to 1
-
-Supported common regulator properties, see ../regulator/regulator.txt for
-more information:
-- regulator-ramp-delay: sets the ramp up delay in uV/us
-   AXP20x/DCDC2: 1600, 800
-   AXP20x/LDO3:  1600, 800
-- regulator-soft-start:enable the output at the lowest possible 
voltage and
-   only then set the desired voltage
-   AXP20x/LDO3: software-based implementation
-
-Optional properties:
-- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
-- x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
- AXP152/20X: range:  750-1875, Default: 1.5 MHz
- AXP22X/8XX: range: 1800-4050, Default: 3   MHz
-
-- x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
- used as an output pin to control an external
- regulator to drive the OTG VBus, rather then
- as an input pin which signals whether the
- board is driving OTG VBus or not.
- (axp221 / axp223 / axp803/ axp813 only)
-
-- x-powers,self-working-mode and
-  x-powers,master-mode: Boolean (axp806 only). Set either of these when the
-   PMIC is wired for self-working mode or master mode.
-   If neither is set then slave mode is assumed.
-   This corresponds to how the MODESET pin is wired.
-
-- -supply: a phandle to the regulator supply node. May be omitted if
- inputs are unregulated, such as using the IPSOUT output
- from the PMIC.
-
-- regulators: A node that houses a sub-node for each regulator. Regulators
- not used but preferred to be managed by the OS should be
- listed as well.
- See Documentation/devicetree/bindings/regulator/regulator.txt
- for more information on standard regulator bindings.
-
-Optional properties for DCDC regulators:
-- x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO (PWM/PFM) mode
- Defau

[linux-sunxi] [PATCH v2 28/52] dt-bindings: mfd: Convert X-Powers AC100 binding to a schema

2021-09-01 Thread Maxime Ripard
The X-Powers AC100 hybrid devices are supported by Linux thanks to its
device tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: Lee Jones 
Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Added maximum number of clocks properties
---
 .../devicetree/bindings/mfd/ac100.txt |  50 
 .../bindings/mfd/x-powers,ac100.yaml  | 116 ++
 2 files changed, 116 insertions(+), 50 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mfd/ac100.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml

diff --git a/Documentation/devicetree/bindings/mfd/ac100.txt 
b/Documentation/devicetree/bindings/mfd/ac100.txt
deleted file mode 100644
index dff219f07493..
--- a/Documentation/devicetree/bindings/mfd/ac100.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-X-Powers AC100 Codec/RTC IC Device Tree bindings
-
-AC100 is a audio codec and RTC subsystem combo IC. The 2 parts are
-separated, including power supplies and interrupt lines, but share
-a common register address space and host interface.
-
-Required properties:
-- compatible: "x-powers,ac100"
-- reg: The I2C slave address or RSB hardware address for the chip
-- sub-nodes:
-  - codec
-- compatible:  "x-powers,ac100-codec"
-- interrupts:  SoC NMI / GPIO interrupt connected to the
-   IRQ_AUDIO pin
-- #clock-cells:Shall be 0
-- clock-output-names:  "4M_adda"
-
-- see clock/clock-bindings.txt for common clock bindings
-
-  - rtc
-- compatible:  "x-powers,ac100-rtc"
-- clocks:  A phandle to the codec's "4M_adda" clock
-- #clock-cells:Shall be 1
-- clock-output-names:  "cko1_rtc", "cko2_rtc", "cko3_rtc"
-
-- see clock/clock-bindings.txt for common clock bindings
-
-Example:
-
-ac100: codec@e89 {
-   compatible = "x-powers,ac100";
-   reg = <0xe89>;
-
-   ac100_codec: codec {
-   compatible = "x-powers,ac100-codec";
-   interrupt-parent = <_pio>;
-   interrupts = <0 9 IRQ_TYPE_LEVEL_LOW>; /* PL9 */
-   #clock-cells = <0>;
-   clock-output-names = "4M_adda";
-   };
-
-   ac100_rtc: rtc {
-   compatible = "x-powers,ac100-rtc";
-   interrupt-parent = <_intc>;
-   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-   clocks = <_codec>;
-   #clock-cells = <1>;
-   clock-output-names = "cko1_rtc", "cko2_rtc", "cko3_rtc";
-   };
-};
diff --git a/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml 
b/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml
new file mode 100644
index ..de330c9869ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/mfd/x-powers,ac100.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: X-Powers AC100 Device Tree Bindings
+
+maintainers:
+  - Chen-Yu Tsai 
+
+properties:
+  compatible:
+const: x-powers,ac100
+
+  reg:
+maxItems: 1
+
+  codec:
+type: object
+
+properties:
+  "#clock-cells":
+const: 0
+
+  compatible:
+const: x-powers,ac100-codec
+
+  interrupts:
+maxItems: 1
+
+  clock-output-names:
+maxItems: 1
+description: >
+  Name of the 4M_adda clock exposed by the codec
+
+required:
+  - "#clock-cells"
+  - compatible
+  - interrupts
+  - clock-output-names
+
+additionalProperties: false
+
+  rtc:
+type: object
+
+properties:
+  "#clock-cells":
+const: 1
+
+  compatible:
+const: x-powers,ac100-rtc
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+description: >
+   A phandle to the codec's "4M_adda" clock
+
+  clock-output-names:
+maxItems: 3
+description: >
+  Name of the cko1, cko2 and cko3 clocks exposed by the codec
+
+required:
+  - "#clock-cells"
+  - compatible
+  - interrupts
+  - clocks
+  - clock-output-names
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - codec
+  - rtc
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+rsb {
+#address-cells = <1>;
+#size-cells = <0>;
+
+codec@e89 {
+compatible = "x-powers,ac100";
+reg = <0xe89>;
+
+ac100_codec: cod

[linux-sunxi] [PATCH v2 27/52] dt-bindings: media: Convert OV5640 binding to a schema

2021-09-01 Thread Maxime Ripard
The Omnivision OV5640 is supported by Linux thanks to its device tree
binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: linux-me...@vger.kernel.org
Cc: Mauro Carvalho Chehab 
Cc: Steve Longerbeam 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/i2c/ov5640.txt  |  92 ---
 .../bindings/media/i2c/ovti,ov5640.yaml   | 154 ++
 2 files changed, 154 insertions(+), 92 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml

diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt 
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
deleted file mode 100644
index c97c2f2da12d..
--- a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-* Omnivision OV5640 MIPI CSI-2 / parallel sensor
-
-Required Properties:
-- compatible: should be "ovti,ov5640"
-- clocks: reference to the xclk input clock.
-- clock-names: should be "xclk".
-- DOVDD-supply: Digital I/O voltage supply, 1.8 volts
-- AVDD-supply: Analog voltage supply, 2.8 volts
-- DVDD-supply: Digital core voltage supply, 1.5 volts
-
-Optional Properties:
-- reset-gpios: reference to the GPIO connected to the reset pin, if any.
-  This is an active low signal to the OV5640.
-- powerdown-gpios: reference to the GPIO connected to the powerdown pin,
-  if any. This is an active high signal to the OV5640.
-- rotation: as defined in
-   Documentation/devicetree/bindings/media/video-interfaces.txt,
-   valid values are 0 (sensor mounted upright) and 180 (sensor
-   mounted upside down).
-
-The device node must contain one 'port' child node for its digital output
-video port, in accordance with the video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-OV5640 can be connected to a MIPI CSI-2 bus or a parallel bus endpoint.
-
-Endpoint node required properties for CSI-2 connection are:
-- remote-endpoint: a phandle to the bus receiver's endpoint node.
-- clock-lanes: should be set to <0> (clock lane on hardware lane 0)
-- data-lanes: should be set to <1> or <1 2> (one or two CSI-2 lanes supported)
-
-Endpoint node required properties for parallel connection are:
-- remote-endpoint: a phandle to the bus receiver's endpoint node.
-- bus-width: shall be set to <8> for 8 bits parallel bus
-or <10> for 10 bits parallel bus
-- data-shift: shall be set to <2> for 8 bits parallel bus
- (lines 9:2 are used) or <0> for 10 bits parallel bus
-- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH 
respectively.
-- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH 
respectively.
-- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
-  signal.
-
-Examples:
-
- {
-   ov5640: camera@3c {
-   compatible = "ovti,ov5640";
-   pinctrl-names = "default";
-   pinctrl-0 = <_ov5640>;
-   reg = <0x3c>;
-   clocks = < IMX6QDL_CLK_CKO>;
-   clock-names = "xclk";
-   DOVDD-supply = <_reg>; /* 1.8v */
-   AVDD-supply = <_reg>;  /* 2.8v */
-   DVDD-supply = <_reg>;  /* 1.5v */
-   powerdown-gpios = < 19 GPIO_ACTIVE_HIGH>;
-   reset-gpios = < 20 GPIO_ACTIVE_LOW>;
-   rotation = <180>;
-
-   port {
-   /* MIPI CSI-2 bus endpoint */
-   ov5640_to_mipi_csi2: endpoint {
-   remote-endpoint = <_csi2_from_ov5640>;
-   clock-lanes = <0>;
-   data-lanes = <1 2>;
-   };
-   };
-   };
-};
-
- {
-   ov5640: camera@3c {
-   compatible = "ovti,ov5640";
-   pinctrl-names = "default";
-   pinctrl-0 = <_ov5640>;
-   reg = <0x3c>;
-   clocks = <_ext_camera>;
-   clock-names = "xclk";
-
-   port {
-   /* Parallel bus endpoint */
-   ov5640_to_parallel: endpoint {
-   remote-endpoint = <_from_ov5640>;
-   bus-width = <8>;
-   data-shift = <2>; /* lines 9:2 are used */
-   hsync-active = <0>;
-   vsync-active = <0>;
-   pclk-sample = <1>;
-   };
-   };
-  

[linux-sunxi] [PATCH v2 26/52] dt-bindings: media: ti,cal: Fix example

2021-09-01 Thread Maxime Ripard
The OV5640 sensor used in the example doesn't follow the binding and
omits the regulators. Add some to make the example valid.

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/media/ti,cal.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/ti,cal.yaml 
b/Documentation/devicetree/bindings/media/ti,cal.yaml
index 65177cd69514..66c5d392fa75 100644
--- a/Documentation/devicetree/bindings/media/ti,cal.yaml
+++ b/Documentation/devicetree/bindings/media/ti,cal.yaml
@@ -154,7 +154,9 @@ examples:
 camera-sensor@3c {
compatible = "ovti,ov5640";
reg = <0x3c>;
-
+   AVDD-supply = <_2p8v>;
+   DOVDD-supply = <_1p8v>;
+   DVDD-supply = <_1p5v>;
clocks = <_ov5640_fixed>;
clock-names = "xclk";
 
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-27-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 25/52] dt-bindings: interconnect: sunxi: Add R40 MBUS compatible

2021-09-01 Thread Maxime Ripard
The R40 MBUS compatible was introduced recently but it was never
documented.

Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml  | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml 
b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml
index e713a6fe4cf7..29c9961ee2d8 100644
--- a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml
@@ -30,6 +30,7 @@ properties:
 enum:
   - allwinner,sun5i-a13-mbus
   - allwinner,sun8i-h3-mbus
+  - allwinner,sun8i-r40-mbus
   - allwinner,sun50i-a64-mbus
 
   reg:
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-26-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 23/52] dt-bindings: hwmon: Add IIO HWMON binding

2021-09-01 Thread Maxime Ripard
Even though we had the iio-hwmon driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.

Cc: Guenter Roeck 
Cc: Jean Delvare 
Cc: Jonathan Cameron 
Cc: linux-hw...@vger.kernel.org
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Reduced the maximum number of io-channels, and added a comment for
the limitation
---
 .../devicetree/bindings/hwmon/iio-hwmon.yaml  | 37 +++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml 
b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
new file mode 100644
index ..f5a6cc3efd33
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: ADC-attached Hardware Sensor Device Tree Bindings
+
+maintainers:
+  - Jonathan Cameron 
+
+description: >
+  Bindings for hardware monitoring devices connected to ADC controllers
+  supporting the Industrial I/O bindings.
+
+properties:
+  compatible:
+const: iio-hwmon
+
+  io-channels:
+minItems: 1
+maxItems: 8 # Should be enough
+description: >
+  List of phandles to ADC channels to read the monitoring values
+
+required:
+  - compatible
+  - io-channels
+
+additionalProperties: false
+
+examples:
+  - |
+  iio-hwmon {
+  compatible = "iio-hwmon";
+  io-channels = < 1>, < 2>;
+  };
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-24-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 24/52] dt-bindings: input: Convert Silead GSL1680 binding to a schema

2021-09-01 Thread Maxime Ripard
The Silead GSL1680 Touchscreen Controller is supported by Linux thanks
to its device tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Added maximum to the number of fingers
---
 .../input/touchscreen/silead,gsl1680.yaml | 91 +++
 .../input/touchscreen/silead_gsl1680.txt  | 44 -
 2 files changed, 91 insertions(+), 44 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
 delete mode 100644 
Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt

diff --git 
a/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml 
b/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
new file mode 100644
index ..cc064696ac28
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/silead,gsl1680.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silead GSL1680 Touchscreen Controller Device Tree Bindings
+
+maintainers:
+  - Dmitry Torokhov 
+
+allOf:
+  - $ref: touchscreen.yaml#
+
+properties:
+  compatible:
+enum:
+  - silead,gsl1680
+  - silead,gsl1688
+  - silead,gsl3670
+  - silead,gsl3675
+  - silead,gsl3692
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  power-gpios:
+maxItems: 1
+
+  firmware:
+$ref: /schemas/types.yaml#/definitions/string
+description: >
+  File basename for board specific firmware
+
+  silead,max-fingers:
+$ref: /schemas/types.yaml#/definitions/uint32
+maximum: 5
+description: >
+  Maximum number of fingers the touchscreen can detect
+
+  silead,home-button:
+type: boolean
+description: >
+  Does the device have a capacitive home-button build into the
+  touchscreen?
+
+  avdd-supply:
+description: >
+  Regulator phandle for controller AVDD
+
+  vddio-supply:
+description: >
+  Regulator phandle for controller VDDIO
+
+unevaluatedProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - power-gpios
+  - touchscreen-size-x
+  - touchscreen-size-y
+
+examples:
+  - |
+#include 
+#include 
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+touchscreen@40 {
+compatible = "silead,gsl1680";
+reg = <0x40>;
+interrupt-parent = <>;
+interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>;
+power-gpios = < 1 3 GPIO_ACTIVE_HIGH>;
+touchscreen-size-x = <480>;
+touchscreen-size-y = <800>;
+touchscreen-inverted-x;
+touchscreen-swapped-x-y;
+silead,max-fingers = <5>;
+};
+};
+
+...
diff --git 
a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt 
b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
deleted file mode 100644
index d67e558e5ab5..
--- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-* GSL 1680 touchscreen controller
-
-Required properties:
-- compatible : Must be one of the following, depending on the 
model:
-   "silead,gsl1680"
-   "silead,gsl1688"
-   "silead,gsl3670"
-   "silead,gsl3675"
-   "silead,gsl3692"
-- reg: I2C slave address of the chip (0x40)
-- interrupts : interrupt specification for the gsl1680 interrupt
-- power-gpios: Specification for the pin connected to the gsl1680's
-   shutdown input. This needs to be driven high to 
take the
-   gsl1680 out of its low power state
-- touchscreen-size-x : See touchscreen.txt
-- touchscreen-size-y : See touchscreen.txt
-
-Optional properties:
-- firmware-name  : File basename (string) for board specific 
firmware
-- touchscreen-inverted-x  : See touchscreen.txt
-- touchscreen-inverted-y  : See touchscreen.txt
-- touchscreen-swapped-x-y : See touchscreen.txt
-- silead,max-fingers : maximum number of fingers the touchscreen can detect
-- silead,home-button : Boolean, set to true on devices which have a
-   capacitive home-button build into the touchscreen
-- vddio-supply   : regulator phandle for controller VDDIO
-- avdd-supply: regulator phandle for controller AVDD
-
-Example:
-
-i2c@ {
-   gsl168

[linux-sunxi] [PATCH v2 22/52] dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema

2021-09-01 Thread Maxime Ripard
The X-Powers AXP PMICs feature a GPIO Controller supported by Linux
thanks to its device tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: Bartosz Golaszewski 
Cc: Chen-Yu Tsai 
Cc: Linus Walleij 
Cc: linux-g...@vger.kernel.org
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Removed the example and moved it in the mfd schema
---
 .../devicetree/bindings/gpio/gpio-axp209.txt  | 75 ---
 .../bindings/gpio/x-powers,axp209-gpio.yaml   | 55 ++
 2 files changed, 55 insertions(+), 75 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt
 create mode 100644 
Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml

diff --git a/Documentation/devicetree/bindings/gpio/gpio-axp209.txt 
b/Documentation/devicetree/bindings/gpio/gpio-axp209.txt
deleted file mode 100644
index fc42b2caa06d..
--- a/Documentation/devicetree/bindings/gpio/gpio-axp209.txt
+++ /dev/null
@@ -1,75 +0,0 @@
-AXP209 GPIO & pinctrl controller
-
-This driver follows the usual GPIO bindings found in
-Documentation/devicetree/bindings/gpio/gpio.txt
-
-This driver follows the usual pinctrl bindings found in
-Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-This driver employs the per-pin muxing pattern.
-
-Required properties:
-- compatible: Should be one of:
-   - "x-powers,axp209-gpio"
-   - "x-powers,axp813-gpio"
-- #gpio-cells: Should be two. The first cell is the pin number and the
-  second is the GPIO flags.
-- gpio-controller: Marks the device node as a GPIO controller.
-
-This node must be a subnode of the axp20x PMIC, documented in
-Documentation/devicetree/bindings/mfd/axp20x.txt
-
-Example:
-
-axp209: pmic@34 {
-   compatible = "x-powers,axp209";
-   reg = <0x34>;
-   interrupt-parent = <_intc>;
-   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-   interrupt-controller;
-   #interrupt-cells = <1>;
-
-   axp_gpio: gpio {
-   compatible = "x-powers,axp209-gpio";
-   gpio-controller;
-   #gpio-cells = <2>;
-   };
-};
-
-The GPIOs can be muxed to other functions and therefore, must be a subnode of
-axp_gpio.
-
-Example:
-
-_gpio {
-   gpio0_adc: gpio0-adc {
-   pins = "GPIO0";
-   function = "adc";
-   };
-};
-
-_node {
-   pinctrl-names = "default";
-   pinctrl-0 = <_adc>;
-};
-
-GPIOs and their functions
--
-
-Each GPIO is independent from the other (i.e. GPIO0 in gpio_in function does
-not force GPIO1 and GPIO2 to be in gpio_in function as well).
-
-axp209
---
-GPIO   |   Functions
-
-GPIO0  |   gpio_in, gpio_out, ldo, adc
-GPIO1  |   gpio_in, gpio_out, ldo, adc
-GPIO2  |   gpio_in, gpio_out
-
-axp813
---
-GPIO   |   Functions
-
-GPIO0  |   gpio_in, gpio_out, ldo, adc
-GPIO1  |   gpio_in, gpio_out, ldo
diff --git a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml 
b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
new file mode 100644
index ..0f628b088cec
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/gpio/x-powers,axp209-gpio.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: X-Powers AXP209 GPIO Device Tree Bindings
+
+maintainers:
+  - Chen-Yu Tsai 
+
+properties:
+  "#gpio-cells":
+const: 2
+description: >
+  The first cell is the pin number and the second is the GPIO flags.
+
+  compatible:
+oneOf:
+  - enum:
+  - x-powers,axp209-gpio
+  - x-powers,axp813-gpio
+  - items:
+  - const: x-powers,axp803-gpio
+  - const: x-powers,axp813-gpio
+
+  gpio-controller: true
+
+patternProperties:
+  "^.*-pins?$":
+$ref: /schemas/pinctrl/pinmux-node.yaml#
+
+properties:
+  pins:
+items:
+  enum:
+- GPIO0
+- GPIO1
+- GPIO2
+
+  function:
+enum:
+  - adc
+  - ldo
+  - gpio_in
+  - gpio_out
+
+required:
+  - compatible
+  - "#gpio-cells"
+  - gpio-controller
+
+additionalProperties: false
+
+...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-23-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 21/52] dt-bindings: gnss: Convert UBlox Neo-6M binding to a schema

2021-09-01 Thread Maxime Ripard
The UBlox Neo 6M is supported by Linux thanks to its device tree
binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: Johan Hovold 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Fixed a typo
  - Fixed the example node name
---
 .../bindings/gnss/u-blox,neo-6m.yaml  | 62 +++
 .../devicetree/bindings/gnss/u-blox.txt   | 45 --
 2 files changed, 62 insertions(+), 45 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
 delete mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt

diff --git a/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml 
b/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
new file mode 100644
index ..396101a223e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gnss/u-blox,neo-6m.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: U-blox GNSS Receiver Device Tree Bindings
+
+maintainers:
+  - Johan Hovold 
+
+description: >
+  The U-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
+
+properties:
+  compatible:
+enum:
+  - u-blox,neo-6m
+  - u-blox,neo-8
+  - u-blox,neo-m8
+
+  reg:
+description: >
+  The DDC Slave Address, SPI chip select address, the number of the USB hub
+  port or the USB host-controller port to which this device is attached,
+  depending on the bus used. Required for the DDC, SPI or USB busses.
+
+  vcc-supply:
+description: >
+  Main voltage regulator
+
+  timepulse-gpios:
+maxItems: 1
+description: >
+  Time pulse GPIO
+
+  u-blox,extint-gpios:
+maxItems: 1
+description: >
+  GPIO connected to the "external interrupt" input pin
+  
+  v-bckp-supply:
+description: >
+  Backup voltage regulator
+
+  current-speed: true
+
+required:
+  - compatible
+  - vcc-supply
+
+additionalProperties: false
+
+examples:
+  - |
+serial {
+gnss {
+compatible = "u-blox,neo-8";
+v-bckp-supply = <_v_bckp_reg>;
+vcc-supply = <_vcc_reg>;
+};
+};
diff --git a/Documentation/devicetree/bindings/gnss/u-blox.txt 
b/Documentation/devicetree/bindings/gnss/u-blox.txt
deleted file mode 100644
index 7cdefd058fe0..
--- a/Documentation/devicetree/bindings/gnss/u-blox.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-u-blox GNSS Receiver DT binding
-
-The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
-
-Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
-properties.
-
-Required properties:
-
-- compatible   : Must be one of
-
-   "u-blox,neo-6m"
-   "u-blox,neo-8"
-   "u-blox,neo-m8"
-
-- vcc-supply   : Main voltage regulator
-
-Required properties (DDC):
-- reg  : DDC (I2C) slave address
-
-Required properties (SPI):
-- reg  : SPI chip select address
-
-Required properties (USB):
-- reg  : Number of the USB hub port or the USB host-controller port
-  to which this device is attached
-
-Optional properties:
-
-- timepulse-gpios  : Time pulse GPIO
-- u-blox,extint-gpios  : GPIO connected to the "external interrupt" input pin
-- v-bckp-supply: Backup voltage regulator
-
-Example:
-
-serial@1234 {
-   compatible = "ns16550a";
-
-   gnss {
-   compatible = "u-blox,neo-8";
-
-   v-bckp-supply = <_v_bckp_reg>;
-   vcc-supply = <_vcc_reg>;
-   };
-};
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-22-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 20/52] dt-bindings: display: panel-lvds: Document missing panel compatibles

2021-09-01 Thread Maxime Ripard
A few panel-lvds compatibles were never documented. Let's add them.

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/panel/lvds.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 1563d57bc793..b2e8f5b263d7 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -73,10 +73,12 @@ properties:
   - enum:
   - advantech,idk-1110wr
   - advantech,idk-2121wr
+  - auo,b101ew05
   - innolux,ee101ia-01d
   - mitsubishi,aa104xd12
   - mitsubishi,aa121td01
   - sgd,gktw70sdae4se
+  - tbs,a711-panel
   - const: panel-lvds
 
   data-mapping:
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-21-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 19/52] dt-bindings: display: Move gktw70sdae4se to panel-lvds

2021-09-01 Thread Maxime Ripard
The Solomon Goldentek Display GKTW70SDAE4SE Device Tree binding doesn't
really add any useful content that is not already present in the
panel-lvds binding aside from a requirement on the data-mapping.

Let's move it to the generic panel-lvds binding

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 .../bindings/display/panel/lvds.yaml  |  2 +
 .../display/panel/sgd,gktw70sdae4se.yaml  | 68 ---
 2 files changed, 2 insertions(+), 68 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml

diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 22f6cf1e134d..1563d57bc793 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -35,6 +35,7 @@ allOf:
 enum:
   - mitsubishi,aa104xd12
   - mitsubishi,aa121td01
+  - sgd,gktw70sdae4se
 
 then:
   properties:
@@ -75,6 +76,7 @@ properties:
   - innolux,ee101ia-01d
   - mitsubishi,aa104xd12
   - mitsubishi,aa121td01
+  - sgd,gktw70sdae4se
   - const: panel-lvds
 
   data-mapping:
diff --git 
a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml 
b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
deleted file mode 100644
index e63a570ae59d..
--- a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
+++ /dev/null
@@ -1,68 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2

-$id: http://devicetree.org/schemas/display/panel/sgd,gktw70sdae4se.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Solomon Goldentek Display GKTW70SDAE4SE 7" WVGA LVDS Display Panel
-
-maintainers:
-  - Neil Armstrong 
-  - Thierry Reding 
-
-allOf:
-  - $ref: lvds.yaml#
-
-properties:
-  compatible:
-items:
-  - const: sgd,gktw70sdae4se
-  - {} # panel-lvds, but not listed here to avoid false select
-
-  data-mapping:
-const: jeida-18
-
-  width-mm:
-const: 153
-
-  height-mm:
-const: 86
-
-  panel-timing: true
-  port: true
-
-additionalProperties: false
-
-required:
-  - compatible
-
-examples:
-  - |+
-panel {
-  compatible = "sgd,gktw70sdae4se", "panel-lvds";
-
-  width-mm = <153>;
-  height-mm = <86>;
-
-  data-mapping = "jeida-18";
-
-  panel-timing {
-clock-frequency = <3200>;
-hactive = <800>;
-vactive = <480>;
-hback-porch = <39>;
-hfront-porch = <39>;
-vback-porch = <29>;
-vfront-porch = <13>;
-hsync-len = <47>;
-vsync-len = <2>;
-  };
-
-  port {
-panel_in: endpoint {
-  remote-endpoint = <_encoder>;
-};
-  };
-};
-
-...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-20-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 18/52] dt-bindings: display: Move aa121td01 to panel-lvds

2021-09-01 Thread Maxime Ripard
The Mitsubishi AA121TD01 Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding
aside from a requirement on the data-mapping.

Let's move it to the generic panel-lvds binding

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 .../bindings/display/panel/lvds.yaml  |  5 +-
 .../display/panel/mitsubishi,aa121td01.yaml   | 69 ---
 2 files changed, 4 insertions(+), 70 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml

diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 09a818a60f2e..22f6cf1e134d 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -32,7 +32,9 @@ allOf:
   properties:
 compatible:
   contains:
-const: mitsubishi,aa104xd12
+enum:
+  - mitsubishi,aa104xd12
+  - mitsubishi,aa121td01
 
 then:
   properties:
@@ -72,6 +74,7 @@ properties:
   - advantech,idk-2121wr
   - innolux,ee101ia-01d
   - mitsubishi,aa104xd12
+  - mitsubishi,aa121td01
   - const: panel-lvds
 
   data-mapping:
diff --git 
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml 
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
deleted file mode 100644
index 467a0ed4d444..
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
+++ /dev/null
@@ -1,69 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2

-$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa121td01.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Mitsubishi AA121TD01 12.1" WXGA LVDS Display Panel
-
-maintainers:
-  - Laurent Pinchart 
-  - Thierry Reding 
-
-allOf:
-  - $ref: lvds.yaml#
-
-properties:
-  compatible:
-items:
-  - const: mitsubishi,aa121td01
-  - {} # panel-lvds, but not listed here to avoid false select
-
-  data-mapping:
-const: jeida-18
-
-  width-mm:
-const: 261
-
-  height-mm:
-const: 163
-
-  panel-timing: true
-  port: true
-
-additionalProperties: false
-
-required:
-  - compatible
-
-examples:
-  - |+
-panel {
-  compatible = "mitsubishi,aa121td01", "panel-lvds";
-
-  width-mm = <261>;
-  height-mm = <163>;
-
-  data-mapping = "jeida-18";
-
-  panel-timing {
-/* 1280x800 @60Hz */
-clock-frequency = <7100>;
-hactive = <1280>;
-vactive = <800>;
-hsync-len = <70>;
-hfront-porch = <20>;
-hback-porch = <70>;
-vsync-len = <5>;
-vfront-porch = <3>;
-vback-porch = <15>;
-  };
-
-  port {
-panel_in: endpoint {
-  remote-endpoint = <_encoder>;
-};
-  };
-};
-
-...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-19-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 17/52] dt-bindings: display: aa121td01: Fix data-mapping

2021-09-01 Thread Maxime Ripard
The Mitsubishi AA121TD01 Device Tree Binding was requiring a
data-mapping property value which was set to another value in the
existing Device Trees. Fix this.

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 .../bindings/display/panel/mitsubishi,aa121td01.yaml  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml 
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
index b0f1d4eff12d..467a0ed4d444 100644
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
@@ -20,7 +20,7 @@ properties:
   - {} # panel-lvds, but not listed here to avoid false select
 
   data-mapping:
-const: jeida-24
+const: jeida-18
 
   width-mm:
 const: 261
@@ -44,7 +44,7 @@ examples:
   width-mm = <261>;
   height-mm = <163>;
 
-  data-mapping = "jeida-24";
+  data-mapping = "jeida-18";
 
   panel-timing {
 /* 1280x800 @60Hz */
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-18-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 16/52] dt-bindings: display: aa121td01: Remove unused vcc-supply

2021-09-01 Thread Maxime Ripard
The Mitsubishi AA121TD01 Device Tree Binding was requiring a vcc-supply
property. However, neither the existing device trees using that binding,
nor the driver were actually using that property which is also redundant
with power-supply. Let's just drop it.

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 .../bindings/display/panel/mitsubishi,aa121td01.yaml | 5 -
 1 file changed, 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml 
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
index 977c50a85b67..b0f1d4eff12d 100644
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
@@ -19,9 +19,6 @@ properties:
   - const: mitsubishi,aa121td01
   - {} # panel-lvds, but not listed here to avoid false select
 
-  vcc-supply:
-description: Reference to the regulator powering the panel VCC pins.
-
   data-mapping:
 const: jeida-24
 
@@ -38,13 +35,11 @@ additionalProperties: false
 
 required:
   - compatible
-  - vcc-supply
 
 examples:
   - |+
 panel {
   compatible = "mitsubishi,aa121td01", "panel-lvds";
-  vcc-supply = <_3v3>;
 
   width-mm = <261>;
   height-mm = <163>;
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-17-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 15/52] dt-bindings: display: Move aa104xd12 to panel-lvds

2021-09-01 Thread Maxime Ripard
The Mitsubishi AA104XD12 Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding
aside from a requirement on the data-mapping.

Let's move it to the generic panel-lvds binding

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 .../bindings/display/panel/lvds.yaml  | 12 
 .../display/panel/mitsubishi,aa104xd12.yaml   | 70 ---
 2 files changed, 12 insertions(+), 70 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml

diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 91a6d97a96e0..09a818a60f2e 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -28,6 +28,17 @@ description: |+
 
 allOf:
   - $ref: panel-common.yaml#
+  - if:
+  properties:
+compatible:
+  contains:
+const: mitsubishi,aa104xd12
+
+then:
+  properties:
+data-mapping:
+  const: jeida-18
+
   - if:
   properties:
 compatible:
@@ -60,6 +71,7 @@ properties:
   - advantech,idk-1110wr
   - advantech,idk-2121wr
   - innolux,ee101ia-01d
+  - mitsubishi,aa104xd12
   - const: panel-lvds
 
   data-mapping:
diff --git 
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml 
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
deleted file mode 100644
index 2d1c85e377cd..
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
+++ /dev/null
@@ -1,70 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2

-$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa104xd12.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Mitsubishi AA104XD12 10.4" XGA LVDS Display Panel
-
-maintainers:
-  - Laurent Pinchart 
-  - Thierry Reding 
-
-allOf:
-  - $ref: lvds.yaml#
-
-properties:
-  compatible:
-items:
-  - const: mitsubishi,aa104xd12
-  - {} # panel-lvds, but not listed here to avoid false select
-
-  data-mapping:
-const: jeida-18
-
-  width-mm:
-const: 210
-
-  height-mm:
-const: 158
-
-  panel-timing: true
-  port: true
-
-additionalProperties: false
-
-required:
-  - compatible
-
-examples:
-  - |+
-
-panel {
-  compatible = "mitsubishi,aa104xd12", "panel-lvds";
-
-  width-mm = <210>;
-  height-mm = <158>;
-
-  data-mapping = "jeida-18";
-
-  panel-timing {
-/* 1024x768 @65Hz */
-clock-frequency = <6500>;
-hactive = <1024>;
-vactive = <768>;
-hsync-len = <136>;
-hfront-porch = <20>;
-hback-porch = <160>;
-vfront-porch = <3>;
-vback-porch = <29>;
-vsync-len = <6>;
-  };
-
-  port {
-panel_in: endpoint {
-  remote-endpoint = <_encoder>;
-};
-  };
-};
-
-...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-16-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 14/52] dt-bindings: display: aa104xd12: Fix data-mapping

2021-09-01 Thread Maxime Ripard
The Mitsubishi AA140XD12 Device Tree Binding was requiring a
data-mapping property value which was set to another value in the
existing Device Trees. Fix this.

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 .../bindings/display/panel/mitsubishi,aa104xd12.yaml  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml 
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
index b595edd58bbb..2d1c85e377cd 100644
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
@@ -20,7 +20,7 @@ properties:
   - {} # panel-lvds, but not listed here to avoid false select
 
   data-mapping:
-const: jeida-24
+const: jeida-18
 
   width-mm:
 const: 210
@@ -45,7 +45,7 @@ examples:
   width-mm = <210>;
   height-mm = <158>;
 
-  data-mapping = "jeida-24";
+  data-mapping = "jeida-18";
 
   panel-timing {
 /* 1024x768 @65Hz */
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-15-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 13/52] dt-bindings: display: aa104xd12: Remove unused vcc-supply

2021-09-01 Thread Maxime Ripard
The Mitsubishi AA140XD12 Device Tree Binding was requiring a vcc-supply
property. However, neither the existing device trees using that binding,
nor the driver were actually using that property which is also redundant
with power-supply. Let's just drop it.

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 .../bindings/display/panel/mitsubishi,aa104xd12.yaml | 5 -
 1 file changed, 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml 
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
index b5e7ee230fa6..b595edd58bbb 100644
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
@@ -19,9 +19,6 @@ properties:
   - const: mitsubishi,aa104xd12
   - {} # panel-lvds, but not listed here to avoid false select
 
-  vcc-supply:
-description: Reference to the regulator powering the panel VCC pins.
-
   data-mapping:
 const: jeida-24
 
@@ -38,14 +35,12 @@ additionalProperties: false
 
 required:
   - compatible
-  - vcc-supply
 
 examples:
   - |+
 
 panel {
   compatible = "mitsubishi,aa104xd12", "panel-lvds";
-  vcc-supply = <_3v3>;
 
   width-mm = <210>;
   height-mm = <158>;
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-14-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 12/52] dt-bindings: display: Move ee101ia-01d to panel-lvds

2021-09-01 Thread Maxime Ripard
The Innolux EE101IA-01D Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding.
Let's move it to the generic panel-lvds binding

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 .../display/panel/innolux,ee101ia-01d.yaml| 31 ---
 .../bindings/display/panel/lvds.yaml  |  1 +
 2 files changed, 1 insertion(+), 31 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml 
b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
deleted file mode 100644
index a69681e724cb..
--- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
+++ /dev/null
@@ -1,31 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2

-$id: http://devicetree.org/schemas/display/panel/innolux,ee101ia-01d.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
-
-maintainers:
-  - Heiko Stuebner 
-  - Thierry Reding 
-
-allOf:
-  - $ref: lvds.yaml#
-
-properties:
-  compatible:
-items:
-  - const: innolux,ee101ia-01d
-  - {} # panel-lvds, but not listed here to avoid false select
-
-  backlight: true
-  enable-gpios: true
-  power-supply: true
-  width-mm: true
-  height-mm: true
-  panel-timing: true
-  port: true
-
-additionalProperties: false
-...
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 9b3b329e4e67..91a6d97a96e0 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -59,6 +59,7 @@ properties:
   - enum:
   - advantech,idk-1110wr
   - advantech,idk-2121wr
+  - innolux,ee101ia-01d
   - const: panel-lvds
 
   data-mapping:
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-13-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 11/52] dt-bindings: display: Move idk-2121wr to panel-lvds

2021-09-01 Thread Maxime Ripard
The Advantech IDK-2121WR Device Tree binding uses most of the panel-lvds
binding, aside from a requirement on the data-mapping and the
definition of the dual link binding.

The LVDS dual link binding applies to any panel with a dual-link setup,
and thus could be made generic, and we can move the data-mapping
requirement to a conditional.

Let's move it to the generic panel-lvds binding

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 .../display/panel/advantech,idk-2121wr.yaml   | 121 --
 .../bindings/display/panel/lvds.yaml  |  88 -
 2 files changed, 87 insertions(+), 122 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml 
b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
deleted file mode 100644
index 67682fe77f10..
--- a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
+++ /dev/null
@@ -1,121 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2

-$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel
-
-maintainers:
-  - Lad Prabhakar 
-  - Thierry Reding 
-
-description: |
-  The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel.
-  A dual-LVDS interface is a dual-link connection with even pixels traveling
-  on one link, and with odd pixels traveling on the other link.
-
-  The panel expects odd pixels on the first port, and even pixels on the
-  second port, therefore the ports must be marked accordingly (with either
-  dual-lvds-odd-pixels or dual-lvds-even-pixels).
-
-properties:
-  compatible:
-items:
-  - const: advantech,idk-2121wr
-  - {} # panel-lvds, but not listed here to avoid false select
-
-  width-mm:
-const: 476
-
-  height-mm:
-const: 268
-
-  data-mapping:
-const: vesa-24
-
-  panel-timing: true
-
-  ports:
-$ref: /schemas/graph.yaml#/properties/ports
-
-properties:
-  port@0:
-$ref: /schemas/graph.yaml#/$defs/port-base
-unevaluatedProperties: false
-description: The sink for odd pixels.
-properties:
-  dual-lvds-odd-pixels: true
-
-required:
-  - dual-lvds-odd-pixels
-
-  port@1:
-$ref: /schemas/graph.yaml#/$defs/port-base
-unevaluatedProperties: false
-description: The sink for even pixels.
-properties:
-  dual-lvds-even-pixels: true
-
-required:
-  - dual-lvds-even-pixels
-
-required:
-  - port@0
-  - port@1
-
-additionalProperties: false
-
-required:
-  - compatible
-  - width-mm
-  - height-mm
-  - data-mapping
-  - panel-timing
-  - ports
-
-examples:
-  - |+
-panel-lvds {
-  compatible = "advantech,idk-2121wr", "panel-lvds";
-
-  width-mm = <476>;
-  height-mm = <268>;
-
-  data-mapping = "vesa-24";
-
-  panel-timing {
-clock-frequency = <14850>;
-hactive = <1920>;
-vactive = <1080>;
-hsync-len = <44>;
-hfront-porch = <88>;
-hback-porch = <148>;
-vfront-porch = <4>;
-vback-porch = <36>;
-vsync-len = <5>;
-  };
-
-  ports {
-#address-cells = <1>;
-#size-cells = <0>;
-
-port@0 {
-  reg = <0>;
-  dual-lvds-odd-pixels;
-  panel_in0: endpoint {
-remote-endpoint = <_out>;
-  };
-};
-
-port@1 {
-  reg = <1>;
-  dual-lvds-even-pixels;
-  panel_in1: endpoint {
-remote-endpoint = <_out>;
-  };
-};
-  };
-};
-
-...
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index e4e49e06f302..9b3b329e4e67 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -39,11 +39,26 @@ allOf:
 data-mapping:
   const: jeida-24
 
+  - if:
+  properties:
+compatible:
+  contains:
+const: advantech,idk-2121wr
+
+then:
+  properties:
+data-mapping:
+  const: vesa-24
+
+  required:
+- ports
+
 properties:
   compatible:
 items:
   - enum:
   - advantech,idk-1110wr
+  - advantech,idk-2121wr
   - const: panel-lvds
 
   data-mapping:
@@ -105,7 +120,34 @@ properties:
   data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6.
 
   port: true
-  ports: true
+
+  ports:
+$ref: /schemas/graph.ya

[linux-sunxi] [PATCH v2 10/52] dt-bindings: display: Move idk-1110wr to panel-lvds

2021-09-01 Thread Maxime Ripard
The Advantech IDK-2121WR Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding
aside from a requirement on the data-mapping.

Let's move it to the generic panel-lvds binding

Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
Signed-off-by: Maxime Ripard 
---
 .../display/panel/advantech,idk-1110wr.yaml   | 69 ---
 .../bindings/display/panel/lvds.yaml  | 22 --
 2 files changed, 15 insertions(+), 76 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml 
b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
deleted file mode 100644
index 93878c2cd370..
--- a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
+++ /dev/null
@@ -1,69 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2

-$id: http://devicetree.org/schemas/display/panel/advantech,idk-1110wr.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Advantech IDK-1110WR 10.1" WSVGA LVDS Display Panel
-
-maintainers:
-  - Lad Prabhakar 
-  - Thierry Reding 
-
-allOf:
-  - $ref: lvds.yaml#
-
-properties:
-  compatible:
-items:
-  - const: advantech,idk-1110wr
-  - {} # panel-lvds, but not listed here to avoid false select
-
-  data-mapping:
-const: jeida-24
-
-  width-mm:
-const: 223
-
-  height-mm:
-const: 125
-
-  panel-timing: true
-  port: true
-
-additionalProperties: false
-
-required:
-  - compatible
-
-examples:
-  - |+
-panel {
-  compatible = "advantech,idk-1110wr", "panel-lvds";
-
-  width-mm = <223>;
-  height-mm = <125>;
-
-  data-mapping = "jeida-24";
-
-  panel-timing {
-/* 1024x600 @60Hz */
-clock-frequency = <5120>;
-hactive = <1024>;
-vactive = <600>;
-hsync-len = <240>;
-hfront-porch = <40>;
-hback-porch = <40>;
-vsync-len = <10>;
-vfront-porch = <15>;
-vback-porch = <10>;
-  };
-
-  port {
-panel_in: endpoint {
-  remote-endpoint = <_encoder>;
-};
-  };
-};
-
-...
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 49460c9dceea..e4e49e06f302 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -28,15 +28,23 @@ description: |+
 
 allOf:
   - $ref: panel-common.yaml#
+  - if:
+  properties:
+compatible:
+  contains:
+const: advantech,idk-1110wr
+
+then:
+  properties:
+data-mapping:
+  const: jeida-24
 
 properties:
   compatible:
-contains:
-  const: panel-lvds
-description:
-  Shall contain "panel-lvds" in addition to a mandatory panel-specific
-  compatible string defined in individual panel bindings. The "panel-lvds"
-  value shall never be used on its own.
+items:
+  - enum:
+  - advantech,idk-1110wr
+  - const: panel-lvds
 
   data-mapping:
 enum:
@@ -112,6 +120,6 @@ oneOf:
   - required:
   - ports
 
-additionalProperties: true
+unevaluatedProperties: false
 
 ...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-11-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 09/52] dt-bindings: clocks: Fix typo in the H6 compatible

2021-09-01 Thread Maxime Ripard
Even though both the driver and the device trees all use the
allwinner,sun50i-h6-de3-clk, we documented the compatible as
allwinner,sun50i-h6-de2-clk in the binding. Let's fix this.

Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml 
b/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml
index 3f995d2b30eb..e79eeac5f086 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml
@@ -24,7 +24,7 @@ properties:
   - const: allwinner,sun8i-v3s-de2-clk
   - const: allwinner,sun50i-a64-de2-clk
   - const: allwinner,sun50i-h5-de2-clk
-  - const: allwinner,sun50i-h6-de2-clk
+  - const: allwinner,sun50i-h6-de3-clk
   - items:
   - const: allwinner,sun8i-r40-de2-clk
   - const: allwinner,sun8i-h3-de2-clk
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-10-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 08/52] dt-bindings: bluetooth: realtek: Add missing max-speed

2021-09-01 Thread Maxime Ripard
additionalProperties prevent any property not explicitly defined in the
binding to be used. Yet, some serial properties like max-speed are valid
and validated through the serial/serial.yaml binding.

Even though the ideal solution would be to use unevaluatedProperties
instead, it's not pratical due to the way the bus bindings have been
described. Let's add max-speed to remove the warning.

Cc: Alistair Francis 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: net...@vger.kernel.org
Cc: Vasily Khoruzhick 
Reviewed-by: Alistair Francis 
Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/net/realtek-bluetooth.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml 
b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml
index 0634e69dd9a6..157d606bf9cb 100644
--- a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml
@@ -34,6 +34,8 @@ properties:
 maxItems: 1
 description: GPIO specifier, used to wakeup the host processor
 
+  max-speed: true
+
 required:
   - compatible
 
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-9-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 07/52] dt-bindings: bluetooth: broadcom: Fix clocks check

2021-09-01 Thread Maxime Ripard
The original binding was mentioning that valid values for the clocks and
clock-names property were one or two clocks from extclk, txco and lpo,
with extclk being deprecated in favor of txco.

However, the current binding lists a valid array as extclk, txco and
lpo, with either one or two items.

While this looks similar, it actually enforces that all the device trees
use either ["extclk"], or ["extclk", "txco"]. That doesn't make much
sense, since the two clocks are said to be equivalent, with one
superseeding the other.

lpo is also not a valid clock anymore, and would be as the third clock
of the list, while we could have only this clock in the previous binding
(and in DTs).

Let's rework the clock clause to allow to have either:

 - extclk, and mark it a deprecated
 - txco alone
 - lpo alone
 - txco, lpo

While ["extclk", "lpo"] wouldn't be valid, it wasn't found in any device
tree so it's not an issue in practice.

Similarly, ["lpo", "txco"] is still considered invalid, but it's
generally considered as a best practice to fix the order of clocks.

Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Linus Walleij 
Cc: net...@vger.kernel.org
Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 .../bindings/net/broadcom-bluetooth.yaml| 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml 
b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
index fbdc2083bec4..5aac094fd217 100644
--- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
@@ -50,16 +50,29 @@ properties:
   by interrupts and "host-wakeup" interrupt-names
 
   clocks:
+minItems: 1
 maxItems: 2
 description: 1 or 2 clocks as defined in clock-names below,
   in that order
 
   clock-names:
 description: Names of the 1 to 2 supplied clocks
-items:
+oneOf:
+  - const: extclk
+deprecated: true
+description: Deprecated in favor of txco
+
   - const: txco
+description: >
+  external reference clock (not a standalone crystal)
+
   - const: lpo
-  - const: extclk
+description: >
+  external low power 32.768 kHz clock
+
+  - items:
+  - const: txco
+  - const: lpo
 
   vbat-supply:
 description: phandle to regulator supply for VBAT
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-8-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 06/52] dt-bindings: arm: Convert ARM CCI-400 binding to a schema

2021-09-01 Thread Maxime Ripard
The ARM CCI-400 Interconnect is supported by Linux thanks to its device
tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: Lorenzo Pieralisi 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Reduced the max number of interrupts
  - Comented the pl330 compatible to avoid a warning
  - Added cci-control-port to the cpus schemas
---
 .../devicetree/bindings/arm/arm,cci-400.yaml  | 216 +
 .../bindings/arm/cci-control-port.yaml|  38 +++
 Documentation/devicetree/bindings/arm/cci.txt | 224 --
 .../devicetree/bindings/arm/cpus.yaml |   2 +
 4 files changed, 256 insertions(+), 224 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/arm,cci-400.yaml
 create mode 100644 Documentation/devicetree/bindings/arm/cci-control-port.yaml
 delete mode 100644 Documentation/devicetree/bindings/arm/cci.txt

diff --git a/Documentation/devicetree/bindings/arm/arm,cci-400.yaml 
b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml
new file mode 100644
index ..4682f991a5c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml
@@ -0,0 +1,216 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,cci-400.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM CCI Cache Coherent Interconnect Device Tree Binding
+
+maintainers:
+  - Lorenzo Pieralisi 
+
+description: >
+  ARM multi-cluster systems maintain intra-cluster coherency through a cache
+  coherent interconnect (CCI) that is capable of monitoring bus transactions
+  and manage coherency, TLB invalidations and memory barriers.
+
+  It allows snooping and distributed virtual memory message broadcast across
+  clusters, through memory mapped interface, with a global control register
+  space and multiple sets of interface control registers, one per slave
+  interface.
+
+properties:
+  $nodename:
+pattern: "^cci(@[0-9a-f]+)?$"
+
+  compatible:
+enum:
+  - arm,cci-400
+  - arm,cci-500
+  - arm,cci-550
+
+  reg:
+maxItems: 1
+description: >
+  Specifies base physical address of CCI control registers common to all
+  interfaces.
+
+  "#address-cells": true
+  "#size-cells": true
+  ranges: true
+
+patternProperties:
+  "^slave-if@[0-9a-f]+$":
+type: object
+
+properties:
+  compatible:
+const: arm,cci-400-ctrl-if
+
+  interface-type:
+enum:
+  - ace
+  - ace-lite
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - interface-type
+  - reg
+
+additionalProperties: false
+
+  "^pmu@[0-9a-f]+$":
+type: object
+
+properties:
+  compatible:
+oneOf:
+  - const: arm,cci-400-pmu,r0
+  - const: arm,cci-400-pmu,r1
+  - const: arm,cci-400-pmu
+deprecated: true
+description: >
+  Permitted only where OS has secure access to CCI registers
+  - const: arm,cci-500-pmu,r0
+  - const: arm,cci-550-pmu,r0
+
+  interrupts:
+minItems: 1
+maxItems: 8
+description: >
+  List of counter overflow interrupts, one per counter. The interrupts
+  must be specified starting with the cycle counter overflow interrupt,
+  followed by counter0 overflow interrupt, counter1 overflow
+  interrupt,...  ,counterN overflow interrupt.
+
+  The CCI PMU has an interrupt signal for each counter. The number of
+  interrupts must be equal to the number of counters.
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - interrupts
+  - reg
+
+additionalProperties: false
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - compatible
+  - ranges
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+  / {
+  #address-cells = <2>;
+  #size-cells = <2>;
+
+  compatible = "arm,vexpress,v2p-ca15_a7", "arm,vexpress";
+  model = "V2P-CA15_CA7";
+  arm,hbi = <0x249>;
+  interrupt-parent = <>;
+
+  /*
+   * This CCI node corresponds to a CCI component whose control
+   * registers sits at address 0x2c09.
+   *
+   * CCI slave interface @0x2c091000 is connected to dma
+   * controller dma0.
+   *
+   * CCI slave interface @0x2c094000 is connected to CPUs
+   * {CPU0, CPU1};
+   *
+   * CCI slave interface @0x2c095000 is connected to CPUs
+   * {CPU2, CPU3};
+   */
+
+  cpus {
+  #size-cells = <0>;
+  #address-cells = <1>;
+
+  CPU0: cpu@0 {
+  dev

[linux-sunxi] [PATCH v2 05/52] dt-bindings: Convert Reserved Memory binding to a schema

2021-09-01 Thread Maxime Ripard
The Reserved Memory mechanism is supported by Linux thanks to its device
tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: Mailing List 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Fixed the license
  - Added a mention that the file has moved
  - Added a documentation for memory-region
  - Split the reserved-memory binding in two: one for the generic part
and one for shared-dma-pool
---
 .../reserved-memory/memory-region.yaml|  40 
 .../reserved-memory/reserved-memory.txt   | 172 +-
 .../reserved-memory/reserved-memory.yaml  |  96 ++
 .../reserved-memory/shared-dma-pool.yaml  |  87 +
 4 files changed, 224 insertions(+), 171 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
 create mode 100644 
Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
 create mode 100644 
Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml

diff --git 
a/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml 
b/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
new file mode 100644
index ..3f93d9f5aa2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/memory-region.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Reserved Memory Region Device Tree Binding
+
+maintainers:
+  - Devicetree Specification Mailing List 
+
+description: |
+  Regions in the /reserved-memory node may be referenced by other device
+  nodes by adding a memory-region property to the device node.
+
+select: true
+
+properties:
+  memory-region:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: >
+  Phandle to a /reserved-memory child node assigned to the device.
+
+  memory-region-names:
+$ref: /schemas/types.yaml#/definitions/string-array
+description: >
+  A list of names, one for each corresponding entry in the
+  memory-region property
+
+additionalProperties: true
+
+examples:
+  - |
+fb0: video@1230 {
+/* ... */
+reg = <0x1230 0x1000>;
+memory-region = <_reserved>;
+};
+
+...
diff --git 
a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index 39b5f4c5a511..1810701a8509 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -1,171 +1 @@
-*** Reserved memory regions ***
-
-Reserved memory is specified as a node under the /reserved-memory node.
-The operating system shall exclude reserved memory from normal usage
-one can create child nodes describing particular reserved (excluded from
-normal use) memory regions. Such memory regions are usually designed for
-the special usage by various device drivers.
-
-Parameters for each memory region can be encoded into the device tree
-with the following nodes:
-
-/reserved-memory node
--
-#address-cells, #size-cells (required) - standard definition
-- Should use the same values as the root node
-ranges (required) - standard definition
-- Should be empty
-
-/reserved-memory/ child nodes
--
-Each child of the reserved-memory node specifies one or more regions of
-reserved memory. Each child node may either use a 'reg' property to
-specify a specific range of reserved memory, or a 'size' property with
-optional constraints to request a dynamically allocated block of memory.
-
-Following the generic-names recommended practice, node names should
-reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
-address (@) should be appended to the name if the node is a
-static allocation.
-
-Properties:
-Requires either a) or b) below.
-a) static allocation
-   reg (required) - standard definition
-b) dynamic allocation
-   size (required) - length based on parent's #size-cells
-   - Size in bytes of memory to reserve.
-   alignment (optional) - length based on parent's #size-cells
-- Address boundary for alignment of allocation.
-   alloc-ranges (optional) - prop-encoded-array (address, length pairs).
-   - Specifies regions of memory that are
- acceptable to allocate from.
-
-If both reg and size are present, then the reg property takes precedence
-and size is ignored.
-
-Additional properties:
-compatible (optional) - standard definition
-- may contain the following strings:
-- shared-dma-pool: This indicates a region of memory meant 

[linux-sunxi] [PATCH v2 04/52] ASoC: dt-bindings: Convert Simple Amplifier binding to a schema

2021-09-01 Thread Maxime Ripard
Simple audio amplifiers are supported by Linux with a matching device
tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: alsa-de...@alsa-project.org
Cc: Jerome Brunet 
Cc: Liam Girdwood 
Cc: Mark Brown 
Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 .../bindings/sound/simple-amplifier.txt   | 17 ---
 .../sound/simple-audio-amplifier.yaml | 45 +++
 2 files changed, 45 insertions(+), 17 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/sound/simple-amplifier.txt
 create mode 100644 
Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml

diff --git a/Documentation/devicetree/bindings/sound/simple-amplifier.txt 
b/Documentation/devicetree/bindings/sound/simple-amplifier.txt
deleted file mode 100644
index b1b097cc9b68..
--- a/Documentation/devicetree/bindings/sound/simple-amplifier.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Simple Amplifier Audio Driver
-
-Required properties:
-- compatible : "dioo,dio2125" or "simple-audio-amplifier"
-
-Optional properties:
-- enable-gpios : the gpio connected to the enable pin of the simple amplifier
-- VCC-supply   : power supply for the device, as covered
- in Documentation/devicetree/bindings/regulator/regulator.txt
-
-Example:
-
-amp: analog-amplifier {
-   compatible = "simple-audio-amplifier";
-   VCC-supply = <>;
-   enable-gpios = < GPIOH_3 0>;
-};
diff --git 
a/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml 
b/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml
new file mode 100644
index ..26379377a7ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/simple-audio-amplifier.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Simple Audio Amplifier Device Tree Bindings
+
+maintainers:
+  - Jerome Brunet 
+
+properties:
+  compatible:
+enum:
+  - dioo,dio2125
+  - simple-audio-amplifier
+
+  enable-gpios:
+maxItems: 1
+
+  VCC-supply:
+description: >
+  power supply for the device
+
+  sound-name-prefix:
+$ref: /schemas/types.yaml#/definitions/string
+description: >
+  See ./name-prefix.txt
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+analog-amplifier {
+compatible = "simple-audio-amplifier";
+VCC-supply = <>;
+enable-gpios = < GPIOH_3 0>;
+};
+
+...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-5-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 03/52] ASoC: dt-bindings: Convert SPDIF Transmitter binding to a schema

2021-09-01 Thread Maxime Ripard
The SPDIF Transmitter binding is used by Linux with a matching Device
Tree binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: alsa-de...@alsa-project.org
Cc: Liam Girdwood 
Cc: Mark Brown 
Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 
---
 .../bindings/sound/linux,spdif-dit.yaml   | 32 +++
 .../bindings/sound/spdif-transmitter.txt  | 10 --
 2 files changed, 32 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml
 delete mode 100644 
Documentation/devicetree/bindings/sound/spdif-transmitter.txt

diff --git a/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml 
b/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml
new file mode 100644
index ..c6b070e1d014
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/linux,spdif-dit.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dummy SPDIF Transmitter Device Tree Bindings
+
+maintainers:
+  - Mark Brown 
+
+properties:
+  compatible:
+const: linux,spdif-dit
+
+  "#sound-dai-cells":
+const: 0
+
+required:
+  - "#sound-dai-cells"
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+spdif-out {
+#sound-dai-cells = <0>;
+compatible = "linux,spdif-dit";
+};
+
+...
diff --git a/Documentation/devicetree/bindings/sound/spdif-transmitter.txt 
b/Documentation/devicetree/bindings/sound/spdif-transmitter.txt
deleted file mode 100644
index 55a85841dd85..
--- a/Documentation/devicetree/bindings/sound/spdif-transmitter.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Device-Tree bindings for dummy spdif transmitter
-
-Required properties:
-   - compatible: should be "linux,spdif-dit".
-
-Example node:
-
-   codec: spdif-transmitter {
-   compatible = "linux,spdif-dit";
-   };
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-4-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 02/52] ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema

2021-09-01 Thread Maxime Ripard
Bluetooth SCO Link are supported by Linux with a matching device tree
binding.

Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.

Cc: alsa-de...@alsa-project.org
Cc: devicet...@vger.kernel.org
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Samuel Holland 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Accept either a 0 or 1 #sound-dai-cells
---
 .../devicetree/bindings/sound/bt-sco.txt  | 13 ---
 .../bindings/sound/linux,bt-sco.yaml  | 38 +++
 2 files changed, 38 insertions(+), 13 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt
 create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml

diff --git a/Documentation/devicetree/bindings/sound/bt-sco.txt 
b/Documentation/devicetree/bindings/sound/bt-sco.txt
deleted file mode 100644
index 641edf75e184..
--- a/Documentation/devicetree/bindings/sound/bt-sco.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-Bluetooth-SCO audio CODEC
-
-This device support generic Bluetooth SCO link.
-
-Required properties:
-
-  - compatible : "delta,dfbmcs320" or "linux,bt-sco"
-
-Example:
-
-codec: bt_sco {
-   compatible = "delta,dfbmcs320";
-};
diff --git a/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml 
b/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
new file mode 100644
index ..e3a1f485f664
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/linux,bt-sco.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bluetooth SCO Audio Codec Device Tree Bindings
+
+maintainers:
+  - Mark Brown 
+
+properties:
+  '#sound-dai-cells':
+enum:
+  - 0
+
+  # For Wideband PCM
+  - 1
+
+  compatible:
+enum:
+  - delta,dfbmcs320
+  - linux,bt-sco
+
+required:
+  - '#sound-dai-cells'
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+codec {
+#sound-dai-cells = <0>;
+compatible = "linux,bt-sco";
+};
+
+...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-3-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding

2021-09-01 Thread Maxime Ripard
Even though we had the wm8978 driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.

Cc: alsa-de...@alsa-project.org
Cc: devicet...@vger.kernel.org
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: patc...@opensource.cirrus.com
Reviewed-by: Rob Herring 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Changed the maintainers of the bindings
---
 .../devicetree/bindings/sound/wlf,wm8978.yaml | 58 +++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8978.yaml

diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml 
b/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml
new file mode 100644
index ..944e5859c962
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/wlf,wm8978.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wolfson WM8978 Codec Device Tree Bindings
+
+maintainers:
+  - patc...@opensource.cirrus.com
+
+properties:
+  '#sound-dai-cells':
+const: 0
+
+  compatible:
+const: wlf,wm8978
+
+  reg:
+maxItems: 1
+
+  spi-max-frequency:
+maximum: 526000
+
+required:
+  - '#sound-dai-cells'
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+codec@0 {
+#sound-dai-cells = <0>;
+compatible = "wlf,wm8978";
+reg = <0>;
+spi-max-frequency = <50>;
+};
+};
+
+  - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+codec@0 {
+#sound-dai-cells = <0>;
+compatible = "wlf,wm8978";
+reg = <0>;
+};
+};
+
+...
-- 
2.31.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210901091852.479202-2-maxime%40cerno.tech.


[linux-sunxi] [PATCH v2 00/52] ARM: dts: Last round of DT schema fixes

2021-09-01 Thread Maxime Ripard
Hi,



Here's another round of schema warnings fixes for the Allwinner platform.



There's a fair share of new schemas in there since the schema tools now warn

when a compatible is not documented in a schema.



We don't have any warning anymore if we use the OPP binding Rob submitted, and

since that means we have all our devices properly validated I don't expect more

fixes now, aside from the usual bunch of regressions.



Let me know what you think,

Maxime



Maxime Ripard (52):

  ASoC: dt-bindings: Add WM8978 Binding

  ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema

  ASoC: dt-bindings: Convert SPDIF Transmitter binding to a schema

  ASoC: dt-bindings: Convert Simple Amplifier binding to a schema

  dt-bindings: Convert Reserved Memory binding to a schema

  dt-bindings: arm: Convert ARM CCI-400 binding to a schema

  dt-bindings: bluetooth: broadcom: Fix clocks check

  dt-bindings: bluetooth: realtek: Add missing max-speed

  dt-bindings: clocks: Fix typo in the H6 compatible

  dt-bindings: display: Move idk-1110wr to panel-lvds

  dt-bindings: display: Move idk-2121wr to panel-lvds

  dt-bindings: display: Move ee101ia-01d to panel-lvds

  dt-bindings: display: aa104xd12: Remove unused vcc-supply

  dt-bindings: display: aa104xd12: Fix data-mapping

  dt-bindings: display: Move aa104xd12 to panel-lvds

  dt-bindings: display: aa121td01: Remove unused vcc-supply

  dt-bindings: display: aa121td01: Fix data-mapping

  dt-bindings: display: Move aa121td01 to panel-lvds

  dt-bindings: display: Move gktw70sdae4se to panel-lvds

  dt-bindings: display: panel-lvds: Document missing panel compatibles

  dt-bindings: gnss: Convert UBlox Neo-6M binding to a schema

  dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema

  dt-bindings: hwmon: Add IIO HWMON binding

  dt-bindings: input: Convert Silead GSL1680 binding to a schema

  dt-bindings: interconnect: sunxi: Add R40 MBUS compatible

  dt-bindings: media: ti,cal: Fix example

  dt-bindings: media: Convert OV5640 binding to a schema

  dt-bindings: mfd: Convert X-Powers AC100 binding to a schema

  dt-bindings: mfd: Convert X-Powers AXP binding to a schema

  dt-bindings: mmc: Convert MMC Card binding to a schema

  dt-bindings: net: dwmac: Fix typo in the R40 compatible

  dt-bindings: net: wireless: Convert ESP ESP8089 binding to a schema

  dt-bindings: regulator: Convert SY8106A binding to a schema

  dt-bindings: sunxi: Add CPU Configuration Controller Binding

  dt-bindings: sunxi: Add Allwinner A80 PRCM Binding

  dt-bindings: usb: Convert SMSC USB3503 binding to a schema

  dt-bindings: usb: dwc3: Fix usb-phy check

  dt-bindings: w1: Convert 1-Wire GPIO binding to a schema

  ARM: dts: sunxi: Rename power-supply names

  ARM: dts: sunxi: Rename gpio pinctrl names

  ARM: dts: sunxi: Fix OPP arrays

  ARM: dts: sunxi: Fix OPPs node name

  ARM: dts: sunxi: Fix the SPI NOR node names

  ARM: dts: v3s: Remove useless DMA properties

  ARM: dts: tbs711: Fix touchscreen compatible

  ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible

  arm64: dts: allwinner: h5: Fix GPU thermal zone node name

  arm64: dts: allwinner: h6: Fix de3 parent clocks ordering

  arm64: dts: allwinner: a100: Fix thermal zone node name

  arm64: dts: allwinner: pinetab: Change regulator node name to avoid

warning

  arm64: dts: allwinner: teres-i: Add missing reg

  arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC



 .../devicetree/bindings/arm/arm,cci-400.yaml  | 216 ++

 .../bindings/arm/cci-control-port.yaml|  38 ++

 Documentation/devicetree/bindings/arm/cci.txt | 224 --

 .../devicetree/bindings/arm/cpus.yaml |   2 +

 .../arm/sunxi/allwinner,sun4i-a10-mbus.yaml   |   1 +

 .../sunxi/allwinner,sun6i-a31-cpuconfig.yaml  |  38 ++

 .../arm/sunxi/allwinner,sun9i-a80-prcm.yaml   |  33 ++

 .../clock/allwinner,sun8i-a83t-de2-clk.yaml   |   2 +-

 .../display/panel/advantech,idk-1110wr.yaml   |  69 ---

 .../display/panel/advantech,idk-2121wr.yaml   | 121 --

 .../display/panel/innolux,ee101ia-01d.yaml|  31 --

 .../bindings/display/panel/lvds.yaml  | 130 +-

 .../display/panel/mitsubishi,aa104xd12.yaml   |  75 

 .../display/panel/mitsubishi,aa121td01.yaml   |  74 

 .../display/panel/sgd,gktw70sdae4se.yaml  |  68 ---

 .../bindings/gnss/u-blox,neo-6m.yaml  |  62 +++

 .../devicetree/bindings/gnss/u-blox.txt   |  45 --

 .../devicetree/bindings/gpio/gpio-axp209.txt  |  75 

 .../bindings/gpio/x-powers,axp209-gpio.yaml   |  55 +++

 .../devicetree/bindings/hwmon/iio-hwmon.yaml  |  37 ++

 .../i2c/allwinner,sun6i-a31-p2wi.yaml |   2 +-

 .../input/touchscreen/silead,gsl1680.yaml |  91 

 .../input/touchscreen/silead_gsl1680.txt  |  44 --

 .../devicetree/bindings/media/i2c/ov5640.txt  |  92 

 .../bindings/media/i2c/ovti,ov5640.yaml   | 154 +++

 .../devicetree/bindings/media/ti,cal.yaml

[linux-sunxi] [PATCH v2 00/52] ARM: dts: Last round of DT schema fixes

2021-09-01 Thread Maxime Ripard
Hi,



Here's another round of schema warnings fixes for the Allwinner platform.



There's a fair share of new schemas in there since the schema tools now warn

when a compatible is not documented in a schema.



We don't have any warning anymore if we use the OPP binding Rob submitted, and

since that means we have all our devices properly validated I don't expect more

fixes now, aside from the usual bunch of regressions.



Let me know what you think,

Maxime



Maxime Ripard (52):

  ASoC: dt-bindings: Add WM8978 Binding

  ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema

  ASoC: dt-bindings: Convert SPDIF Transmitter binding to a schema

  ASoC: dt-bindings: Convert Simple Amplifier binding to a schema

  dt-bindings: Convert Reserved Memory binding to a schema

  dt-bindings: arm: Convert ARM CCI-400 binding to a schema

  dt-bindings: bluetooth: broadcom: Fix clocks check

  dt-bindings: bluetooth: realtek: Add missing max-speed

  dt-bindings: clocks: Fix typo in the H6 compatible

  dt-bindings: display: Move idk-1110wr to panel-lvds

  dt-bindings: display: Move idk-2121wr to panel-lvds

  dt-bindings: display: Move ee101ia-01d to panel-lvds

  dt-bindings: display: aa104xd12: Remove unused vcc-supply

  dt-bindings: display: aa104xd12: Fix data-mapping

  dt-bindings: display: Move aa104xd12 to panel-lvds

  dt-bindings: display: aa121td01: Remove unused vcc-supply

  dt-bindings: display: aa121td01: Fix data-mapping

  dt-bindings: display: Move aa121td01 to panel-lvds

  dt-bindings: display: Move gktw70sdae4se to panel-lvds

  dt-bindings: display: panel-lvds: Document missing panel compatibles

  dt-bindings: gnss: Convert UBlox Neo-6M binding to a schema

  dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema

  dt-bindings: hwmon: Add IIO HWMON binding

  dt-bindings: input: Convert Silead GSL1680 binding to a schema

  dt-bindings: interconnect: sunxi: Add R40 MBUS compatible

  dt-bindings: media: ti,cal: Fix example

  dt-bindings: media: Convert OV5640 binding to a schema

  dt-bindings: mfd: Convert X-Powers AC100 binding to a schema

  dt-bindings: mfd: Convert X-Powers AXP binding to a schema

  dt-bindings: mmc: Convert MMC Card binding to a schema

  dt-bindings: net: dwmac: Fix typo in the R40 compatible

  dt-bindings: net: wireless: Convert ESP ESP8089 binding to a schema

  dt-bindings: regulator: Convert SY8106A binding to a schema

  dt-bindings: sunxi: Add CPU Configuration Controller Binding

  dt-bindings: sunxi: Add Allwinner A80 PRCM Binding

  dt-bindings: usb: Convert SMSC USB3503 binding to a schema

  dt-bindings: usb: dwc3: Fix usb-phy check

  dt-bindings: w1: Convert 1-Wire GPIO binding to a schema

  ARM: dts: sunxi: Rename power-supply names

  ARM: dts: sunxi: Rename gpio pinctrl names

  ARM: dts: sunxi: Fix OPP arrays

  ARM: dts: sunxi: Fix OPPs node name

  ARM: dts: sunxi: Fix the SPI NOR node names

  ARM: dts: v3s: Remove useless DMA properties

  ARM: dts: tbs711: Fix touchscreen compatible

  ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible

  arm64: dts: allwinner: h5: Fix GPU thermal zone node name

  arm64: dts: allwinner: h6: Fix de3 parent clocks ordering

  arm64: dts: allwinner: a100: Fix thermal zone node name

  arm64: dts: allwinner: pinetab: Change regulator node name to avoid

warning

  arm64: dts: allwinner: teres-i: Add missing reg

  arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC



 .../devicetree/bindings/arm/arm,cci-400.yaml  | 216 ++

 .../bindings/arm/cci-control-port.yaml|  38 ++

 Documentation/devicetree/bindings/arm/cci.txt | 224 --

 .../devicetree/bindings/arm/cpus.yaml |   2 +

 .../arm/sunxi/allwinner,sun4i-a10-mbus.yaml   |   1 +

 .../sunxi/allwinner,sun6i-a31-cpuconfig.yaml  |  38 ++

 .../arm/sunxi/allwinner,sun9i-a80-prcm.yaml   |  33 ++

 .../clock/allwinner,sun8i-a83t-de2-clk.yaml   |   2 +-

 .../display/panel/advantech,idk-1110wr.yaml   |  69 ---

 .../display/panel/advantech,idk-2121wr.yaml   | 121 --

 .../display/panel/innolux,ee101ia-01d.yaml|  31 --

 .../bindings/display/panel/lvds.yaml  | 130 +-

 .../display/panel/mitsubishi,aa104xd12.yaml   |  75 

 .../display/panel/mitsubishi,aa121td01.yaml   |  74 

 .../display/panel/sgd,gktw70sdae4se.yaml  |  68 ---

 .../bindings/gnss/u-blox,neo-6m.yaml  |  62 +++

 .../devicetree/bindings/gnss/u-blox.txt   |  45 --

 .../devicetree/bindings/gpio/gpio-axp209.txt  |  75 

 .../bindings/gpio/x-powers,axp209-gpio.yaml   |  55 +++

 .../devicetree/bindings/hwmon/iio-hwmon.yaml  |  37 ++

 .../i2c/allwinner,sun6i-a31-p2wi.yaml |   2 +-

 .../input/touchscreen/silead,gsl1680.yaml |  91 

 .../input/touchscreen/silead_gsl1680.txt  |  44 --

 .../devicetree/bindings/media/i2c/ov5640.txt  |  92 

 .../bindings/media/i2c/ovti,ov5640.yaml   | 154 +++

 .../devicetree/bindings/media/ti,cal.yaml

[linux-sunxi] [PATCH v2 00/52] ARM: dts: Last round of DT schema fixes

2021-09-01 Thread Maxime Ripard
Hi,



Here's another round of schema warnings fixes for the Allwinner platform.



There's a fair share of new schemas in there since the schema tools now warn

when a compatible is not documented in a schema.



We don't have any warning anymore if we use the OPP binding Rob submitted, and

since that means we have all our devices properly validated I don't expect more

fixes now, aside from the usual bunch of regressions.



Let me know what you think,

Maxime



Maxime Ripard (52):

  ASoC: dt-bindings: Add WM8978 Binding

  ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema

  ASoC: dt-bindings: Convert SPDIF Transmitter binding to a schema

  ASoC: dt-bindings: Convert Simple Amplifier binding to a schema

  dt-bindings: Convert Reserved Memory binding to a schema

  dt-bindings: arm: Convert ARM CCI-400 binding to a schema

  dt-bindings: bluetooth: broadcom: Fix clocks check

  dt-bindings: bluetooth: realtek: Add missing max-speed

  dt-bindings: clocks: Fix typo in the H6 compatible

  dt-bindings: display: Move idk-1110wr to panel-lvds

  dt-bindings: display: Move idk-2121wr to panel-lvds

  dt-bindings: display: Move ee101ia-01d to panel-lvds

  dt-bindings: display: aa104xd12: Remove unused vcc-supply

  dt-bindings: display: aa104xd12: Fix data-mapping

  dt-bindings: display: Move aa104xd12 to panel-lvds

  dt-bindings: display: aa121td01: Remove unused vcc-supply

  dt-bindings: display: aa121td01: Fix data-mapping

  dt-bindings: display: Move aa121td01 to panel-lvds

  dt-bindings: display: Move gktw70sdae4se to panel-lvds

  dt-bindings: display: panel-lvds: Document missing panel compatibles

  dt-bindings: gnss: Convert UBlox Neo-6M binding to a schema

  dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema

  dt-bindings: hwmon: Add IIO HWMON binding

  dt-bindings: input: Convert Silead GSL1680 binding to a schema

  dt-bindings: interconnect: sunxi: Add R40 MBUS compatible

  dt-bindings: media: ti,cal: Fix example

  dt-bindings: media: Convert OV5640 binding to a schema

  dt-bindings: mfd: Convert X-Powers AC100 binding to a schema

  dt-bindings: mfd: Convert X-Powers AXP binding to a schema

  dt-bindings: mmc: Convert MMC Card binding to a schema

  dt-bindings: net: dwmac: Fix typo in the R40 compatible

  dt-bindings: net: wireless: Convert ESP ESP8089 binding to a schema

  dt-bindings: regulator: Convert SY8106A binding to a schema

  dt-bindings: sunxi: Add CPU Configuration Controller Binding

  dt-bindings: sunxi: Add Allwinner A80 PRCM Binding

  dt-bindings: usb: Convert SMSC USB3503 binding to a schema

  dt-bindings: usb: dwc3: Fix usb-phy check

  dt-bindings: w1: Convert 1-Wire GPIO binding to a schema

  ARM: dts: sunxi: Rename power-supply names

  ARM: dts: sunxi: Rename gpio pinctrl names

  ARM: dts: sunxi: Fix OPP arrays

  ARM: dts: sunxi: Fix OPPs node name

  ARM: dts: sunxi: Fix the SPI NOR node names

  ARM: dts: v3s: Remove useless DMA properties

  ARM: dts: tbs711: Fix touchscreen compatible

  ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible

  arm64: dts: allwinner: h5: Fix GPU thermal zone node name

  arm64: dts: allwinner: h6: Fix de3 parent clocks ordering

  arm64: dts: allwinner: a100: Fix thermal zone node name

  arm64: dts: allwinner: pinetab: Change regulator node name to avoid

warning

  arm64: dts: allwinner: teres-i: Add missing reg

  arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC



 .../devicetree/bindings/arm/arm,cci-400.yaml  | 216 ++

 .../bindings/arm/cci-control-port.yaml|  38 ++

 Documentation/devicetree/bindings/arm/cci.txt | 224 --

 .../devicetree/bindings/arm/cpus.yaml |   2 +

 .../arm/sunxi/allwinner,sun4i-a10-mbus.yaml   |   1 +

 .../sunxi/allwinner,sun6i-a31-cpuconfig.yaml  |  38 ++

 .../arm/sunxi/allwinner,sun9i-a80-prcm.yaml   |  33 ++

 .../clock/allwinner,sun8i-a83t-de2-clk.yaml   |   2 +-

 .../display/panel/advantech,idk-1110wr.yaml   |  69 ---

 .../display/panel/advantech,idk-2121wr.yaml   | 121 --

 .../display/panel/innolux,ee101ia-01d.yaml|  31 --

 .../bindings/display/panel/lvds.yaml  | 130 +-

 .../display/panel/mitsubishi,aa104xd12.yaml   |  75 

 .../display/panel/mitsubishi,aa121td01.yaml   |  74 

 .../display/panel/sgd,gktw70sdae4se.yaml  |  68 ---

 .../bindings/gnss/u-blox,neo-6m.yaml  |  62 +++

 .../devicetree/bindings/gnss/u-blox.txt   |  45 --

 .../devicetree/bindings/gpio/gpio-axp209.txt  |  75 

 .../bindings/gpio/x-powers,axp209-gpio.yaml   |  55 +++

 .../devicetree/bindings/hwmon/iio-hwmon.yaml  |  37 ++

 .../i2c/allwinner,sun6i-a31-p2wi.yaml |   2 +-

 .../input/touchscreen/silead,gsl1680.yaml |  91 

 .../input/touchscreen/silead_gsl1680.txt  |  44 --

 .../devicetree/bindings/media/i2c/ov5640.txt  |  92 

 .../bindings/media/i2c/ovti,ov5640.yaml   | 154 +++

 .../devicetree/bindings/media/ti,cal.yaml

[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

2021-09-01 Thread Maxime Ripard
On Wed, Aug 18, 2021 at 10:04:07AM +0100, Andre Przywara wrote:
> On Tue, 17 Aug 2021 09:38:10 +0200
> Maxime Ripard  wrote:
> 
> Hi Maxime,
> 
> > On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
> > > On Mon, 26 Jul 2021 16:41:37 +0200
> > > Maxime Ripard  wrote:
> > >   
> > > > Hi,
> > > > 
> > > > On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:  
> > > > > Add the obvious compatible name to the existing RTC binding.
> > > > > The actual RTC part of the device uses a different day/month/year
> > > > > storage scheme, so it's not compatible with the previous devices.
> > > > > Also the clock part is quite different, as there is no external 32K 
> > > > > LOSC
> > > > > oscillator input.
> > > > > 
> > > > > Signed-off-by: Andre Przywara 
> > > > >
> > > > > ---
> > > > >  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml  | 14 
> > > > > ++
> > > > >  1 file changed, 14 insertions(+)
> > > > > 
> > > > > diff --git 
> > > > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> > > > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > > index beeb90e55727..d8a6500e5840 100644
> > > > > --- 
> > > > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > > +++ 
> > > > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > > > @@ -26,6 +26,7 @@ properties:
> > > > >- const: allwinner,sun50i-a64-rtc
> > > > >- const: allwinner,sun8i-h3-rtc
> > > > >- const: allwinner,sun50i-h6-rtc
> > > > > +  - const: allwinner,sun50i-h616-rtc
> > > > >  
> > > > >reg:
> > > > >  maxItems: 1
> > > > > @@ -104,6 +105,19 @@ allOf:
> > > > >minItems: 3
> > > > >maxItems: 3
> > > > >  
> > > > > +  - if:
> > > > > +  properties:
> > > > > +compatible:
> > > > > +  contains:
> > > > > +const: allwinner,sun50i-h616-rtc
> > > > > +
> > > > > +then:
> > > > > +  properties:
> > > > > +clock-output-names:
> > > > > +  minItems: 3
> > > > > +  maxItems: 3
> > > > 
> > > > You don't need both of them when they are equal
> > > >   
> > > > > +clocks: false
> > > > > +
> > > > 
> > > > It's not entirely clear to me what those clocks are about though. If we
> > > > look at the clock output in the user manual, it looks like there's only
> > > > two clocks that are actually being output: the 32k "fanout" clock and
> > > > the losc. What are the 3 you're talking about?]  
> > > 
> > > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
> > > clock (/32), and the multiplexed PAD.  
> > 
> > But the input and debounce clock is only for the RTC itself right? So it
> > should be local to the driver and doesn't need to be made available to
> > the other drivers
> 
> I understood "debounce" as being the clock used for the pinctrl
> debouncer. What would it debounce otherwise? Do you think that this
> "debounce circuit" is something internal to the RTC and is totally
> irrelevant for us?

I don't think that's it.

The Debounce circuit is after the 32 divider, so we have a clock rate of
1kHz (Figure 3-35, page 275)

The PIO Interrupt debouncing can use either a 32kHz or 24MHz clock, so
the rates don't match, and given the naming would rather be clocked from
CLK32K_LOSC.

The DCXO_CTRL_REG (Section 3.13.6.13) hints at something different
though, it says:

"
CLK16M_RC_EN
1: Enable
0: Disable
The related register configuration is necessary to ensure the reset debounce
circuit has a stable clock source.
The first time SoC starts up, by default, the reset debounce circuit of SoC
uses 32K divided by RC16M. In power-off, software reads the related bit to
ensure whether EXT32K is working normally, if it is normal, first switch the
clock source of debounce circuit to EXT32K, then close RC16M.
Without EXT32K scenario or external RTC scenario, software confirms firstly
whether EXT32K is

[linux-sunxi] Re: [PATCH 10/54] dt-bindings: display: panel-lvds: Document panel compatibles

2021-08-23 Thread Maxime Ripard
Hi,

On Wed, Aug 18, 2021 at 08:48:46AM -0500, Rob Herring wrote:
> On Wed, Aug 18, 2021 at 7:43 AM Maxime Ripard  wrote:
> >
> > Hi Rob, Sam,
> >
> > On Wed, Jul 21, 2021 at 08:29:47PM -0600, Rob Herring wrote:
> > > On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
> > > > The binding mentions that all the drivers using that driver must use a
> > > > vendor-specific compatible but never enforces it, nor documents the
> > > > vendor-specific compatibles.
> > > >
> > > > Let's make we document all of them, and that the binding will create an
> > > > error if we add one that isn't.
> > > >
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Cc: Laurent Pinchart 
> > > > Cc: Sam Ravnborg 
> > > > Cc: Thierry Reding 
> > > > Signed-off-by: Maxime Ripard 
> > > > ---
> > > >  .../bindings/display/panel/lvds.yaml   | 18 --
> > > >  1 file changed, 12 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
> > > > b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > > > index 49460c9dceea..d1513111eb48 100644
> > > > --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > > > +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > > > @@ -31,12 +31,18 @@ allOf:
> > > >
> > > >  properties:
> > > >compatible:
> > > > -contains:
> > > > -  const: panel-lvds
> > > > -description:
> > > > -  Shall contain "panel-lvds" in addition to a mandatory 
> > > > panel-specific
> > > > -  compatible string defined in individual panel bindings. The 
> > > > "panel-lvds"
> > > > -  value shall never be used on its own.
> > > > +items:
> > > > +  - enum:
> > > > +  - advantech,idk-1110wr
> > >
> > > At least this one is documented elsewhere.
> >
> > Indeed, I missed it.
> >
> > > You can add 'minItems: 2' if you want to just enforce having 2 
> > > compatibles. Or do:
> > >
> > > items:
> > >   - {}
> > >   - const: panel-lvds
> > >
> > > Which also enforces the order.
> >
> > It's not just about the order since a missing compatible will also raise
> > a warning.
> >
> > Some of those panels have a binding of their own, but some probably
> > won't (and I can't find anything specific about the one I'm most
> > interested in: tbs,a711-panel)
> >
> > Can we have something like:
> >
> > compatible:
> >   oneOf:
> > - items:
> >   - enum:
> > - tbs,a711-panel
> >   - const: panel-lvds
> >
> > - items:
> >   - {}
> >   - const: panel-lvds
> >
> > That would work for both cases I guess?
> 
> No, both conditions will be true. If you use 'anyOf', then we're never
> really checking the specific compatible.
> 
> I think the problem here is trying to mix a common binding (aka an
> incomplete collection of properties) and a specific binding.

I'm not entirely sure why we have specific bindings for this in the
first place.

We currently have 6 specific bindings, and for 5 of them the only
specific thing in there are the data-mapping value to force and their
dimension.

I'd argue that the dimension shouldn't even be set in stone: you could
very well imagine a screen with exactly the same timings but a different
size. We would consider it compatible.

And the data-mapping can be dealt with with an if clause fairly easily.

And for the last one, the specific thing about it is that it's using a
dual-link output, which is a generic binding and could thus be described
in panel-lvds too.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210823163114.ohmdpc7pn22p5ycd%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

2021-08-19 Thread Maxime Ripard
Salut Alex,

On Tue, Aug 17, 2021 at 10:13:11AM +0200, Alexandre Belloni wrote:
> On 17/08/2021 09:38:10+0200, Maxime Ripard wrote:
> > > > It's not entirely clear to me what those clocks are about though. If we
> > > > look at the clock output in the user manual, it looks like there's only
> > > > two clocks that are actually being output: the 32k "fanout" clock and
> > > > the losc. What are the 3 you're talking about?]
> > > 
> > > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
> > > clock (/32), and the multiplexed PAD.
> > 
> > But the input and debounce clock is only for the RTC itself right? So it
> > should be local to the driver and doesn't need to be made available to
> > the other drivers
> > 
> 
> Shouldn't they be exposed to be able to use assigned-clock?

I'm not sure we would even need that? If it's an internal clock to the
RTC, then we probably won't ever need to change it from the device tree?

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210819075630.upliivqux4dsohzd%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH 10/54] dt-bindings: display: panel-lvds: Document panel compatibles

2021-08-18 Thread Maxime Ripard
Hi Rob, Sam,

On Wed, Jul 21, 2021 at 08:29:47PM -0600, Rob Herring wrote:
> On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
> > The binding mentions that all the drivers using that driver must use a
> > vendor-specific compatible but never enforces it, nor documents the
> > vendor-specific compatibles.
> > 
> > Let's make we document all of them, and that the binding will create an
> > error if we add one that isn't.
> > 
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Laurent Pinchart 
> > Cc: Sam Ravnborg 
> > Cc: Thierry Reding 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  .../bindings/display/panel/lvds.yaml   | 18 --
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
> > b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > index 49460c9dceea..d1513111eb48 100644
> > --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > @@ -31,12 +31,18 @@ allOf:
> >  
> >  properties:
> >compatible:
> > -contains:
> > -  const: panel-lvds
> > -description:
> > -  Shall contain "panel-lvds" in addition to a mandatory panel-specific
> > -  compatible string defined in individual panel bindings. The 
> > "panel-lvds"
> > -  value shall never be used on its own.
> > +items:
> > +  - enum:
> > +  - advantech,idk-1110wr
> 
> At least this one is documented elsewhere.

Indeed, I missed it.

> You can add 'minItems: 2' if you want to just enforce having 2 compatibles. 
> Or do:
> 
> items:
>   - {}
>   - const: panel-lvds
> 
> Which also enforces the order.

It's not just about the order since a missing compatible will also raise
a warning.

Some of those panels have a binding of their own, but some probably
won't (and I can't find anything specific about the one I'm most
interested in: tbs,a711-panel)

Can we have something like:

compatible:
  oneOf:
- items:
  - enum:
- tbs,a711-panel
  - const: panel-lvds

- items:
  - {}
  - const: panel-lvds

That would work for both cases I guess?

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210818124304.2jxsf44bcbprcvbk%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH 05/54] dt-bindings: Convert Reserved Memory binding to a schema

2021-08-18 Thread Maxime Ripard
Hi Rob,

On Wed, Jul 21, 2021 at 08:30:43AM -0600, Rob Herring wrote:
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: /reserved-memory Node
> > +
> > +maintainers:
> > +  - Devicetree Specification Mailing List 
> > +
> > +description: >
> > +  Reserved memory is specified as a node under the /reserved-memory node. 
> > The
> > +  operating system shall exclude reserved memory from normal usage one can
> > +  create child nodes describing particular reserved (excluded from normal 
> > use)
> > +  memory regions. Such memory regions are usually designed for the special
> > +  usage by various device drivers.
> > +
> > +properties:
> > +  $nodename:
> > +const: reserved-memory
> > +
> > +  "#address-cells": true
> > +  "#size-cells": true
> > +  ranges: true
> > +
> > +patternProperties:
> > +  "^(?!(ranges))[a-z,-]*(@[0-9]+)?$":
> 
> Note that you could drop this and put under 'additionalProperties'.
> You would lose some node name checking, but there's really little
> standard on these nodes.

I didn't realise it could be used that way too, I'll change it.

> > +type: object
> > +
> > +description: >
> > +  Each child of the reserved-memory node specifies one or more regions 
> > of
> > +  reserved memory. Each child node may either use a 'reg' property to
> > +  specify a specific range of reserved memory, or a 'size' property 
> > with
> > +  optional constraints to request a dynamically allocated block of 
> > memory.
> > +
> > +  Following the generic-names recommended practice, node names should
> > +  reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). 
> > Unit
> > +  address (@) should be appended to the name if the node is a
> > +  static allocation.
> > +
> > +properties:
> > +  reg: true
> > +
> > +  size:
> > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > +description: >
> > +  Length based on parent's \#size-cells. Size in bytes of memory to
> > +  reserve.
> > +
> > +  alignment:
> > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > +description: >
> > +  Length based on parent's \#size-cells. Address boundary for
> > +  alignment of allocation.
> > +
> > +  alloc-ranges:
> > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > +description: >
> > +  Address and Length pairs. Specifies regions of memory that are
> > +  acceptable to allocate from.
> > +
> > +  compatible:
> > +oneOf:
> > +  - const: shared-dma-pool
> > +description: >
> > +  This indicates a region of memory meant to be used as a 
> > shared
> > +  pool of DMA buffers for a set of devices. It can be used by 
> > an
> > +  operating system to instantiate the necessary pool management
> > +  subsystem if necessary.
> > +
> > +  # Vendor-specific compatibles in the form 
> > ,[-]
> > +  - const: mediatek,trustzone-bootinfo
> 
> I think these should be separate schema files. At least, we're going
> to need to support separate files because I don't think we want ones
> adding custom properties here. This would fail unless we add every
> compatible here. We could also be a bit more exact as to which
> properties below apply (e.g. linux,.*-default is only valid for
> shared-dma-pool).

I'm not entirely sure how we can just ignore the vendor compatibles
without raising a warning. Do you have any suggestion?

Thanks!
Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210818100021.yzzcuadkowy4tfv4%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH 27/54] dt-bindings: net: wireless: Convert ESP ESP8089 binding to a schema

2021-08-18 Thread Maxime Ripard
Hi Kalle,

On Fri, Aug 06, 2021 at 08:47:09AM +, Kalle Valo wrote:
> Maxime Ripard  wrote:
> 
> > The ESP8089 Wireless Chip is supported by Linux (through an out-of-tree
> > driver) thanks to its device tree binding.
> > 
> > Now that we have the DT validation in place, let's convert the device
> > tree bindings for that driver over to a YAML schema.
> > 
> > Cc: "David S. Miller" 
> > Cc: de Goede 
> > Cc: Jakub Kicinski 
> > Cc: Kalle Valo 
> > Cc: linux-wirel...@vger.kernel.org
> > Cc: net...@vger.kernel.org
> > Signed-off-by: Maxime Ripard 
> > Reviewed-by: Rob Herring 
> 
> We support out-of-tree drivers in DT?

Yeah, as long as the binding is stable we can merge it. This controller
is one of these examples, but we supported multiple GPU that way too.

> Via which tree is this supposed to go? I guess not via
> wireless-drivers-next as this is an out-of-tree driver.

It's up to you I guess. It was already part of the dt-bindings wireless
directory, so either your tree or the DT maintainers if you'd prefer not
to.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210818084539.kw267o4dc5nqk2qt%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v9 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

2021-08-18 Thread Maxime Ripard
On Mon, Aug 02, 2021 at 01:39:43AM +0100, Andre Przywara wrote:
> Add the obvious compatible name to the existing RTC binding.
> The actual RTC part of the device uses a different day/month/year
> storage scheme, so it's not compatible with the previous devices.
> Also the clock part is quite different, as there is no external 32K LOSC
> oscillator input.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Rob Herring 
> ---
>  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml  | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> index beeb90e55727..d8a6500e5840 100644
> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> @@ -26,6 +26,7 @@ properties:
>- const: allwinner,sun50i-a64-rtc
>- const: allwinner,sun8i-h3-rtc
>- const: allwinner,sun50i-h6-rtc
> +  - const: allwinner,sun50i-h616-rtc
>  
>reg:
>  maxItems: 1
> @@ -104,6 +105,19 @@ allOf:
>minItems: 3
>maxItems: 3
>  
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: allwinner,sun50i-h616-rtc
> +
> +then:
> +  properties:
> +clock-output-names:
> +  minItems: 3
> +  maxItems: 3

The comments I made here on the v7 are still relevant: you only need one
of these two, and the list of clocks should be documented.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210818081526.ejzqyz4tqvf2mmdj%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

2021-08-17 Thread Maxime Ripard
Hi,

On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
> On Mon, 26 Jul 2021 16:41:37 +0200
> Maxime Ripard  wrote:
> 
> > Hi,
> > 
> > On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:
> > > Add the obvious compatible name to the existing RTC binding.
> > > The actual RTC part of the device uses a different day/month/year
> > > storage scheme, so it's not compatible with the previous devices.
> > > Also the clock part is quite different, as there is no external 32K LOSC
> > > oscillator input.
> > > 
> > > Signed-off-by: Andre Przywara 
> > >
> > > ---
> > >  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml  | 14 ++
> > >  1 file changed, 14 insertions(+)
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > index beeb90e55727..d8a6500e5840 100644
> > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > @@ -26,6 +26,7 @@ properties:
> > >- const: allwinner,sun50i-a64-rtc
> > >- const: allwinner,sun8i-h3-rtc
> > >- const: allwinner,sun50i-h6-rtc
> > > +  - const: allwinner,sun50i-h616-rtc
> > >  
> > >reg:
> > >  maxItems: 1
> > > @@ -104,6 +105,19 @@ allOf:
> > >minItems: 3
> > >maxItems: 3
> > >  
> > > +  - if:
> > > +  properties:
> > > +compatible:
> > > +  contains:
> > > +const: allwinner,sun50i-h616-rtc
> > > +
> > > +then:
> > > +  properties:
> > > +clock-output-names:
> > > +  minItems: 3
> > > +  maxItems: 3  
> > 
> > You don't need both of them when they are equal
> > 
> > > +clocks: false
> > > +  
> > 
> > It's not entirely clear to me what those clocks are about though. If we
> > look at the clock output in the user manual, it looks like there's only
> > two clocks that are actually being output: the 32k "fanout" clock and
> > the losc. What are the 3 you're talking about?]
> 
> I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
> clock (/32), and the multiplexed PAD.

But the input and debounce clock is only for the RTC itself right? So it
should be local to the driver and doesn't need to be made available to
the other drivers

Either way, what this list is must be documented.

> > Also, it looks like the 32k fanout clock needs at least the hosc or
> > pll-periph in input, so we probably don't want to ask for no parent
> > clock?
> 
> Well, we never seem to reference the HOSC this way, this was always
> somewhat explicit. And yes, there is PLL-PERIPH as an input, but we
> don't support this yet. So I went with 0 input clocks *for now*: the
> driver can then ignore all clocks, so any clock referenced in the DT
> later won't cause any harm. This will all be addressed by Samuel's RTC
> clock patch, which will also touch the H6, IIRC. And it looks like we
> will need to touch the binding anyway then, but can then just *extend*
> this.

You mentioned that series several times already and never provided an
explanation for what it was supposed to be doing except fixing
everything. What's the general plan for that series?

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210817073810.7stuzrppyjf4spab%40gilmour.


signature.asc
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >