* Re: (subset) [PATCH v2 0/3] (Re)enable DP/HDMI audio for RK3399 Gru
From: Heiko Stuebner @ 2022-01-23 15:40 UTC (permalink / raw)
To: Mark Brown, Brian Norris, Daniel Vetter, David Airlie,
Liam Girdwood
Cc: Heiko Stuebner, Rob Herring, linux-arm-kernel, dri-devel,
Lin Huang, devicetree, linux-rockchip, linux-kernel, alsa-devel,
Sandy Huang
In-Reply-To: <20220114230209.4091727-1-briannorris@chromium.org>
On Fri, 14 Jan 2022 15:02:06 -0800, Brian Norris wrote:
> This series fixes DP/HDMI audio for RK3399 Gru systems.
>
> First, there was a regression with the switch to SPDIF. Patch 1 can be
> taken separately as a regression fix if desired. But it's not quite so
> useful (at least on Chrome OS systems) without the second part.
>
> Second, jack detection was never upstreamed, because the hdmi-codec
> dependencies were still being worked out when this platform was first
> supported.
>
> [...]
Applied as fix for 5.17, thanks!
[1/3] arm64: dts: rockchip: Switch RK3399-Gru DP to SPDIF output
commit: b5fbaf7d779f5f02b7f75b080e7707222573be2a
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: rk3568: drop pclk_xpcs from gmac0
From: Heiko Stuebner @ 2022-01-23 15:40 UTC (permalink / raw)
To: Frank Wunderlich, linux-rockchip
Cc: Heiko Stuebner, Rob Herring, linux-arm-kernel, Peter Geis,
Frank Wunderlich, devicetree, linux-kernel, Michael Riesch
In-Reply-To: <20220123133510.135651-1-linux@fw-web.de>
On Sun, 23 Jan 2022 14:35:10 +0100, Frank Wunderlich wrote:
> pclk_xpcs is not supported by mainline driver and breaks dtbs_check
>
> following warnings occour, and many more
>
> rk3568-evb1-v10.dt.yaml: ethernet@fe2a0000: clocks:
> [[15, 386], [15, 389], [15, 389], [15, 184], [15, 180], [15, 181],
> [15, 389], [15, 185], [15, 172]] is too long
> From schema: Documentation/devicetree/bindings/net/snps,dwmac.yaml
> rk3568-evb1-v10.dt.yaml: ethernet@fe2a0000: clock-names:
> ['stmmaceth', 'mac_clk_rx', 'mac_clk_tx', 'clk_mac_refout', 'aclk_mac',
> 'pclk_mac', 'clk_mac_speed', 'ptp_ref', 'pclk_xpcs'] is too long
> From schema: Documentation/devicetree/bindings/net/snps,dwmac.yaml
>
> [...]
Applied as fix for 5.17, thanks!
[1/1] arm64: dts: rk3568: drop pclk_xpcs from gmac0
commit: 85a8bccfa945680dc561f06b65ea01341d2033fc
I've adapted the subject to
arm64: dts: rockchip: drop pclk_xpcs from gmac0 on rk3568
though. Please use prefixes matching the subsystem
(i.e. arm64: dts: rockchip: ... in this case)
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: fix rk3399-puma-haikou USB OTG mode
From: Heiko Stuebner @ 2022-01-23 15:40 UTC (permalink / raw)
To: quentin.schulz@theobroma-systems.com, robh+dt
Cc: Heiko Stuebner, linux-arm-kernel, devicetree, linux-rockchip,
Quentin Schulz, linux-kernel
In-Reply-To: <20220120125156.16217-1-quentin.schulz@theobroma-systems.com>
On Thu, 20 Jan 2022 13:51:56 +0100, quentin.schulz@theobroma-systems.com wrote:
> The micro USB3.0 port available on the Haikou evaluation kit for Puma
> RK3399-Q7 SoM supports dual-role model (aka drd or OTG) but its support
> was broken until now because of missing logic around the ID pin.
>
> This adds proper support for USB OTG on Puma Haikou by "connecting" the
> GPIO used for USB ID to the USB3 controller device.
Applied as fix for 5.17, thanks!
[1/1] arm64: dts: rockchip: fix rk3399-puma-haikou USB OTG mode
commit: ed2c66a95c0c5669880aa93d0d34c6e9694b4cbd
I've done a bit of reordereing:
- extcon comes alphabetically after dr_mode
- extcon-usb3 before external-gmac...
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: rk356x: fix dma-controller warning
From: Heiko Stuebner @ 2022-01-23 15:40 UTC (permalink / raw)
To: Frank Wunderlich, linux-rockchip
Cc: Heiko Stuebner, Rob Herring, linux-arm-kernel, Frank Wunderlich,
devicetree, linux-kernel, Michael Riesch
In-Reply-To: <20220123133615.135789-1-linux@fw-web.de>
On Sun, 23 Jan 2022 14:36:15 +0100, Frank Wunderlich wrote:
> DMA-Cotrollers defined in rk356x.dtsi do not match the pattern in bindings.
>
> arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dt.yaml:
> dmac@fe530000: $nodename:0: 'dmac@fe530000' does not match '^dma-controller(@.*)?$'
> From schema: Documentation/devicetree/bindings/dma/arm,pl330.yaml
> arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dt.yaml:
> dmac@fe550000: $nodename:0: 'dmac@fe550000' does not match '^dma-controller(@.*)?$'
> From schema: Documentation/devicetree/bindings/dma/arm,pl330.yaml
>
> [...]
Applied as fix for 5.17, thanks!
[1/1] arm64: dts: rk356x: fix dma-controller warning
commit: 2ddd96aadbd0412040ef49eda94549c32de6c92c
I've adapted the subject to
arm64: dts: rockchip: fix dma-controller node names on rk356x
though. Please use prefixes matching the subsystem
(i.e. arm64: dts: rockchip: ... in this case)
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: rockchip: enable the pine64 touch screen on rockpro64
From: Heiko Stuebner @ 2022-01-23 15:30 UTC (permalink / raw)
To: Rob Herring, Peter Geis
Cc: Peter Geis, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20220107051335.3812535-5-pgwipeout@gmail.com>
Hi Peter,
Am Freitag, 7. Januar 2022, 06:13:35 CET schrieb Peter Geis:
> Enable the touch screen, backlight, and dsi nodes for the Pine64 touch panel
> attached to the rockpro64.
can you please also include me in the other patches of the series?
I.e. they introduce a new property for the display, so it's nice to know
when they get applied.
While I do agree with patch 3/4, I'm hesistant about this one.
The display/touchscreen will probably not be connected on every rockpro64
so what happens if it doesn't?
I.e are there alternative uses for the affected pins, that may get fried
when this is always enabled?
So part of me would think that an dt-overlay enabling this might be the
nicer way to go?
Heiko
> Signed-off-by: Peter Geis <pgwipeout@gmail.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> index 158befb9a48c..f6c36fcd6db3 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> @@ -26,7 +26,7 @@ backlight: backlight {
> pwms = <&pwm0 0 1000000 0>;
> brightness-levels = <0 4 8 16 32 64 128 255>;
> default-brightness-level = <5>;
> - status = "disabled";
> + status = "okay";
> };
>
> clkin_gmac: external-gmac-clock {
> @@ -594,7 +594,7 @@ touch: touchscreen@5d {
> interrupts = <RK_PD5 IRQ_TYPE_EDGE_FALLING>;
> irq-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&gpio4 RK_PD6 GPIO_ACTIVE_HIGH>;
> - status = "disabled";
> + status = "okay";
> };
> };
>
> @@ -633,7 +633,7 @@ &io_domains {
>
> /* enable for pine64 panel display support */
> &mipi_dsi {
> - status = "disabled";
> + status = "okay";
> clock-master;
>
> ports {
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: watchdog: fsl-imx7ulp-wdt: Fix assigned-clock-parents
From: Rob Herring @ 2022-01-23 15:29 UTC (permalink / raw)
To: Rob Herring
Cc: Guenter Roeck, Shawn Guo, NXP Linux Team, Wim Van Sebroeck,
linux-arm-kernel, linux-kernel, Anson Huang, linux-watchdog,
Sascha Hauer, Fabio Estevam, devicetree, Pengutronix Kernel Team
In-Reply-To: <20220120172333.1628990-1-robh@kernel.org>
On Thu, 20 Jan 2022 11:23:32 -0600, Rob Herring wrote:
> The schema has a typo with 'assigned-clocks-parents'. As it is not
> required to list assigned clocks in bindings, just drop the assigned-clocks
> property definitions to fix this.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: ti,k3-am654-cpts: Fix assigned-clock-parents
From: Rob Herring @ 2022-01-23 15:29 UTC (permalink / raw)
To: Rob Herring
Cc: netdev, Jakub Kicinski, David S. Miller, devicetree, linux-kernel,
Grygorii Strashko, Sekhar Nori
In-Reply-To: <20220120172319.1628500-1-robh@kernel.org>
On Thu, 20 Jan 2022 11:23:18 -0600, Rob Herring wrote:
> The schema has a typo with 'assigned-clocks-parents'. As it is not
> required to list assigned clocks in bindings, just drop the assigned-clocks
> property definitions to fix this
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml | 6 ------
> 1 file changed, 6 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: stm32-i2c: Move st,syscfg-fmp definition to top level
From: Rob Herring @ 2022-01-23 15:29 UTC (permalink / raw)
To: Rob Herring
Cc: Pierre-Yves MORDRET, devicetree, Maxime Coquelin, linux-i2c,
linux-stm32, linux-kernel, linux-arm-kernel, Alexandre Torgue
In-Reply-To: <20220119174407.3810088-1-robh@kernel.org>
On Wed, 19 Jan 2022 11:44:07 -0600, Rob Herring wrote:
> It is preferred to define all properties in the main schema and leave
> if/then/else schemas to just be further constraints on properties.
>
> Rework the schema to use be more specific for each cell. Previously,
> multiple entries of 3 cells each was allowed.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 24 ++++++++++---------
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: ingenic,i2c: Rework interrupts in example
From: Rob Herring @ 2022-01-23 15:28 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-kernel, linux-i2c, Paul Cercueil
In-Reply-To: <20220119174349.3809513-1-robh@kernel.org>
On Wed, 19 Jan 2022 11:43:49 -0600, Rob Herring wrote:
> In order to determine the number of interrupt cells in examples, the
> examples will require all 'interrupts' properties to use the same number
> of cells or have explicit interrupt provider node(s). As the former is
> simpler, update the Ingenic example to use 2 interrupt cells everywhere.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: nvmem: qcom,spmi-sdam: Drop child node schema
From: Rob Herring @ 2022-01-23 15:28 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, devicetree, linux-kernel, Kumar Thella,
Andy Gross, linux-arm-msm, Srinivas Kandagatla
In-Reply-To: <20220119151135.3598392-1-robh@kernel.org>
On Wed, 19 Jan 2022 09:11:35 -0600, Rob Herring wrote:
> Drop the child node schema. The schema for child nodes is already
> defined by nvmem.yaml and doesn't need to be duplicated in the
> qcom,spmi-sdam schema.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/nvmem/qcom,spmi-sdam.yaml | 28 -------------------
> 1 file changed, 28 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: imx: Make each example a separate entry
From: Rob Herring @ 2022-01-23 15:28 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-i2c, Shawn Guo, Oleksij Rempel, Sascha Hauer,
Fabio Estevam, Oleksij Rempel, NXP Linux Team, linux-arm-kernel,
linux-kernel, Pengutronix Kernel Team
In-Reply-To: <20220119015253.2437352-1-robh@kernel.org>
On Tue, 18 Jan 2022 19:52:53 -0600, Rob Herring wrote:
> Each independent example should be a separate entry. This allows for
> 'interrupts' to have different cell sizes.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/i2c/i2c-imx.yaml | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: mpc: Make each example a separate entry
From: Rob Herring @ 2022-01-23 15:28 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-kernel, Chris Packham, linux-i2c
In-Reply-To: <20220119015234.2436754-1-robh@kernel.org>
On Tue, 18 Jan 2022 19:52:34 -0600, Rob Herring wrote:
> Each independent example should be a separate entry. This allows for
> 'interrupts' to have different cell sizes.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Applied, thanks!
^ permalink raw reply
* Re: MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC
From: Andrew Lunn @ 2022-01-23 15:26 UTC (permalink / raw)
To: Arınç ÜNAL
Cc: DENG Qingfang, Luiz Angelo Daros de Luca, Matthias Brugger,
John Crispin, Siddhant Gupta, Ilya Lipnitskiy, Sergio Paracuellos,
Felix Fietkau, Sean Wang, Mark Lee, Russell King, Jakub Kicinski,
David Miller, René van Dorst,
moderated list:ARM/Mediatek SoC support, netdev, linux-mips,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
openwrt-devel, erkin.bozoglu
In-Reply-To: <02ecce91-7aad-4392-c9d7-f45ca1b31e0b@arinc9.com>
On Sun, Jan 23, 2022 at 11:33:04AM +0300, Arınç ÜNAL wrote:
> Hey Deng,
>
> On 23/01/2022 09:51, DENG Qingfang wrote:
> > Hi,
> >
> > Do you set the ethernet pinmux correctly?
> >
> > ðernet {
> > pinctrl-names = "default";
> > pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>;
> > };
>
> This fixed it! We did have &rgmii2_pins on the gmac1 node (it was originally
> on external_phy) so we never thought to investigate the pinctrl
> configuration further! Turns out &rgmii2_pins needs to be defined on the
> ethernet node instead.
PHYs are generally external, so pinmux on them makes no sense. PHYs in
DT are not devices in the usual sense, so i don't think the driver
core will handle pinmux for them, even if you did list them.
This could be interesting for the DT compliance checker. Ideally we
want it to warn if it finds a pinmux configuration in a PHY node.
It also sounds like you had them somewhere else wrong?
Andrew
^ permalink raw reply
* Re: [PATCH v6 03/14] media: cadence: csi2rx: Add get_fmt and set_fmt pad ops
From: Laurent Pinchart @ 2022-01-23 15:13 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Mauro Carvalho Chehab, Nikhil Devshatwar, Tomi Valkeinen,
Benoit Parrot, Maxime Ripard, Rob Herring, Sakari Ailus,
Niklas Söderlund, devicetree, linux-kernel, linux-media
In-Reply-To: <20220121142904.4091481-4-p.yadav@ti.com>
Hi Pratyush,
Thank you for the patch.
On Fri, Jan 21, 2022 at 07:58:53PM +0530, Pratyush Yadav wrote:
> The format is needed to calculate the link speed for the external DPHY
> configuration. It is not right to query the format from the source
> subdev. Add get_fmt and set_fmt pad operations so that the format can be
> configured and correct bpp be selected.
>
> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>
> Changes in v6:
> - Move the lock around the dereference for framefmt in
> csi2rx_{get,set}_fmt() instead of when we get the pointer.
> - Do not return an error when an unsupported format is set. Instead
> adjust the code to the first format in the list.
> - Not adding Laurent's R-by since I am making changes in
> csi2rx_set_fmt() that he didn't explicitly recommend.
>
> Changes in v5:
> - Use YUV 1X16 formats instead of 2X8.
> - New in v5.
>
> drivers/media/platform/cadence/cdns-csi2rx.c | 131 +++++++++++++++++++
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c b/drivers/media/platform/cadence/cdns-csi2rx.c
> index 2547903f2e8e..ae3ebdb3890d 100644
> --- a/drivers/media/platform/cadence/cdns-csi2rx.c
> +++ b/drivers/media/platform/cadence/cdns-csi2rx.c
> @@ -54,6 +54,11 @@ enum csi2rx_pads {
> CSI2RX_PAD_MAX,
> };
>
> +struct csi2rx_fmt {
> + u32 code;
> + u8 bpp;
> +};
> +
> struct csi2rx_priv {
> struct device *dev;
> unsigned int count;
> @@ -79,12 +84,43 @@ struct csi2rx_priv {
> struct v4l2_subdev subdev;
> struct v4l2_async_notifier notifier;
> struct media_pad pads[CSI2RX_PAD_MAX];
> + struct v4l2_mbus_framefmt fmt;
>
> /* Remote source */
> struct v4l2_subdev *source_subdev;
> int source_pad;
> };
>
> +static const struct csi2rx_fmt formats[] = {
> + {
> + .code = MEDIA_BUS_FMT_YUYV8_1X16,
> + .bpp = 16,
> + },
> + {
> + .code = MEDIA_BUS_FMT_UYVY8_1X16,
> + .bpp = 16,
> + },
> + {
> + .code = MEDIA_BUS_FMT_YVYU8_1X16,
> + .bpp = 16,
> + },
> + {
> + .code = MEDIA_BUS_FMT_VYUY8_1X16,
> + .bpp = 16,
> + },
> +};
> +
> +static const struct csi2rx_fmt *csi2rx_get_fmt_by_code(u32 code)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(formats); i++)
> + if (formats[i].code == code)
> + return &formats[i];
> +
> + return NULL;
> +}
> +
> static inline
> struct csi2rx_priv *v4l2_subdev_to_csi2rx(struct v4l2_subdev *subdev)
> {
> @@ -236,12 +272,103 @@ static int csi2rx_s_stream(struct v4l2_subdev *subdev, int enable)
> return ret;
> }
>
> +static struct v4l2_mbus_framefmt *
> +csi2rx_get_pad_format(struct csi2rx_priv *csi2rx,
> + struct v4l2_subdev_state *state,
> + unsigned int pad, u32 which)
> +{
> + switch (which) {
> + case V4L2_SUBDEV_FORMAT_TRY:
> + return v4l2_subdev_get_try_format(&csi2rx->subdev, state, pad);
> + case V4L2_SUBDEV_FORMAT_ACTIVE:
> + return &csi2rx->fmt;
> + default:
> + return NULL;
> + }
> +}
> +
> +static int csi2rx_get_fmt(struct v4l2_subdev *subdev,
> + struct v4l2_subdev_state *state,
> + struct v4l2_subdev_format *format)
> +{
> + struct csi2rx_priv *csi2rx = v4l2_subdev_to_csi2rx(subdev);
> + struct v4l2_mbus_framefmt *framefmt;
> +
> + framefmt = csi2rx_get_pad_format(csi2rx, state, format->pad,
> + format->which);
> + if (!framefmt)
> + return -EINVAL;
> +
> + mutex_lock(&csi2rx->lock);
> + format->format = *framefmt;
> + mutex_unlock(&csi2rx->lock);
> +
> + return 0;
> +}
> +
> +static int csi2rx_set_fmt(struct v4l2_subdev *subdev,
> + struct v4l2_subdev_state *state,
> + struct v4l2_subdev_format *format)
> +{
> + struct csi2rx_priv *csi2rx = v4l2_subdev_to_csi2rx(subdev);
> + struct v4l2_mbus_framefmt *framefmt;
> +
> + /* No transcoding, source and sink formats must match. */
> + if (format->pad != CSI2RX_PAD_SINK)
> + return csi2rx_get_fmt(subdev, state, format);
> +
> + if (!csi2rx_get_fmt_by_code(format->format.code))
> + format->format.code = formats[0].code;
> +
> + format->format.field = V4L2_FIELD_NONE;
> +
> + framefmt = csi2rx_get_pad_format(csi2rx, state, format->pad,
> + format->which);
> + if (!framefmt)
> + return -EINVAL;
> +
> + mutex_lock(&csi2rx->lock);
> + *framefmt = format->format;
> + mutex_unlock(&csi2rx->lock);
> +
> + return 0;
> +}
> +
> +static int csi2rx_init_cfg(struct v4l2_subdev *subdev,
> + struct v4l2_subdev_state *state)
> +{
> + struct v4l2_subdev_format format = {
> + .which = state ? V4L2_SUBDEV_FORMAT_TRY
> + : V4L2_SUBDEV_FORMAT_ACTIVE,
> + .pad = CSI2RX_PAD_SINK,
> + .format = {
> + .width = 640,
> + .height = 480,
> + .code = MEDIA_BUS_FMT_UYVY8_1X16,
> + .field = V4L2_FIELD_NONE,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> + .ycbcr_enc = V4L2_YCBCR_ENC_601,
> + .quantization = V4L2_QUANTIZATION_LIM_RANGE,
> + .xfer_func = V4L2_XFER_FUNC_SRGB,
> + },
> + };
> +
> + return csi2rx_set_fmt(subdev, state, &format);
> +}
> +
> +static const struct v4l2_subdev_pad_ops csi2rx_pad_ops = {
> + .get_fmt = csi2rx_get_fmt,
> + .set_fmt = csi2rx_set_fmt,
> + .init_cfg = csi2rx_init_cfg,
> +};
> +
> static const struct v4l2_subdev_video_ops csi2rx_video_ops = {
> .s_stream = csi2rx_s_stream,
> };
>
> static const struct v4l2_subdev_ops csi2rx_subdev_ops = {
> .video = &csi2rx_video_ops,
> + .pad = &csi2rx_pad_ops,
> };
>
> static int csi2rx_async_bound(struct v4l2_async_notifier *notifier,
> @@ -457,6 +584,10 @@ static int csi2rx_probe(struct platform_device *pdev)
> if (ret)
> goto err_cleanup;
>
> + ret = csi2rx_init_cfg(&csi2rx->subdev, NULL);
> + if (ret)
> + goto err_cleanup;
> +
> ret = v4l2_async_register_subdev(&csi2rx->subdev);
> if (ret < 0)
> goto err_cleanup;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH V3 4/4] thermal: qcom: add support for PMIC5 Gen2 ADCTM
From: Jishnu Prakash @ 2022-01-23 14:56 UTC (permalink / raw)
To: Dmitry Baryshkov, agross, bjorn.andersson, devicetree, mka,
robh+dt, knaack.h, lars, pmeerw, manivannan.sadhasivam,
linus.walleij, quic_kgunda, quic_aghayal, daniel.lezcano,
rui.zhang, quic_subbaram, jic23, amitk, Thara Gopinath,
Rafael J. Wysocki, linux-pm, linux-arm-msm, linux-kernel
Cc: linux-arm-msm-owner, linux-iio
In-Reply-To: <b0fb77da-812c-b1b7-81fa-cad0b6ba247c@linaro.org>
Hi Dmitry,
On 11/29/2021 8:02 AM, Dmitry Baryshkov wrote:
> On 23/11/2021 08:57, Jishnu Prakash wrote:
>> Add support for PMIC5 Gen2 ADC_TM, used on PMIC7 chips. It is a
>> close counterpart of PMIC7 ADC and has the same functionality as
>> PMIC5 ADC_TM, for threshold monitoring and interrupt generation.
>> It is present on PMK8350 alone, like PMIC7 ADC and can be used
>> to monitor up to 8 ADC channels, from any of the PMIC7 PMICs
>> having ADC on a target, through PBS(Programmable Boot Sequence).
>>
>> Signed-off-by: Jishnu Prakash <quic_jprakash@quicinc.com>
>> ---
>> drivers/thermal/qcom/qcom-spmi-adc-tm5.c | 375
>> ++++++++++++++++++++++++++++++-
>> 1 file changed, 372 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
>> b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
>> index fc8cd45..a7b33a8 100644
>> static int adc_tm5_set_trips(void *data, int low, int high)
>> {
>> struct adc_tm5_channel *channel = data;
>> @@ -422,6 +739,11 @@ static int adc_tm5_init(struct adc_tm5_chip *chip)
>> }
>> }
>> + mutex_init(&chip->adc_mutex_lock);
>
> Minor issue. This way, the mutex is left uninitialized for ADC_TM5_HC
> devices. I'd move the mutex_init() call to the _probe function itself.
The mutex is needed only for Gen2 ADC_TM devices, I have mentioned this
in the adc_tm5_chip struct description. I'll keep it in the Gen2 ADC_TM
init function.
>
>> +
>> + if (chip->data->gen == ADC_TM5_GEN2)
>> + return ret;
>> +
>
> Please do not do this. Create a separate adc_tm5_gen2_init function.
> Add init() callback to adc_tm5_data structure.
Will make this change in next post.
>
>> buf[0] = chip->decimation;
>> buf[1] = chip->avg_samples | ADC_TM5_FAST_AVG_EN;
>> buf[2] = ADC_TM5_TIMER1;
>> @@ -442,7 +764,7 @@ static int adc_tm5_get_dt_channel_data(struct
>> adc_tm5_chip *adc_tm,
>> struct device_node *node)
>> {
>> const char *name = node->name;
>> - u32 chan, value, varr[2];
>> + u32 chan, value, adc_channel, varr[2];
>> int ret;
>> struct device *dev = adc_tm->dev;
>> struct of_phandle_args args;
>> @@ -472,7 +794,11 @@ static int adc_tm5_get_dt_channel_data(struct
>> adc_tm5_chip *adc_tm,
>> }
>> of_node_put(args.np);
>> - if (args.args_count != 1 || args.args[0] >= ADC5_MAX_CHANNEL) {
>> + adc_channel = args.args[0];
>> + if (adc_tm->data->gen == ADC_TM5_GEN2)
>> + adc_channel &= 0xff;
>> +
>> + if (args.args_count != 1 || adc_channel >= ADC5_MAX_CHANNEL) {
>
> Here you read the data (args.args[0]) before checking that it is
> actually available (args.args_count is not zero). Please correct the
> sequence.
Will correct this in next post.
>
>> dev_err(dev, "%s: invalid ADC channel number %d\n", name,
>> chan);
>> return -EINVAL;
>> }
>> @@ -518,6 +844,32 @@ static int adc_tm5_get_dt_channel_data(struct
>> adc_tm5_chip *adc_tm,
>> else
>> channel->cal_method = ADC_TM5_ABSOLUTE_CAL;
>> + if (adc_tm->data->gen == ADC_TM5_GEN2) {
>> + ret = of_property_read_u32(node, "qcom,decimation", &value);
>> + if (!ret) {
>> + ret = qcom_adc5_decimation_from_dt(value,
>> adc_tm->data->decimation);
>> + if (ret < 0) {
>> + dev_err(dev, "invalid decimation %d\n", value);
>> + return ret;
Thanks,
Jishnu
^ permalink raw reply
* Re: [PATCH V3 3/4] thermal: qcom: Add support for multiple generations of devices
From: Jishnu Prakash @ 2022-01-23 14:50 UTC (permalink / raw)
To: Dmitry Baryshkov, agross, bjorn.andersson, devicetree, mka,
robh+dt, knaack.h, lars, pmeerw, manivannan.sadhasivam,
linus.walleij, quic_kgunda, quic_aghayal, daniel.lezcano,
rui.zhang, quic_subbaram, jic23, amitk, Thara Gopinath,
Rafael J. Wysocki, linux-pm, linux-arm-msm, linux-kernel
Cc: linux-arm-msm-owner, linux-iio
In-Reply-To: <47228209-552e-b148-c93a-4fbb5a36583e@linaro.org>
Hi Dmitry,
On 11/29/2021 7:55 AM, Dmitry Baryshkov wrote:
> On 23/11/2021 08:57, Jishnu Prakash wrote:
>> Refactor code to support multiple generations of ADC_TM devices
>> by defining gen number, irq name and disable, configure and isr
>> APIs in the individual data structs.
>>
>> Signed-off-by: Jishnu Prakash <quic_jprakash@quicinc.com>
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>
> Minor question below.
>
>> ---
>> drivers/thermal/qcom/qcom-spmi-adc-tm5.c | 76
>> ++++++++++++++++++++------------
>> 1 file changed, 48 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
>> b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
>> index 824671c..fc8cd45 100644
>> --- a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
>> +++ b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
>> @@ -78,11 +78,10 @@ enum adc5_timer_select {
>> ADC5_TIMER_SEL_NONE,
>> };
>> -struct adc_tm5_data {
>> - const u32 full_scale_code_volt;
>> - unsigned int *decimation;
>> - unsigned int *hw_settle;
>> - bool is_hc;
>> +enum adc5_gen {
>> + ADC_TM5,
>> + ADC_TM_HC,
>> + ADC_TM5_MAX
>> };
>> enum adc_tm5_cal_method {
>> @@ -92,6 +91,18 @@ enum adc_tm5_cal_method {
>> };
>> struct adc_tm5_chip;
>> +struct adc_tm5_channel;
>> +
>> +struct adc_tm5_data {
>> + const u32 full_scale_code_volt;
>> + unsigned int *decimation;
>> + unsigned int *hw_settle;
>> + int (*disable_channel)(struct adc_tm5_channel *channel);
>> + int (*configure)(struct adc_tm5_channel *channel, int low, int
>> high);
>> + irqreturn_t (*isr)(int irq, void *data);
>> + char *irq_name;
>> + int gen;
>> +};
>
> Any reason for moving the adc_tm5_data definition? It is still prefix
> with the adc_tmp5_channel declaration.
There's no strong reason, I just thought it would look better to keep
all the major struct definitions together after the enum definitions.
>
>> /**
>> * struct adc_tm5_channel - ADC Thermal Monitoring channel data.
>> @@ -139,22 +150,6 @@ struct adc_tm5_chip {
>> u16 base;
>> };
>> -static const struct adc_tm5_data adc_tm5_data_pmic = {
>> - .full_scale_code_volt = 0x70e4,
>> - .decimation = (unsigned int []) { 250, 420, 840 },
>> - .hw_settle = (unsigned int []) { 15, 100, 200, 300, 400, 500,
>> 600, 700,
>> - 1000, 2000, 4000, 8000, 16000, 32000,
>> - 64000, 128000 },
>> -};
>> -
>> -static const struct adc_tm5_data adc_tm_hc_data_pmic = {
>> - .full_scale_code_volt = 0x70e4,
>> - .decimation = (unsigned int []) { 256, 512, 1024 },
>> - .hw_settle = (unsigned int []) { 0, 100, 200, 300, 400, 500,
>> 600, 700,
>> - 1000, 2000, 4000, 6000, 8000, 10000 },
>> - .is_hc = true,
>> -};
>> -
Thanks,
Jishnu
^ permalink raw reply
* RE: [RFC 19/28] media: dt-bindings: media: renesas,vsp1: Document RZ/{G2L,V2L} VSPD bindings
From: Biju Das @ 2022-01-23 14:47 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Rob Herring, Mauro Carvalho Chehab, Kieran Bingham,
linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, Geert Uytterhoeven, Chris Paterson,
Biju Das, Prabhakar Mahadev Lad
In-Reply-To: <Yeydyu+jg9cNObhN@pendragon.ideasonboard.com>
Hi Laurent,
Thanks for the feedback.
> Subject: Re: [RFC 19/28] media: dt-bindings: media: renesas,vsp1: Document
> RZ/{G2L,V2L} VSPD bindings
>
> Hi Biju,
>
> On Sat, Jan 22, 2022 at 11:23:32AM +0000, Biju Das wrote:
> > > Subject: Re: [RFC 19/28] media: dt-bindings: media: renesas,vsp1:
> > > Document RZ/{G2L,V2L} VSPD bindings
> > >
> > > On Wed, Jan 12, 2022 at 05:46:03PM +0000, Biju Das wrote:
> > > > Document VSPD found in RZ/G2L and RZ/V2L family SoC's.
> > > >
> > > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > > > ---
> > > > Documentation/devicetree/bindings/media/renesas,vsp1.yaml | 4
> > > > +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> > > > b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> > > > index 990e9c1dbc43..b27ee23d2b29 100644
> > > > --- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> > > > +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> > > > @@ -19,6 +19,7 @@ properties:
> > > > enum:
> > > > - renesas,vsp1 # R-Car Gen2 and RZ/G1
> > > > - renesas,vsp2 # R-Car Gen3 and RZ/G2
> > > > + - renesas,vsp2-r9a07g044 # RZ/G2L and RZ/V2L
>
> The commit message should explain why a new device-specific compatible
> value is needed.
OK. Will add this in next version.
Basically It does not have version register compared to other SoC's supported by
this driver.
>
> > > >
> > > > reg:
> > > > maxItems: 1
> > > > @@ -27,7 +28,8 @@ properties:
> > > > maxItems: 1
> > > >
> > > > clocks:
> > > > - maxItems: 1
> > > > + minItems: 1
> > > > + maxItems: 3
> > >
> > > You have to define what each one is once you have more than 1.
> >
> > Agreed, Will define each clocks.
>
> This should also be conditioned by the compatible string, to have maxItems
> set to 1 for renesas,vsp1 and renesas,vsp2, and 3 for renesas,vsp2-
> r9a07g044.
Agreed.
Regards,
Biju
>
> > > > power-domains:
> > > > maxItems: 1
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH V3 4/4] thermal: qcom: add support for PMIC5 Gen2 ADCTM
From: Jishnu Prakash @ 2022-01-23 14:46 UTC (permalink / raw)
To: Jonathan Cameron
Cc: agross, bjorn.andersson, devicetree, mka, dmitry.baryshkov,
robh+dt, knaack.h, lars, pmeerw, manivannan.sadhasivam,
linus.walleij, quic_kgunda, quic_aghayal, daniel.lezcano,
rui.zhang, quic_subbaram, jic23, amitk, Thara Gopinath,
Rafael J. Wysocki, linux-pm, linux-arm-msm, linux-kernel,
linux-arm-msm-owner, linux-iio
In-Reply-To: <20211126184613.00002816@Huawei.com>
Hi Jonathan,
On 11/27/2021 12:16 AM, Jonathan Cameron wrote:
> On Tue, 23 Nov 2021 11:27:04 +0530
> Jishnu Prakash <quic_jprakash@quicinc.com> wrote:
>
>> Add support for PMIC5 Gen2 ADC_TM, used on PMIC7 chips. It is a
>> close counterpart of PMIC7 ADC and has the same functionality as
>> PMIC5 ADC_TM, for threshold monitoring and interrupt generation.
>> It is present on PMK8350 alone, like PMIC7 ADC and can be used
>> to monitor up to 8 ADC channels, from any of the PMIC7 PMICs
>> having ADC on a target, through PBS(Programmable Boot Sequence).
>>
>> Signed-off-by: Jishnu Prakash <quic_jprakash@quicinc.com>
> Just one note on using put_unaligned_le16() below. Otherwise, from
> a drive by review point of view it looks fine to someone not that
> familiar with the driver or thermal :)
>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
>> ---
>> drivers/thermal/qcom/qcom-spmi-adc-tm5.c | 375 ++++++++++++++++++++++++++++++-
>> 1 file changed, 372 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
>> index fc8cd45..a7b33a8 100644
>> --- a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
>> +++ b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
>> @@ -4,7 +4,10 @@
>> *
>> * Based on original driver:
>> * Copyright (c) 2012-2020, The Linux Foundation. All rights reserved.
>> + *
>> + * Copyright (c) 2021 Qualcomm Innovation Center, Inc. All rights reserved.
>> */
>> +
>> + /* Low temperature corresponds to high voltage threshold */
>> + if (low != -INT_MAX) {
>> + channel->high_thr_en = true;
>> + adc_code = qcom_adc_tm5_gen2_temp_res_scale(low);
>> +
>> + buf[11] = adc_code & 0xff;
>> + buf[12] = adc_code >> 8;
> looks like a little endian put though not necessarily aligned so
> put_unaligned_le16() preferred to open coding it. Same in similar places.
> Not my area though so maintainer may not care as much.
I'll use put_unaligned_le16 as suggested, in similar places in the next
post.
>> + } else {
>> + channel->high_thr_en = false;
>> + }
>> +
>> + buf[13] = ADC_TM_GEN2_MEAS_EN;
>> + if (channel->high_thr_en)
>> + buf[13] |= ADC_TM5_GEN2_HIGH_THR_INT_EN;
Thanks,
Jishnu
^ permalink raw reply
* Re: [PATCH V3 0/4] thermal: qcom: Add support for PMIC5 Gen2 ADC_TM
From: Jishnu Prakash @ 2022-01-23 14:43 UTC (permalink / raw)
To: Jonathan Cameron
Cc: agross, bjorn.andersson, devicetree, mka, dmitry.baryshkov,
robh+dt, knaack.h, lars, pmeerw, manivannan.sadhasivam,
linus.walleij, quic_kgunda, quic_aghayal, daniel.lezcano,
rui.zhang, quic_subbaram, jic23, amitk, linux-arm-msm,
linux-kernel, linux-arm-msm-owner, linux-iio, linux-pm
In-Reply-To: <20211126182911.00005110@Huawei.com>
Hi Jonathan,
On 11/26/2021 11:59 PM, Jonathan Cameron wrote:
> On Tue, 23 Nov 2021 11:27:00 +0530
> Jishnu Prakash <quic_jprakash@quicinc.com> wrote:
>
>> Made following changes in this post:
>> Addressed comments given by Jonathan for qcom-spmi-adc-tm5.yaml.
>> Addressed comments given by Dmitry and Jonathan for qcom-spmi-adc-tm5.c.
>> Split patch for qcom-spmi-adc-tm5.c into two parts, one to refactor
>> code to support multiple device generations and the second to add
>> actual Gen2 ADC_TM changes.
> Series is missing a change log. Either in cover letter, or in
> individual patches after the --
>
> Jonathan
I'll add the change log in the cover letter in the next post.
>
>> Jishnu Prakash (4):
>> dt-bindings: thermal: qcom: add PMIC5 Gen2 ADC_TM bindings
>> iio: adc: qcom-vadc-common: add reverse scaling for PMIC5 Gen2 ADC_TM
>> thermal: qcom: Add support for multiple generations of devices
>> thermal: qcom: add support for PMIC5 Gen2 ADCTM
>>
>> .../bindings/thermal/qcom-spmi-adc-tm5.yaml | 110 ++++-
>> drivers/iio/adc/qcom-vadc-common.c | 11 +
>> drivers/thermal/qcom/qcom-spmi-adc-tm5.c | 451 +++++++++++++++++++--
>> include/linux/iio/adc/qcom-vadc-common.h | 2 +
>> 4 files changed, 541 insertions(+), 33 deletions(-)
>>
Thanks,
Jishnu
^ permalink raw reply
* Re: [PATCH RFC 00/11] dmaengine: bcm2835: add BCM2711 40-bit DMA support
From: Stefan Wahren @ 2022-01-23 14:08 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Florian Fainelli, Nicolas Saenz Julienne
Cc: Ray Jui, Scott Branden, bcm-kernel-feedback-list, dmaengine,
Phil Elwell, devicetree, linux-arm-kernel, Lukas Wunner,
linux-rpi-kernel
In-Reply-To: <1640606743-10993-1-git-send-email-stefan.wahren@i2se.com>
Hi,
Am 27.12.21 um 13:05 schrieb Stefan Wahren:
> The BCM2711 has 4 DMA channels with a 40-bit address range, allowing them
> to access the full 4GB of memory on a Pi 4. This patch series serves as a
> basis for a discussion (just compile tested, so don't expect anything working)
> which include the following points:
>
> * correct DT binding and representation for BCM2711
>
> According to the vendor DTS [1] the 4 DMA channels are connected to SCB.
> I'm not sure how this is properly adapted to the mainline DT.
>
> * general implementation approach
>
> The vendor approach mapped all the BCM2835 control block bits to the BCM2711
> layout and the rest of the differences are handled by a lot of is_40bit_channel
> conditions. An advantage of this is the small amount of changes to the driver.
> But on the down side the code is now much harder to understand and maintain.
>
> This series tries to implement this feature in a more cleaner way
> while keeping it in the bcm2835-dma driver. Before this series the driver
> has ~ 1000 lines and after that ~ 1500 lines.
>
> So the question is this approach acceptable?
>
> Patches 1 - 3 are just clean-ups.
>
> Disclaimer: my knowledge about the DMA controller is very limited
>
> More information:
>
> https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf
>
> [1] - https://github.com/raspberrypi/linux/blob/561deffcf471ba0f7bd48541d06a79d5aa38d297/arch/arm/boot/dts/bcm2711-rpi-ds.dtsi#L47
> [2] - https://github.com/raspberrypi/linux/commit/44364bd140b0bc9187c881fbdc4ee358961059d5
would be nice to get some input aka gentle ping.
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: rockchip: Add Bananapi R2 Pro
From: Frank Wunderlich @ 2022-01-23 13:51 UTC (permalink / raw)
To: linux-rockchip
Cc: Frank Wunderlich, Rob Herring, Heiko Stuebner, Peter Geis,
Johan Jonker, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20220123135116.136846-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
This patch adds Devicetree for Bananapi R2 Pro based on RK3568.
Add uart/sd/emmc/i2c/rk809/tsadc nodes for basic function.
Gmac0 is directly connected to wan-port so usable without additional
driver.
On gmac1 there is a switch (rtl8367rb) connected which have not yet a
driver in mainline.
Patch also prepares nodes for GPIO header.
Co-developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
changes in v2:
- drop alias for gmac1 - currently unused due to missing switch driver
- verified / changed pinctrl of pwm/spi/uart/i2c
- add sharing information for con2 functions
- always power on vccio1 iodomain (used for rtc)
- drop V00 from model
- change leds (change names, drop label, add pinctrl, use color+function)
- add fan
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3568-bpi-r2-pro.dts | 461 ++++++++++++++++++
2 files changed, 462 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 479906f3ad7b..70007b370d87 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -58,3 +58,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-bpi-r2-pro.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
new file mode 100644
index 000000000000..738b62adbef8
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Author: Frank Wunderlich <frank-w@public-files.de>
+ *
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3568.dtsi"
+
+/ {
+ model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
+ compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 = &gmac0;
+ mmc0 = &sdmmc0;
+ mmc1 = &sdhci;
+ };
+
+ chosen: chosen {
+ stdout-path = "serial2:1500000n8";
+ bootargs = "earlycon=uart8250,mmio32,0xfe660000";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&blue_led_pin &green_led_pin>;
+
+ blue_led: led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio0 RK_PD6 GPIO_ACTIVE_HIGH>;
+ };
+
+ green_led: led-1 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "on";
+ function = LED_FUNCTION_POWER;
+ gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ dc_12v: dc-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcc5v0_sys: vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_12v>;
+ };
+};
+
+&gmac0 {
+ assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>;
+ assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>, <&cru CLK_MAC0_2TOP>;
+ clock_in_out = "input";
+ phy-handle = <&rgmii_phy0>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac0_miim
+ &gmac0_tx_bus2
+ &gmac0_rx_bus2
+ &gmac0_rgmii_clk
+ &gmac0_rgmii_bus>;
+
+ snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ /* Reset time is 20ms, 100ms for rtl8211f */
+ snps,reset-delays-us = <0 20000 100000>;
+
+ tx_delay = <0x3c>;
+ rx_delay = <0x2f>;
+
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int>;
+ rockchip,system-power-controller;
+ vcc1-supply = <&vcc3v3_sys>;
+ vcc2-supply = <&vcc3v3_sys>;
+ vcc3-supply = <&vcc3v3_sys>;
+ vcc4-supply = <&vcc3v3_sys>;
+ vcc5-supply = <&vcc3v3_sys>;
+ vcc6-supply = <&vcc3v3_sys>;
+ vcc7-supply = <&vcc3v3_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc3v3_sys>;
+ wakeup-source;
+
+ regulators {
+ vdd_logic: DCDC_REG1 {
+ regulator-name = "vdd_logic";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-init-microvolt = <900000>;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: DCDC_REG2 {
+ regulator-name = "vdd_gpu";
+ regulator-init-microvolt = <900000>;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vdd_npu: DCDC_REG4 {
+ regulator-name = "vdd_npu";
+ regulator-init-microvolt = <900000>;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG5 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v9_image: LDO_REG1 {
+ regulator-name = "vdda0v9_image";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v9: LDO_REG2 {
+ regulator-name = "vdda_0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v9_pmu: LDO_REG3 {
+ regulator-name = "vdda0v9_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ vccio_acodec: LDO_REG4 {
+ regulator-name = "vccio_acodec";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd: LDO_REG5 {
+ regulator-name = "vccio_sd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_pmu: LDO_REG6 {
+ regulator-name = "vcc3v3_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcca_1v8: LDO_REG7 {
+ regulator-name = "vcca_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pmu: LDO_REG8 {
+ regulator-name = "vcca1v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcca1v8_image: LDO_REG9 {
+ regulator-name = "vcca1v8_image";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v3: SWITCH_REG1 {
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_sd: SWITCH_REG2 {
+ regulator-name = "vcc3v3_sd";
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&i2c5 {
+ /* pin 3 (SDA) + 4 (SCL) of header con2 */
+ status = "disabled";
+};
+
+&mdio0 {
+ rgmii_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x0>;
+ };
+};
+
+&pinctrl {
+ leds {
+ blue_led_pin: blue-led-pin {
+ rockchip,pins = <0 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ green_led_pin: green-led-pin {
+ rockchip,pins = <0 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int: pmic_int {
+ rockchip,pins =
+ <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pmu_io_domains {
+ pmuio1-supply = <&vcc3v3_pmu>;
+ pmuio2-supply = <&vcc3v3_pmu>;
+ vccio1-supply = <&vccio_acodec>;
+ vccio3-supply = <&vccio_sd>;
+ vccio4-supply = <&vcc_1v8>;
+ vccio5-supply = <&vcc_3v3>;
+ vccio6-supply = <&vcc_3v3>;
+ vccio7-supply = <&vcc_3v3>;
+ status = "okay";
+};
+
+&pwm8 {
+ /* fan 5v - gnd - pwm */
+ status = "okay";
+};
+
+&pwm10 {
+ /* pin 7 of header con2 */
+ status = "disabled";
+};
+
+&pwm11 {
+ /* pin 15 of header con2 */
+ status = "disabled";
+};
+
+&pwm12 {
+ /* pin 21 of header con2 */
+ /* shared with uart9 + spi3 */
+ pinctrl-0 = <&pwm12m1_pins>;
+ status = "disabled";
+};
+
+&pwm13 {
+ /* pin 24 of header con2 */
+ /* shared with uart9 */
+ pinctrl-0 = <&pwm13m1_pins>;
+ status = "disabled";
+};
+
+&pwm14 {
+ /* pin 23 of header con2 */
+ /* shared with spi3 */
+ pinctrl-0 = <&pwm14m1_pins>;
+ status = "disabled";
+};
+
+&pwm15 {
+ /* pin 19 of header con2 */
+ /* shared with spi3 */
+ pinctrl-0 = <&pwm15m1_pins>;
+ status = "disabled";
+};
+
+&saradc {
+ vref-supply = <&vcca_1v8>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ max-frequency = <200000000>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
+ status = "okay";
+};
+
+&sdmmc0 {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vccio_sd>;
+ status = "okay";
+};
+
+&spi3 {
+ /* pin 19 (MO) + 21 (MI) + 23 (CK) of header con2 */
+ /* shared with pwm12/14/15 and uart9 */
+ pinctrl-0 = <&spi3m1_pins>;
+ status = "disabled";
+};
+
+&tsadc {
+ status = "okay";
+};
+
+&uart0 {
+ /* pin 8 (TX) + 10 (RX) (RTS:16, CTS:18) of header con2 */
+ status = "disabled";
+};
+
+&uart2 {
+ /* debug-uart */
+ status = "okay";
+};
+
+&uart7 {
+ /* pin 11 (TX) + 13 (RX) of header con2 */
+ pinctrl-0 = <&uart7m1_xfer>;
+ status = "disabled";
+};
+
+&uart9 {
+ /* pin 21 (TX) + 24 (RX) of header con2 */
+ /* shared with pwm13 and pwm12/spi3 */
+ pinctrl-0 = <&uart9m1_xfer>;
+ status = "disabled";
+};
--
2.25.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: rockchip: Add BananaPi R2 Pro Board
From: Frank Wunderlich @ 2022-01-23 13:51 UTC (permalink / raw)
To: linux-rockchip
Cc: Frank Wunderlich, Rob Herring, Heiko Stuebner, Peter Geis,
Johan Jonker, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20220123135116.136846-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
Add Devicetree Binding for Bananapi R2 Pro Board based on rk3568 SoC
Co-developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 4aed16176434..33d6423fe6c3 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -651,6 +651,11 @@ properties:
- const: rockchip,rk3568-evb1-v10
- const: rockchip,rk3568
+ - description: Rockchip RK3568 Banana Pi R2 Pro
+ items:
+ - const: rockchip,rk3568-bpi-r2pro
+ - const: rockchip,rk3568
+
additionalProperties: true
...
--
2.25.1
^ permalink raw reply related
* [PATCH v2 0/2] Add BananaPi R2 Pro board
From: Frank Wunderlich @ 2022-01-23 13:51 UTC (permalink / raw)
To: linux-rockchip
Cc: Frank Wunderlich, Rob Herring, Heiko Stuebner, Peter Geis,
Johan Jonker, devicetree, linux-arm-kernel, linux-kernel
From: Frank Wunderlich <frank-w@public-files.de>
This Series adds RK3568 based Bananapi R2 Board.
changes in v2:
- rebase on 5.17-rc1
- dropped patch for fixing dtbs_check (sent separately)
- verified pins on gpio-header (con2) and changed pinctrl where needed
- changed led part
Frank Wunderlich (2):
dt-bindings: rockchip: Add BananaPi R2 Pro Board
arm64: dts: rockchip: Add Bananapi R2 Pro
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3568-bpi-r2-pro.dts | 461 ++++++++++++++++++
3 files changed, 467 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
--
2.25.1
^ permalink raw reply
* [PATCH v2] arm64: dts: rk3568: drop pclk_xpcs from gmac0
From: Frank Wunderlich @ 2022-01-23 13:35 UTC (permalink / raw)
To: linux-rockchip
Cc: Frank Wunderlich, Rob Herring, Heiko Stuebner, Michael Riesch,
devicetree, linux-arm-kernel, linux-kernel, Peter Geis
From: Frank Wunderlich <frank-w@public-files.de>
pclk_xpcs is not supported by mainline driver and breaks dtbs_check
following warnings occour, and many more
rk3568-evb1-v10.dt.yaml: ethernet@fe2a0000: clocks:
[[15, 386], [15, 389], [15, 389], [15, 184], [15, 180], [15, 181],
[15, 389], [15, 185], [15, 172]] is too long
From schema: Documentation/devicetree/bindings/net/snps,dwmac.yaml
rk3568-evb1-v10.dt.yaml: ethernet@fe2a0000: clock-names:
['stmmaceth', 'mac_clk_rx', 'mac_clk_tx', 'clk_mac_refout', 'aclk_mac',
'pclk_mac', 'clk_mac_speed', 'ptp_ref', 'pclk_xpcs'] is too long
From schema: Documentation/devicetree/bindings/net/snps,dwmac.yaml
after removing it, the clock and other warnings are gone.
pclk_xpcs on gmac is used to support QSGMII, but this requires a driver
supporting it.
Once xpcs support is introduced, the clock can be added to the
documentation and both controllers.
Fixes: b8d41e5053cd ("arm64: dts: rockchip: add gmac0 node to rk3568")
Co-developed-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Michael Riesch <michael.riesch@wolfvision.net>
---
changes in v2:
- rebase on 5.17-rc1
- separate from bpi-r2pro series
- changed commit-message
---
arch/arm64/boot/dts/rockchip/rk3568.dtsi | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
index 2fd313a295f8..d91df1cde736 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -32,13 +32,11 @@ gmac0: ethernet@fe2a0000 {
clocks = <&cru SCLK_GMAC0>, <&cru SCLK_GMAC0_RX_TX>,
<&cru SCLK_GMAC0_RX_TX>, <&cru CLK_MAC0_REFOUT>,
<&cru ACLK_GMAC0>, <&cru PCLK_GMAC0>,
- <&cru SCLK_GMAC0_RX_TX>, <&cru CLK_GMAC0_PTP_REF>,
- <&cru PCLK_XPCS>;
+ <&cru SCLK_GMAC0_RX_TX>, <&cru CLK_GMAC0_PTP_REF>;
clock-names = "stmmaceth", "mac_clk_rx",
"mac_clk_tx", "clk_mac_refout",
"aclk_mac", "pclk_mac",
- "clk_mac_speed", "ptp_ref",
- "pclk_xpcs";
+ "clk_mac_speed", "ptp_ref";
resets = <&cru SRST_A_GMAC0>;
reset-names = "stmmaceth";
rockchip,grf = <&grf>;
--
2.25.1
^ permalink raw reply related
* Re: Aw: Re: [PATCH v1 1/3] dts64: rk3568: drop pclk_xpcs from gmac0
From: Heiko Stuebner @ 2022-01-23 13:38 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Peter Geis, Johan Jonker, Frank Wunderlich,
open list:ARM/Rockchip SoC..., Rob Herring, devicetree,
arm-mail-list, Linux Kernel Mailing List
In-Reply-To: <trinity-d0efbf68-ed45-47d4-97b3-d3788c5a9de6-1642863025116@3c-app-gmx-bap44>
Hi Frank,
Am Samstag, 22. Januar 2022, 15:50:25 CET schrieb Frank Wunderlich:
> i plan to send a v2 of the series after 5.17-rc1 is out, because i have now verified
> the functions from gpio header and found some pinctrl-changes. V1 had only prepared
> the nodes to know which devices are present on this header.
>
> should i include this patch again or do you pull it from v1 (maybe as fix)?
I do plan to include this as fix after -rc1, but I just saw that you already sent
a separate patch of it, so I'll take that one instead :-)
Heiko
>
> regards Frank
>
>
> > Gesendet: Montag, 17. Januar 2022 um 22:05 Uhr
> > Von: "Heiko Stübner" <heiko@sntech.de>
>
> > From looking at the documentation I got the impression that the
> > pclk_xpcs is related to the separate qsgmii_pcs in the memory map.
> >
> > So yes, I fully agree to dropping this clock from here and then adding
> > them to whatever ip block really needs it.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox