* RE: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
From: Klymenko, Anatoliy @ 2024-03-30 2:02 UTC (permalink / raw)
To: Conor Dooley
Cc: Krzysztof Kozlowski, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Simek, Michal, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Tomi Valkeinen,
dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-media@vger.kernel.org
In-Reply-To: <20240329-overture-tank-d20888f2cb6e@spud>
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Friday, March 29, 2024 8:47 AM
> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Maxime Ripard
> <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>;
> David Airlie <airlied@gmail.com>; Daniel Vetter <daniel@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>; Andrzej Hajda
> <andrzej.hajda@intel.com>; Neil Armstrong <neil.armstrong@linaro.org>;
> Robert Foss <rfoss@kernel.org>; Jonas Karlman <jonas@kwiboo.se>; Jernej
> Skrabec <jernej.skrabec@gmail.com>; Rob Herring <robh+dt@kernel.org>;
> Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley
> <conor+dt@kernel.org>; Mauro Carvalho Chehab <mchehab@kernel.org>;
> Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>; dri-
> devel@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-
> media@vger.kernel.org
> Subject: Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
>
> On Fri, Mar 29, 2024 at 12:38:33AM +0000, Klymenko, Anatoliy wrote:
> > Thank you for the feedback.
> > > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> > > Subject: Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
> > > On 22/03/2024 20:12, Klymenko, Anatoliy wrote:
> > > >> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> > > >> On 21/03/2024 21:43, Anatoliy Klymenko wrote:
> > > >>> diff --git a/include/dt-bindings/media/media-bus-format.h
> > > >>> b/include/dt-
> > > >> bindings/media/media-bus-format.h
> > > >>> new file mode 100644
> > > >>> index 000000000000..60fc6e11dabc
> > > >>> --- /dev/null
> > > >>> +++ b/include/dt-bindings/media/media-bus-format.h
> > > >>> @@ -0,0 +1,177 @@
> > > >>> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
> > > >>> +/*
> > > >>> + * Media Bus API header
> > > >>> + *
> > > >>> + * Copyright (C) 2009, Guennadi Liakhovetski
> > > >>> +<g.liakhovetski@gmx.de>
> > > >>> + *
> > > >>> + * This program is free software; you can redistribute it and/or
> > > >>> +modify
> > > >>> + * it under the terms of the GNU General Public License version 2
> > > >>> +as
> > > >>> + * published by the Free Software Foundation.
> > > >>
> > > >> That's not true. Your SPDX tells something entirely different.
> > > >>
> > > >
> > > > Thank you - I'll see how to fix it.
> > > >
> > > >> Anyway, you did not explain why you need to copy anything anywhere.
> > > >>
> > > >> Specifically, random hex values *are not bindings*.
> > > >>
> > > >
> > > > The same media bus format values are being used by the reference
> > > > driver in patch #9. And, as far as I know, we cannot use headers from
> > > > Linux API headers directly (at least I
> > >
> > > I don't understand what does it mean. You can use in your driver
> whatever
> > > headers you wish, I don't care about them.
> > >
> > >
> > > noticed the same pattern in ../dt-bindings/sdtv-standarts.h for instance).
> > > What would be the best approach to reusing the same defines on DT and
> > > driver sides from your point of view? Symlink maybe?
> > > >
> > >
> > > Wrap your messages to match mailing list discussion style. There are no
> > > defines used in DT. If there are, show me them in *THIS* or other
> > > *upstreamed* (being upstreamed) patchset.
> > >
> >
> > Sorry, I didn't explain properly what I'm trying to achieve. I need to
> > create a DT node property that represents video signal format, one of
> > MEDIA_BUS_FMT_* from include/uapi/linux/media-bus-format.h. It would
> be
> > nice to reuse the same symbolic values in the device tree. What is the
> > best approach here? Should I create a separate header in
> > include/dt-bindings with the same or similar (to avoid multiple
> > definition errors) defines, or is it better to create a symlink to
> > media-bus-format.h like include/dt-bindings/linux-event-codes.h?
>
> Isn't there already a property for this, described in
> Documentation/devicetree/bindings/media/xilinx/video.txt
> ?
Those properties are very similar, indeed but not exactly the same. The
one you noticed maps Xilinx video data format on AXI4-Stream transport
that covers color space and chroma subsampling only. The rest of the
signal attributes are either conventional or left out. MEDIA_BUS_FMT_*
collection is more specific and embeds additional information about
video signals, like bits per component and component ordering.
^ permalink raw reply
* [PATCH 2/2] arm64: dts: allwinner: Add Tanix TX1 support
From: Andre Przywara @ 2024-03-30 1:32 UTC (permalink / raw)
To: Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-sunxi
In-Reply-To: <20240330013243.17943-1-andre.przywara@arm.com>
The Tanix TX1 is a tiny TV box with the Allwinner H313 SoC. The box
features no Ethernet or an SD card slot, which makes booting from it
somewhat interesting: Pressing the hidden FEL button and using a USB-A
to USB-A cable to upload code from a host PC is one way to run mainline.
The box features:
- Allwinner H313 SoC (4 * Arm Cortex-A53 cores)
- 1 or 2 GB DRAM
- 8 or 16 GB eMMC flash
- SCI S9082H WiFi chip
- HDMI port
- one USB 2.0 port
- 3.5mm AV port
- barrel plug 5V DC input via barrel plug
The devicetree covers most peripherals.
The eMMC did not work properly in HS200 speed mode, so this mode property
is omitted. HS-DDR seems to work fine.
The blue LED is connected to the same GPIO pin as the red LED, just
using the opposite polarity. Apparently there is no way of describing
this in DT, so the red LED is omitted.
Next to the FEL button is a hidden button, that can be pushed by using
something like a paperclip, through the ventilation vents of the case.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-h313-tanix-tx1.dts | 184 ++++++++++++++++++
2 files changed, 185 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h313-tanix-tx1.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 294921f12b738..c8ac2823677f2 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h313-tanix-tx1.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h313-tanix-tx1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h313-tanix-tx1.dts
new file mode 100644
index 0000000000000..622f4290057a8
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h313-tanix-tx1.dts
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2024 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "Tanix TX1";
+ compatible = "oranth,tanix-tx1", "allwinner,sun50i-h616";
+
+ aliases {
+ serial0 = &uart0;
+ ethernet0 = &sdio_wifi;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ key {
+ label = "hidden";
+ linux,code = <BTN_0>;
+ gpios = <&pio 7 9 GPIO_ACTIVE_LOW>; /* PH9 */
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ function = LED_FUNCTION_POWER;
+ color = <LED_COLOR_ID_BLUE>;
+ gpios = <&pio 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
+ default-state = "on";
+ };
+ };
+
+ wifi_pwrseq: pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rtc CLK_OSC32K_FANOUT>;
+ clock-names = "ext_clock";
+ pinctrl-0 = <&x32clk_fanout_pin>;
+ pinctrl-names = "default";
+ reset-gpios = <&pio 6 18 GPIO_ACTIVE_LOW>; /* PG18 */
+ };
+
+ reg_vcc5v: vcc5v {
+ /* board wide 5V supply directly from the DC input */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ir {
+ status = "okay";
+};
+
+&mmc1 {
+ vmmc-supply = <®_dldo1>;
+ vqmmc-supply = <®_aldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ sdio_wifi: wifi@1 {
+ reg = <1>;
+ };
+};
+
+&mmc2 {
+ vmmc-supply = <®_dldo1>;
+ vqmmc-supply = <®_aldo1>;
+ bus-width = <8>;
+ non-removable;
+ max-frequency = <100000000>;
+ cap-mmc-hw-reset;
+ mmc-ddr-1_8v;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&pio {
+ vcc-pc-supply = <®_aldo1>;
+ vcc-pf-supply = <®_dldo1>;
+ vcc-pg-supply = <®_aldo1>;
+ vcc-ph-supply = <®_dldo1>;
+ vcc-pi-supply = <®_dldo1>;
+};
+
+&r_i2c {
+ status = "okay";
+
+ axp313: pmic@36 {
+ compatible = "x-powers,axp313a";
+ reg = <0x36>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+
+ vin1-supply = <®_vcc5v>;
+ vin2-supply = <®_vcc5v>;
+ vin3-supply = <®_vcc5v>;
+
+ regulators {
+ /* Supplies VCC-PLL, so needs to be always on. */
+ reg_aldo1: aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8";
+ };
+
+ /* Supplies VCC-IO, so needs to be always on. */
+ reg_dldo1: dldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc3v3";
+ };
+
+ reg_dcdc1: dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <990000>;
+ regulator-name = "vdd-gpu-sys";
+ };
+
+ reg_dcdc2: dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1120000>;
+ regulator-name = "vdd-cpu";
+ };
+
+ reg_dcdc3: dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vdd-dram";
+ };
+ };
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_ph_pins>;
+ status = "okay";
+};
+
+&usbotg {
+ dr_mode = "host"; /* USB A type receptable */
+ status = "okay";
+};
+
+&usbphy {
+ status = "okay";
+};
--
2.35.8
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: allwinner: Add Tanix TX1 support
From: Andre Przywara @ 2024-03-30 1:32 UTC (permalink / raw)
To: Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-sunxi
Tanix TX1 is a tiny TV box (60% of a credit card) with an Allwinner
H313 SoC. This seems to be the same as the H616, just the "bad bin"
version, limited to 1.3 GHz.
The box has no Ethernet or SD card slot, which makes booting from it
somewhat interesting: Pressing the hidden FEL button and using a USB-A
to USB-A cable to upload code from a host PC is one way to run mainline.
The box features a minimal set of peripherals: one USB port, 8 or 16GB
of eMMC, an HDMI port and an (unsupported) SCI S9082H WiFi chip.
Patch 1 adds the DT binding for the board compatible, I refrained from
using the H313 name here, since it seems to be functionally identical to
the H616.
Patch 2 adds the devicetree.
There is a blue and a red LED, both connected to the same GPIO pin, but
with different polarities, so it's only either one of them enabled.
I did not find a way to describe this in DT, so I omitted the red LED.
Please have a look!
Cheers,
Andre
Andre Przywara (2):
dt-bindings: arm: sunxi: document Tanix TX1 name
arm64: dts: allwinner: Add Tanix TX1 support
.../devicetree/bindings/arm/sunxi.yaml | 5 +
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-h313-tanix-tx1.dts | 184 ++++++++++++++++++
3 files changed, 190 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h313-tanix-tx1.dts
--
2.35.8
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: sunxi: document Tanix TX1 name
From: Andre Przywara @ 2024-03-30 1:32 UTC (permalink / raw)
To: Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-sunxi
In-Reply-To: <20240330013243.17943-1-andre.przywara@arm.com>
The Tanix TX1 is a tiny TV box with the Allwinner H313 SoC, a lower bin
version of the Allwinner H616. It comes with no SD card slot or Ethernet
port.
Add the board/SoC compatible string pair to the list of known boards.
Since the H313 does not look different from a software point of view,
we keep the H616 compatible string.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 6fe137605ba53..9530235941cc3 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -865,6 +865,11 @@ properties:
- const: t95,t95max-axp313
- const: allwinner,sun50i-h616
+ - description: Tanix TX1
+ items:
+ - const: oranth,tanix-tx1
+ - const: allwinner,sun50i-h616
+
- description: Tanix TX6
items:
- const: oranth,tanix-tx6
--
2.35.8
^ permalink raw reply related
* Re: [PATCH v1 3/3] phy: freescale: imx8q-hsio: Add i.MX8Q HSIO PHY driver support
From: kernel test robot @ 2024-03-30 0:51 UTC (permalink / raw)
To: Richard Zhu, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, frank.li
Cc: oe-kbuild-all, hongxing.zhu, linux-phy, devicetree,
linux-arm-kernel, linux-kernel, kernel, linux-imx
In-Reply-To: <1711699790-16494-4-git-send-email-hongxing.zhu@nxp.com>
Hi Richard,
kernel test robot noticed the following build errors:
[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v6.9-rc1 next-20240328]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Richard-Zhu/dt-bindings-phy-Add-i-MX8Q-HSIO-SerDes-PHY-binding/20240329-162937
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link: https://lore.kernel.org/r/1711699790-16494-4-git-send-email-hongxing.zhu%40nxp.com
patch subject: [PATCH v1 3/3] phy: freescale: imx8q-hsio: Add i.MX8Q HSIO PHY driver support
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20240330/202403300825.mjcHpoRu-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240330/202403300825.mjcHpoRu-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403300825.mjcHpoRu-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/phy/freescale/phy-fsl-imx8q-hsio.c: In function 'imx8q_hsio_set_mode':
>> drivers/phy/freescale/phy-fsl-imx8q-hsio.c:367:15: error: implicit declaration of function 'FIELD_PREP' [-Werror=implicit-function-declaration]
367 | val = FIELD_PREP(MODE_MASK, val);
| ^~~~~~~~~~
cc1: some warnings being treated as errors
vim +/FIELD_PREP +367 drivers/phy/freescale/phy-fsl-imx8q-hsio.c
355
356 static int imx8q_hsio_set_mode(struct phy *phy, enum phy_mode mode,
357 int submode)
358 {
359 u32 val;
360 struct imx8q_hsio_lane *lane = phy_get_drvdata(phy);
361 struct imx8q_hsio_priv *priv = lane->priv;
362
363 if (lane->lane_mode != mode)
364 return -EINVAL;
365
366 val = (mode == PHY_MODE_PCIE) ? MODE_PCIE : MODE_SATA;
> 367 val = FIELD_PREP(MODE_MASK, val);
368 regmap_update_bits(priv->phy, lane->phy_off + CTRL0, MODE_MASK, val);
369
370 switch (submode) {
371 case PHY_MODE_PCIE_RC:
372 val = FIELD_PREP(DEVICE_TYPE_MASK, PCI_EXP_TYPE_ROOT_PORT);
373 break;
374 case PHY_MODE_PCIE_EP:
375 val = FIELD_PREP(DEVICE_TYPE_MASK, PCI_EXP_TYPE_ENDPOINT);
376 break;
377 default: /* Support only PCIe EP and RC now. */
378 return 0;
379 }
380 if (submode)
381 regmap_update_bits(priv->ctrl, lane->ctrl_off + CTRL0,
382 DEVICE_TYPE_MASK, val);
383
384 return 0;
385 }
386
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
From: kernel test robot @ 2024-03-30 0:30 UTC (permalink / raw)
To: git, linux-media
Cc: oe-kbuild-all, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, Luigi311
In-Reply-To: <20240327231710.53188-19-git@luigi311.com>
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on media-tree/master]
[also build test WARNING on linuxtv-media-stage/master linus/master v6.9-rc1 next-20240328]
[cannot apply to sailus-media-tree/streams]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/git-luigi311-com/media-i2c-imx258-Remove-unused-defines/20240328-072629
base: git://linuxtv.org/media_tree.git master
patch link: https://lore.kernel.org/r/20240327231710.53188-19-git%40luigi311.com
patch subject: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20240330/202403300820.NEs0EOr7-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403300820.NEs0EOr7-lkp@intel.com/
dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml: properties:compatible: [{'enum': ['sony,imx258', 'sony,imx258-pdaf']}] is not of type 'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
>> Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml: properties:compatible: [{'enum': ['sony,imx258', 'sony,imx258-pdaf']}] is not of type 'object', 'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
--
>> Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml: ignoring, error in schema: properties: compatible
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH 4/4] regulator: axp20x: AXP717: Add boost regulator
From: Andre Przywara @ 2024-03-29 23:50 UTC (permalink / raw)
To: Chen-Yu Tsai, Lee Jones, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: devicetree, linux-kernel, linux-sunxi, Jernej Skrabec,
Samuel Holland, Ryan Walklin, Chris Morgan
In-Reply-To: <20240329235033.25309-1-andre.przywara@arm.com>
The AXP717 also contains an adjustable boost regulator, to provide the
5V USB VBUS rail when running on battery.
Add the regulator description that states the voltage range this
regulator can cover.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/regulator/axp20x-regulator.c | 4 ++++
include/linux/mfd/axp20x.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 3907606b091f6..71407c5810941 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -143,6 +143,7 @@
#define AXP717_DCDC3_NUM_VOLTAGES 103
#define AXP717_DCDC_V_OUT_MASK GENMASK(6, 0)
#define AXP717_LDO_V_OUT_MASK GENMASK(4, 0)
+#define AXP717_BOOST_V_OUT_MASK GENMASK(7, 4)
#define AXP803_PWR_OUT_DCDC1_MASK BIT_MASK(0)
#define AXP803_PWR_OUT_DCDC2_MASK BIT_MASK(1)
@@ -829,6 +830,9 @@ static const struct regulator_desc axp717_regulators[] = {
AXP_DESC(AXP717, CPUSLDO, "cpusldo", "vin1", 500, 1400, 50,
AXP717_CPUSLDO_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO1_OUTPUT_CONTROL, BIT(4)),
+ AXP_DESC(AXP717, BOOST, "boost", "vin1", 4550, 5510, 64,
+ AXP717_BOOST_CONTROL, AXP717_BOOST_V_OUT_MASK,
+ AXP717_MODULE_EN_CONTROL, BIT(4)),
};
/* DCDC ranges shared with AXP813 */
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index 4dad54fdf67ee..5e86b976c4caa 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -486,6 +486,7 @@ enum {
AXP717_CLDO3,
AXP717_CLDO4,
AXP717_CPUSLDO,
+ AXP717_BOOST,
AXP717_REG_ID_MAX,
};
--
2.35.8
^ permalink raw reply related
* [PATCH 3/4] mfd: axp20x: AXP717: Add support for boost regulator
From: Andre Przywara @ 2024-03-29 23:50 UTC (permalink / raw)
To: Chen-Yu Tsai, Lee Jones, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: devicetree, linux-kernel, linux-sunxi, Jernej Skrabec,
Samuel Holland, Ryan Walklin, Chris Morgan
In-Reply-To: <20240329235033.25309-1-andre.przywara@arm.com>
The AXP717 also contains a boost regulator, to provide the 5V USB VBUS
rail when running on battery.
Add the registers to the MFD description to be able to use them from the
regulator driver.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/mfd/axp20x.c | 2 ++
include/linux/mfd/axp20x.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 48ce6ea693cea..62f3dd254d57b 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -209,6 +209,8 @@ static const struct regmap_access_table axp313a_volatile_table = {
};
static const struct regmap_range axp717_writeable_ranges[] = {
+ regmap_reg_range(AXP717_MODULE_EN_CONTROL, AXP717_MODULE_EN_CONTROL),
+ regmap_reg_range(AXP717_BOOST_CONTROL, AXP717_BOOST_CONTROL),
regmap_reg_range(AXP717_IRQ0_EN, AXP717_IRQ4_EN),
regmap_reg_range(AXP717_DCDC_OUTPUT_CONTROL, AXP717_CPUSLDO_CONTROL),
};
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index 8c0a33a2e9ce2..4dad54fdf67ee 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -115,6 +115,8 @@ enum axp20x_variants {
#define AXP313A_IRQ_STATE 0x21
#define AXP717_ON_INDICATE 0x00
+#define AXP717_MODULE_EN_CONTROL 0x19
+#define AXP717_BOOST_CONTROL 0x1e
#define AXP717_IRQ0_EN 0x40
#define AXP717_IRQ1_EN 0x41
#define AXP717_IRQ2_EN 0x42
--
2.35.8
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: mfd: x-powers,axp152: add boost regulator
From: Andre Przywara @ 2024-03-29 23:50 UTC (permalink / raw)
To: Chen-Yu Tsai, Lee Jones, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: devicetree, linux-kernel, linux-sunxi, Jernej Skrabec,
Samuel Holland, Ryan Walklin, Chris Morgan
In-Reply-To: <20240329235033.25309-1-andre.przywara@arm.com>
The X-Powers AXP717 contains a boost regulator, that it meant to provide
the 5V USB VBUS voltage when the devices operates on battery.
Add the name "boost" to the regexp describing the allowed node names,
to allow the regulator to be described in the devicetree.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
index b8e8db0d58e9c..14ab367fc8871 100644
--- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
+++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
@@ -274,7 +274,7 @@ properties:
Defines the work frequency of DC-DC in kHz.
patternProperties:
- "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo)$":
+ "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo|boost)$":
$ref: /schemas/regulator/regulator.yaml#
type: object
unevaluatedProperties: false
--
2.35.8
^ permalink raw reply related
* [PATCH 1/4] regulator: axp20x: AXP717: fix LDO supply rails and off-by-ones
From: Andre Przywara @ 2024-03-29 23:50 UTC (permalink / raw)
To: Chen-Yu Tsai, Lee Jones, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: devicetree, linux-kernel, linux-sunxi, Jernej Skrabec,
Samuel Holland, Ryan Walklin, Chris Morgan
In-Reply-To: <20240329235033.25309-1-andre.przywara@arm.com>
The X-Powers AXP717 PMIC has separate input supply pins for each group
of LDOs, so they are not all using the same DCDC1 input, as described
currently.
Replace the "supply" member of each LDO description with the respective
group supply name, so that the supply dependencies can be correctly
described in the devicetree.
Also fix two off-by-ones in the regulator macros, after some double
checking the numbers against the datasheet.
Fixes: d2ac3df75c3a ("regulator: axp20x: add support for the AXP717")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/regulator/axp20x-regulator.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 34fcdd82b2eaa..3907606b091f6 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -140,7 +140,7 @@
#define AXP717_DCDC1_NUM_VOLTAGES 88
#define AXP717_DCDC2_NUM_VOLTAGES 107
-#define AXP717_DCDC3_NUM_VOLTAGES 104
+#define AXP717_DCDC3_NUM_VOLTAGES 103
#define AXP717_DCDC_V_OUT_MASK GENMASK(6, 0)
#define AXP717_LDO_V_OUT_MASK GENMASK(4, 0)
@@ -766,7 +766,7 @@ static const struct linear_range axp717_dcdc1_ranges[] = {
static const struct linear_range axp717_dcdc2_ranges[] = {
REGULATOR_LINEAR_RANGE(500000, 0, 70, 10000),
REGULATOR_LINEAR_RANGE(1220000, 71, 87, 20000),
- REGULATOR_LINEAR_RANGE(1600000, 88, 107, 100000),
+ REGULATOR_LINEAR_RANGE(1600000, 88, 106, 100000),
};
static const struct linear_range axp717_dcdc3_ranges[] = {
@@ -790,40 +790,40 @@ static const struct regulator_desc axp717_regulators[] = {
AXP_DESC(AXP717, DCDC4, "dcdc4", "vin4", 1000, 3700, 100,
AXP717_DCDC4_CONTROL, AXP717_DCDC_V_OUT_MASK,
AXP717_DCDC_OUTPUT_CONTROL, BIT(3)),
- AXP_DESC(AXP717, ALDO1, "aldo1", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, ALDO1, "aldo1", "aldoin", 500, 3500, 100,
AXP717_ALDO1_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO0_OUTPUT_CONTROL, BIT(0)),
- AXP_DESC(AXP717, ALDO2, "aldo2", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, ALDO2, "aldo2", "aldoin", 500, 3500, 100,
AXP717_ALDO2_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO0_OUTPUT_CONTROL, BIT(1)),
- AXP_DESC(AXP717, ALDO3, "aldo3", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, ALDO3, "aldo3", "aldoin", 500, 3500, 100,
AXP717_ALDO3_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO0_OUTPUT_CONTROL, BIT(2)),
- AXP_DESC(AXP717, ALDO4, "aldo4", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, ALDO4, "aldo4", "aldoin", 500, 3500, 100,
AXP717_ALDO4_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO0_OUTPUT_CONTROL, BIT(3)),
- AXP_DESC(AXP717, BLDO1, "bldo1", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, BLDO1, "bldo1", "bldoin", 500, 3500, 100,
AXP717_BLDO1_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO0_OUTPUT_CONTROL, BIT(4)),
- AXP_DESC(AXP717, BLDO2, "bldo2", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, BLDO2, "bldo2", "bldoin", 500, 3500, 100,
AXP717_BLDO2_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO0_OUTPUT_CONTROL, BIT(5)),
- AXP_DESC(AXP717, BLDO3, "bldo3", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, BLDO3, "bldo3", "bldoin", 500, 3500, 100,
AXP717_BLDO3_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO0_OUTPUT_CONTROL, BIT(6)),
- AXP_DESC(AXP717, BLDO4, "bldo4", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, BLDO4, "bldo4", "bldoin", 500, 3500, 100,
AXP717_BLDO4_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO0_OUTPUT_CONTROL, BIT(7)),
- AXP_DESC(AXP717, CLDO1, "cldo1", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, CLDO1, "cldo1", "cldoin", 500, 3500, 100,
AXP717_CLDO1_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO1_OUTPUT_CONTROL, BIT(0)),
- AXP_DESC(AXP717, CLDO2, "cldo2", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, CLDO2, "cldo2", "cldoin", 500, 3500, 100,
AXP717_CLDO2_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO1_OUTPUT_CONTROL, BIT(1)),
- AXP_DESC(AXP717, CLDO3, "cldo3", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, CLDO3, "cldo3", "cldoin", 500, 3500, 100,
AXP717_CLDO3_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO1_OUTPUT_CONTROL, BIT(2)),
- AXP_DESC(AXP717, CLDO4, "cldo4", "vin1", 500, 3500, 100,
+ AXP_DESC(AXP717, CLDO4, "cldo4", "cldoin", 500, 3500, 100,
AXP717_CLDO4_CONTROL, AXP717_LDO_V_OUT_MASK,
AXP717_LDO1_OUTPUT_CONTROL, BIT(3)),
AXP_DESC(AXP717, CPUSLDO, "cpusldo", "vin1", 500, 1400, 50,
--
2.35.8
^ permalink raw reply related
* [PATCH 0/4] regulator: Fix AXP717 PMIC support
From: Andre Przywara @ 2024-03-29 23:50 UTC (permalink / raw)
To: Chen-Yu Tsai, Lee Jones, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: devicetree, linux-kernel, linux-sunxi, Jernej Skrabec,
Samuel Holland, Ryan Walklin, Chris Morgan
Here are some fixes to the AXP717 PMIC support series. Lee put that in
an immutable branch already, so these here go on top.
Patch 1 contains fixes to the regulator descriptions: the LDOs had the
wrong supply source, and two numbers were wrong. The datasheet describes
the voltage ranges and register values differently from what our macros
expect, in a way that literally begs for off-by-ones, so here you go.
I don't know if that's still feasible, but it would be a good candidate
to squash into the patch that it fixes.
The other three patches add the "boost" regulator, which is meant to
provide the 5V USB VBUS power when operating from the battery. It's the
usual trinity of binding/mfd/regulator patches.
Again this could be squashed into the respective patches from the
original series, if people agree.
Please have a look and test on a device, since I could not do this.
Based on mfd/ib-mfd-regulator-6.10, as detailed below.
Cheers,
Andre
Andre Przywara (4):
regulator: axp20x: AXP717: fix LDO supply rails and off-by-ones
dt-bindings: mfd: x-powers,axp152: add boost regulator
mfd: axp20x: AXP717: Add support for boost regulator
regulator: axp20x: AXP717: Add boost regulator
.../bindings/mfd/x-powers,axp152.yaml | 2 +-
drivers/mfd/axp20x.c | 2 ++
drivers/regulator/axp20x-regulator.c | 32 +++++++++++--------
include/linux/mfd/axp20x.h | 3 ++
4 files changed, 24 insertions(+), 15 deletions(-)
base-commit: 4cece764965020c22cff7665b18a012006359095
prerequisite-patch-id: 2b5fb10f68e0994071fc4c7dce73db7047c23220
prerequisite-patch-id: 5d0735de888d155b2c1cdb814e852a5852a17ec7
prerequisite-patch-id: 29c30894b4bf0b9e1e71de065cabbd842505e248
prerequisite-patch-id: 0ab87cbf7362b6dc2d577d2264eb9574be47b5f6
--
2.35.8
^ permalink raw reply
* Re: [PATCH v18 00/41] Introduce QC USB SND audio offloading support
From: Wesley Cheng @ 2024-03-29 23:28 UTC (permalink / raw)
To: srinivas.kandagatla, mathias.nyman, perex, conor+dt, corbet,
lgirdwood, andersson, krzysztof.kozlowski+dt, gregkh,
Thinh.Nguyen, broonie, bgoswami, tiwai, robh+dt, konrad.dybcio
Cc: linux-kernel, devicetree, linux-sound, linux-usb, linux-arm-msm,
linux-doc, alsa-devel
In-Reply-To: <20240228013619.29758-1-quic_wcheng@quicinc.com>
Hi,
On 2/27/2024 5:35 PM, Wesley Cheng wrote:
> Several Qualcomm based chipsets can support USB audio offloading to a
> dedicated audio DSP, which can take over issuing transfers to the USB
> host controller. The intention is to reduce the load on the main
> processors in the SoC, and allow them to be placed into lower power modes.
> There are several parts to this design:
> 1. Adding ASoC binding layer
> 2. Create a USB backend for Q6DSP
> 3. Introduce XHCI interrupter support
> 4. Create vendor ops for the USB SND driver
>
> USB | ASoC
> --------------------------------------------------------------------
> | _________________________
> | |sm8250 platform card |
> | |_________________________|
> | | |
> | ___V____ ____V____
> | |Q6USB | |Q6AFE |
> | |"codec" | |"cpu" |
> | |________| |_________|
> | ^ ^ ^
> | | |________|
> | ___V____ |
> | |SOC-USB | |
> ________ ________ | | |
> |USB SND |<--->|QC offld|<------------>|________| |
> |(card.c)| | |<---------- |
> |________| |________|___ | | |
> ^ ^ | | | ____________V_________
> | | | | | |APR/GLINK |
> __ V_______________V_____ | | | |______________________|
> |USB SND (endpoint.c) | | | | ^
> |_________________________| | | | |
> ^ | | | ___________V___________
> | | | |->|audio DSP |
> ___________V_____________ | | |_______________________|
> |XHCI HCD |<- |
> |_________________________| |
>
>
> Adding ASoC binding layer:
> soc-usb: Intention is to treat a USB port similar to a headphone jack.
> The port is always present on the device, but cable/pin status can be
> enabled/disabled. Expose mechanisms for USB backend ASoC drivers to
> communicate with USB SND.
>
> Create a USB backend for Q6DSP:
> q6usb: Basic backend driver that will be responsible for maintaining the
> resources needed to initiate a playback stream using the Q6DSP. Will
> be the entity that checks to make sure the connected USB audio device
> supports the requested PCM format. If it does not, the PCM open call will
> fail, and userpsace ALSA can take action accordingly.
>
> Introduce XHCI interrupter support:
> XHCI HCD supports multiple interrupters, which allows for events to be routed
> to different event rings. This is determined by "Interrupter Target" field
> specified in Section "6.4.1.1 Normal TRB" of the XHCI specification.
>
> Events in the offloading case will be routed to an event ring that is assigned
> to the audio DSP.
>
> Create vendor ops for the USB SND driver:
> qc_audio_offload: This particular driver has several components associated
> with it:
> - QMI stream request handler
> - XHCI interrupter and resource management
> - audio DSP memory management
>
> When the audio DSP wants to enable a playback stream, the request is first
> received by the ASoC platform sound card. Depending on the selected route,
> ASoC will bring up the individual DAIs in the path. The Q6USB backend DAI
> will send an AFE port start command (with enabling the USB playback path), and
> the audio DSP will handle the request accordingly.
>
> Part of the AFE USB port start handling will have an exchange of control
> messages using the QMI protocol. The qc_audio_offload driver will populate the
> buffer information:
> - Event ring base address
> - EP transfer ring base address
>
> and pass it along to the audio DSP. All endpoint management will now be handed
> over to the DSP, and the main processor is not involved in transfers.
>
> Overall, implementing this feature will still expose separate sound card and PCM
> devices for both the platorm card and USB audio device:
> 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D
> SM8250-MTP-WCD9380-WSA8810-VA-DMIC
> 1 [Audio ]: USB-Audio - USB Audio
> Generic USB Audio at usb-xhci-hcd.1.auto-1.4, high speed
>
> This is to ensure that userspace ALSA entities can decide which route to take
> when executing the audio playback. In the above, if card#1 is selected, then
> USB audio data will take the legacy path over the USB PCM drivers, etc...
>
> This feature was validated using:
> - tinymix: set/enable the multimedia path to route to USB backend
> - tinyplay: issue playback on platform card
>
> Changelog
> --------------------------------------------
> Changes in v18:
> - Rebased to usb-next, which merged in part of the series. Removed these patches.
> - Reworked Kconfigs for the ASoC USB related components from QCOM Q6DSP drivers
> to keep dependencies in place for SoC USB and USB SND.
> - Removed the repurposing of the stop ep sync API into existing XHCI operations.
> This will be solely used by the XHCI sideband for now.
>
Wanted to give a friendly ping to see if there were any more
concerns/feedback about this series before I submit a new revision that
rebases to the latest kernel codebase?
Thanks
Wesley Cheng
^ permalink raw reply
* Re: [PATCH v6 0/1] Add property in dwmac-stm32 documentation
From: patchwork-bot+netdevbpf @ 2024-03-29 22:50 UTC (permalink / raw)
To: Christophe Roullier
Cc: davem, edumazet, kuba, pabeni, robh+dt, krzysztof.kozlowski+dt,
conor+dt, mcoquelin.stm32, alexandre.torgue, richardcochran,
joabreu, lgirdwood, broonie, marex, netdev, devicetree,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20240328185337.332703-1-christophe.roullier@foss.st.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 28 Mar 2024 19:53:36 +0100 you wrote:
> Introduce property in dwmac-stm32 documentation
>
> - st,ext-phyclk: is present since 2020 in driver so need to explain
> it and avoid dtbs check issue : views/kernel/upstream/net-next/arch/arm/boot/dts/st/stm32mp157c-dk2.dtb:
> ethernet@5800a000: Unevaluated properties are not allowed
> ('st,ext-phyclk' was unexpected)
> Furthermore this property will be use in upstream of MP13 dwmac glue. (next step)
>
> [...]
Here is the summary with links:
- [v6,1/1] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
https://git.kernel.org/netdev/net-next/c/929107d3d2a3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Gilles Talis @ 2024-03-29 22:08 UTC (permalink / raw)
To: Andrew Lunn
Cc: devicetree, imx, linux-arm-kernel, conor+dt,
krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex
In-Reply-To: <147dfc5e-91e5-4ad4-b818-f6717e62df45@lunn.ch>
Hi Andrew,
Thank you for your review.
Le jeu. 28 mars 2024 à 18:11, Andrew Lunn <andrew@lunn.ch> a écrit :
>
> > +&eqos {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_eqos>;
> > + phy-mode = "rgmii-id";
> > + phy-handle = <ðphy0>;
> > + status = "okay";
> > +
> > + mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ethphy0: ethernet-phy@0 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <0>;
> > + reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <1000>;
> > + reset-deassert-us = <10000>;
> > + qca,disable-smarteee;
> > + qca,disable-hibernation-mode;
> > + vddio-supply = <&vddio>;
> > +
> > + vddio: vddio-regulator {
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + };
>
> Please could you explain what this last node is doing.
>
> Andrew
It seems like this might not be needed. Will check that and fix as appropriate.
thanks
Gilles.
^ permalink raw reply
* Re: [PATCH v4 2/5] soc: qcom: llcc: Add regmap for Broadcast_AND region
From: Bjorn Andersson @ 2024-03-29 22:02 UTC (permalink / raw)
To: Unnathi Chalicheemala
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel, kernel
In-Reply-To: <20240329-llcc-broadcast-and-v4-2-107c76fd8ceb@quicinc.com>
On Fri, Mar 29, 2024 at 02:53:41PM -0700, Unnathi Chalicheemala wrote:
> Define new regmap structure for Broadcast_AND region and initialize
> this regmap when HW block version is greater than 4.1, otherwise
> initialize as a NULL pointer for backwards compatibility.
>
> Switch from broadcast_OR to broadcast_AND region (when defined in DT)
> for checking status bit 1 as Broadcast_OR region checks only for bit 0.
>
Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Regards,
Bjorn
^ permalink raw reply
* [PATCH v4 2/5] soc: qcom: llcc: Add regmap for Broadcast_AND region
From: Unnathi Chalicheemala @ 2024-03-29 21:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel,
Unnathi Chalicheemala
In-Reply-To: <20240329-llcc-broadcast-and-v4-0-107c76fd8ceb@quicinc.com>
Define new regmap structure for Broadcast_AND region and initialize
this regmap when HW block version is greater than 4.1, otherwise
initialize as a NULL pointer for backwards compatibility.
Switch from broadcast_OR to broadcast_AND region (when defined in DT)
for checking status bit 1 as Broadcast_OR region checks only for bit 0.
Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com>
---
drivers/soc/qcom/llcc-qcom.c | 14 +++++++++++++-
include/linux/soc/qcom/llcc-qcom.h | 4 +++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c
index cbef0dea1d5d..727d00c527f1 100644
--- a/drivers/soc/qcom/llcc-qcom.c
+++ b/drivers/soc/qcom/llcc-qcom.c
@@ -821,6 +821,7 @@ EXPORT_SYMBOL_GPL(llcc_slice_putd);
static int llcc_update_act_ctrl(u32 sid,
u32 act_ctrl_reg_val, u32 status)
{
+ struct regmap *regmap;
u32 act_ctrl_reg;
u32 act_clear_reg;
u32 status_reg;
@@ -849,7 +850,8 @@ static int llcc_update_act_ctrl(u32 sid,
return ret;
if (drv_data->version >= LLCC_VERSION_4_1_0_0) {
- ret = regmap_read_poll_timeout(drv_data->bcast_regmap, status_reg,
+ regmap = drv_data->bcast_and_regmap ?: drv_data->bcast_regmap;
+ ret = regmap_read_poll_timeout(regmap, status_reg,
slice_status, (slice_status & ACT_COMPLETE),
0, LLCC_STATUS_READ_DELAY);
if (ret)
@@ -1284,6 +1286,16 @@ static int qcom_llcc_probe(struct platform_device *pdev)
drv_data->version = version;
+ /* Applicable only when drv_data->version >= 4.1 */
+ drv_data->bcast_and_regmap = qcom_llcc_init_mmio(pdev, i + 1, "llcc_broadcast_and_base");
+ if (IS_ERR(drv_data->bcast_and_regmap)) {
+ ret = PTR_ERR(drv_data->bcast_and_regmap);
+ if (ret == -EINVAL)
+ drv_data->bcast_and_regmap = NULL;
+ else
+ goto err;
+ }
+
llcc_cfg = cfg->sct_data;
sz = cfg->size;
diff --git a/include/linux/soc/qcom/llcc-qcom.h b/include/linux/soc/qcom/llcc-qcom.h
index 1a886666bbb6..9e9f528b1370 100644
--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -115,7 +115,8 @@ struct llcc_edac_reg_offset {
/**
* struct llcc_drv_data - Data associated with the llcc driver
* @regmaps: regmaps associated with the llcc device
- * @bcast_regmap: regmap associated with llcc broadcast offset
+ * @bcast_regmap: regmap associated with llcc broadcast OR offset
+ * @bcast_and_regmap: regmap associated with llcc broadcast AND offset
* @cfg: pointer to the data structure for slice configuration
* @edac_reg_offset: Offset of the LLCC EDAC registers
* @lock: mutex associated with each slice
@@ -129,6 +130,7 @@ struct llcc_edac_reg_offset {
struct llcc_drv_data {
struct regmap **regmaps;
struct regmap *bcast_regmap;
+ struct regmap *bcast_and_regmap;
const struct llcc_slice_config *cfg;
const struct llcc_edac_reg_offset *edac_reg_offset;
struct mutex lock;
--
2.25.1
^ permalink raw reply related
* [PATCH v4 3/5] arm64: dts: qcom: sm8450: Add mapping to llcc Broadcast_AND region
From: Unnathi Chalicheemala @ 2024-03-29 21:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel,
Unnathi Chalicheemala
In-Reply-To: <20240329-llcc-broadcast-and-v4-0-107c76fd8ceb@quicinc.com>
Mapping Broadcast_AND region for LLCC in SM8450.
Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com>
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index b86be34a912b..72587b9c7bba 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -4347,9 +4347,10 @@ system-cache-controller@19200000 {
compatible = "qcom,sm8450-llcc";
reg = <0 0x19200000 0 0x80000>, <0 0x19600000 0 0x80000>,
<0 0x19300000 0 0x80000>, <0 0x19700000 0 0x80000>,
- <0 0x19a00000 0 0x80000>;
+ <0 0x19a00000 0 0x80000>, <0 0x19c00000 0 0x80000>;
reg-names = "llcc0_base", "llcc1_base", "llcc2_base",
- "llcc3_base", "llcc_broadcast_base";
+ "llcc3_base", "llcc_broadcast_base",
+ "llcc_broadcast_and_base";
interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
};
--
2.25.1
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: arm: msm: Add llcc Broadcast_AND register
From: Unnathi Chalicheemala @ 2024-03-29 21:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel,
Unnathi Chalicheemala
In-Reply-To: <20240329-llcc-broadcast-and-v4-0-107c76fd8ceb@quicinc.com>
The LLCC block in SM8450, SM8550 and SM8650 have a new register
space for Broadcast_AND region. This is used to check that all
channels have bit set to "1", mainly in SCID activation/deactivation.
Previously we were mapping only the Broadcast_OR region assuming
there was only one broadcast register region. Now we also map
Broadcast_AND region.
Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com>
---
.../devicetree/bindings/cache/qcom,llcc.yaml | 27 +++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/cache/qcom,llcc.yaml b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml
index 07ccbda4a0ab..a6237028957f 100644
--- a/Documentation/devicetree/bindings/cache/qcom,llcc.yaml
+++ b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml
@@ -141,8 +141,31 @@ allOf:
- qcom,sm8150-llcc
- qcom,sm8250-llcc
- qcom,sm8350-llcc
+ then:
+ properties:
+ reg:
+ items:
+ - description: LLCC0 base register region
+ - description: LLCC1 base register region
+ - description: LLCC2 base register region
+ - description: LLCC3 base register region
+ - description: LLCC broadcast base register region
+ reg-names:
+ items:
+ - const: llcc0_base
+ - const: llcc1_base
+ - const: llcc2_base
+ - const: llcc3_base
+ - const: llcc_broadcast_base
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,sm8450-llcc
- qcom,sm8550-llcc
+ - qcom,sm8650-llcc
then:
properties:
reg:
@@ -151,7 +174,8 @@ allOf:
- description: LLCC1 base register region
- description: LLCC2 base register region
- description: LLCC3 base register region
- - description: LLCC broadcast base register region
+ - description: LLCC broadcast OR register region
+ - description: LLCC broadcast AND register region
reg-names:
items:
- const: llcc0_base
@@ -159,6 +183,7 @@ allOf:
- const: llcc2_base
- const: llcc3_base
- const: llcc_broadcast_base
+ - const: llcc_broadcast_and_base
additionalProperties: false
--
2.25.1
^ permalink raw reply related
* [PATCH v4 4/5] arm64: dts: qcom: sm8550: Add Broadcast_AND register in LLCC block
From: Unnathi Chalicheemala @ 2024-03-29 21:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel,
Unnathi Chalicheemala
In-Reply-To: <20240329-llcc-broadcast-and-v4-0-107c76fd8ceb@quicinc.com>
Chipsets before SM8450 have only one broadcast register (Broadcast_OR)
which is used to broadcast writes and check for status bit 0 only in
all channels.
From SM8450 onwards, a new Broadcast_AND region was added
which checks for status bit 1. This hasn't been updated and Broadcast_OR
region was wrongly being used to check for status bit 1 all along.
Hence mapping Broadcast_AND region's address space to LLCC in SM8550.
Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com>
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 3904348075f6..ee387e6f9832 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -4263,12 +4263,14 @@ system-cache-controller@25000000 {
<0 0x25200000 0 0x200000>,
<0 0x25400000 0 0x200000>,
<0 0x25600000 0 0x200000>,
- <0 0x25800000 0 0x200000>;
+ <0 0x25800000 0 0x200000>,
+ <0 0x25a00000 0 0x200000>;
reg-names = "llcc0_base",
"llcc1_base",
"llcc2_base",
"llcc3_base",
- "llcc_broadcast_base";
+ "llcc_broadcast_base",
+ "llcc_broadcast_and_base";
interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
};
--
2.25.1
^ permalink raw reply related
* [PATCH v4 5/5] arm64: dts: qcom: sm8650: Add Broadcast_AND register in LLCC block
From: Unnathi Chalicheemala @ 2024-03-29 21:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel,
Unnathi Chalicheemala
In-Reply-To: <20240329-llcc-broadcast-and-v4-0-107c76fd8ceb@quicinc.com>
Chipsets before SM8450 have only one broadcast register (Broadcast_OR)
which is used to broadcast writes and check for status bit 0 only in
all channels.
From SM8450 onwards, a new Broadcast_AND region was added which checks
for status bit 1. This hasn't been updated and Broadcast_OR region
was wrongly being used to check for status bit 1 all along.
Hence mapping Broadcast_AND region's address space to LLCC in SM8650.
Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index ba72d8f38420..8db052810357 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -4781,12 +4781,14 @@ system-cache-controller@25000000 {
<0 0x25400000 0 0x200000>,
<0 0x25200000 0 0x200000>,
<0 0x25600000 0 0x200000>,
- <0 0x25800000 0 0x200000>;
+ <0 0x25800000 0 0x200000>,
+ <0 0x25a00000 0 0x200000>;
reg-names = "llcc0_base",
"llcc1_base",
"llcc2_base",
"llcc3_base",
- "llcc_broadcast_base";
+ "llcc_broadcast_base",
+ "llcc_broadcast_and_base";
interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
};
--
2.25.1
^ permalink raw reply related
* [PATCH v4 0/5] LLCC: Support for Broadcast_AND region
From: Unnathi Chalicheemala @ 2024-03-29 21:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel,
Unnathi Chalicheemala
This series adds:
1. Device tree register mapping for Broadcast_AND region in SM8450,
SM8550, SM8650.
2. LLCC driver updates to reflect addition of Broadcast_AND regmap.
To support CSR programming, a broadcast interface is used to program all
channels in a single command. Until SM8450 there was only one broadcast
region (Broadcast_OR) used to broadcast write and check for status bit
0. From SM8450 onwards another broadcast region (Broadcast_AND) has been
added which checks for status bit 1.
This series updates the device trees from SM8450 onwards to have a
mapping to this Broadcast_AND region. It also updates the llcc_drv_data
structure with a regmap for Broadcast_AND region and corrects the
broadcast region used to check for status bit 1.
Changes in v4:
- Updated Devicetree patches' commit messages to make problem statement
clearer
- Resolved Konrad's comments on driver code patch
- Updated v3 changelog to include dropped R-b tag
Changes in v3:
- Removed new example in dt-bindings patch and ran 'make
DT_CHECKER_FLAGS=-m dt_binding_check'
- Dropped Krzysztof's R-b tag on dt-bindings patch
- Use of ternary operator in llcc_update_act_ctrl()
- Add comment before initialization of Broadcast_AND regmap in probe
function
- Move DeviceTree patches to the end
Changes in v2:
- Added an additional check in the case old DT files are used for
above mentioned chipsets for backwards compatibility
- Moved addition of if check in llcc_update_act_ctrl() to a separate
"Fixes" patch; not part of this series
Link to v3: https://lore.kernel.org/all/cover.1708551850.git.quic_uchalich@quicinc.com/
Link to v2: https://lore.kernel.org/all/cover.1707202761.git.quic_uchalich@quicinc.com/
Link to v1: https://lore.kernel.org/all/cover.1706296015.git.quic_uchalich@quicinc.com/
Unnathi Chalicheemala (5):
dt-bindings: arm: msm: Add llcc Broadcast_AND register
soc: qcom: llcc: Add regmap for Broadcast_AND region
arm64: dts: qcom: sm8450: Add mapping to llcc Broadcast_AND region
arm64: dts: qcom: sm8550: Add mapping to llcc Broadcast_AND region
arm64: dts: qcom: sm8650: Add mapping to llcc Broadcast_AND region
.../devicetree/bindings/cache/qcom,llcc.yaml | 27 ++++++++++++++++++-
arch/arm64/boot/dts/qcom/sm8450.dtsi | 5 ++--
arch/arm64/boot/dts/qcom/sm8550.dtsi | 6 +++--
arch/arm64/boot/dts/qcom/sm8650.dtsi | 6 +++--
drivers/soc/qcom/llcc-qcom.c | 15 ++++++++++-
include/linux/soc/qcom/llcc-qcom.h | 4 ++-
6 files changed, 54 insertions(+), 9 deletions(-)
--
2.25.1
---
Unnathi Chalicheemala (5):
dt-bindings: arm: msm: Add llcc Broadcast_AND register
soc: qcom: llcc: Add regmap for Broadcast_AND region
arm64: dts: qcom: sm8450: Add mapping to llcc Broadcast_AND region
arm64: dts: qcom: sm8550: Add Broadcast_AND register in LLCC block
arm64: dts: qcom: sm8650: Add Broadcast_AND register in LLCC block
.../devicetree/bindings/cache/qcom,llcc.yaml | 27 +++++++++++++++++++++-
arch/arm64/boot/dts/qcom/sm8450.dtsi | 5 ++--
arch/arm64/boot/dts/qcom/sm8550.dtsi | 6 +++--
arch/arm64/boot/dts/qcom/sm8650.dtsi | 6 +++--
drivers/soc/qcom/llcc-qcom.c | 14 ++++++++++-
include/linux/soc/qcom/llcc-qcom.h | 4 +++-
6 files changed, 53 insertions(+), 9 deletions(-)
---
base-commit: 4535e1a4174c4111d92c5a9a21e542d232e0fcaa
change-id: 20240329-llcc-broadcast-and-eec0838308d6
Best regards,
--
Unnathi Chalicheemala <quic_uchalich@quicinc.com>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Gilles Talis @ 2024-03-29 21:44 UTC (permalink / raw)
To: Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, conor+dt,
krzysztof.kozlowski+dt, robh, shawnguo, alex
In-Reply-To: <CAOMZO5D7QG3sbtCe_Y3h1i0b1VaLXCftLSCkjSuXcso+dKij9Q@mail.gmail.com>
Hi Fabio,
Thank you for the review.
Le jeu. 28 mars 2024 à 18:55, Fabio Estevam <festevam@gmail.com> a écrit :
>
> On Thu, Mar 28, 2024 at 5:23 PM Gilles Talis <gilles.talis@gmail.com> wrote:
>
> > + pinctrl_i2c6: i2c6grp {
> > + fsl,pins = <
> > + MX8MP_IOMUXC_UART4_RXD__I2C6_SCL 0x400001c3
> > + MX8MP_IOMUXC_UART4_TXD__I2C6_SDA 0x400001c3
>
> If i2c6 is not used, you can drop its pinctrl entry.
Got it. Will fix that.
thanks!
Gilles.
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Gilles Talis @ 2024-03-29 21:43 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, imx, linux-arm-kernel, conor+dt,
krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex
In-Reply-To: <a6728917-b756-430a-905c-f458fe41b998@linaro.org>
Hi Krzysztof,
Thank you for the review.
Le jeu. 28 mars 2024 à 18:04, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> a écrit :
>
> On 28/03/2024 21:23, Gilles Talis wrote:
> > The Emcraft Systems NavQ+ kit is a mobile robotics platform
> > based on NXP i.MX8 MPlus SoC.
> >
> > The following interfaces and devices are enabled:
> > - eMMC
> > - Gigabit Ethernet
> > - RTC
> > - SD-Card
> > - UART console
> >
> > Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
> > ---
> > arch/arm64/boot/dts/freescale/Makefile | 1 +
> > .../arm64/boot/dts/freescale/imx8mp-navqp.dts | 435 ++++++++++++++++++
> > 2 files changed, 436 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> > index 045250d0a040..bf99864c0bc4 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -166,6 +166,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk3.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-icore-mx8mp-edimm2.2.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-msc-sm2s-ep1.dtb
> > +dtb-$(CONFIG_ARCH_MXC) += imx8mp-navqp.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-hdmi.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
> > new file mode 100644
> > index 000000000000..8182e71008f8
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
> > @@ -0,0 +1,435 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2021 Emcraft Systems
> > + * Copyright 2024 Gilles Talis <gilles.talis@gmail.com>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include "imx8mp.dtsi"
> > +
> > +/ {
> > + model = "Emcraft Systems i.MX8MPlus NavQ+ Kit";
> > + compatible = "emcraft,imx8mp-navqp", "fsl,imx8mp";
> > +
> > + chosen {
> > + stdout-path = &uart2;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpio_led>;
> > +
> > + status {
>
> It does not look like you tested the DTS against bindings. Please run
> `make dtbs_check W=1` (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
>
> > + label = "status";
>
> Please provide color and function properties, if reasonable, and then
> remove label property.
>
> > + gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
> > + default-state = "on";
> > + };
> > + };
> > +
>
> ...
>
> > + pinctrl_i2c6: i2c6grp {
> > + fsl,pins = <
> > + MX8MP_IOMUXC_UART4_RXD__I2C6_SCL 0x400001c3
> > + MX8MP_IOMUXC_UART4_TXD__I2C6_SDA 0x400001c3
> > + >;
> > + };
> > +
> > + pinctrl_pmic: pmicirq {
> > + fsl,pins = <
> > + MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
> > + >;
> > + };
> > +
> > + pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
> > + fsl,pins = <
> > + MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x41
> > + >;
> > + };
> > +
> > + pinctrl_uart2: uart2grp {
> > + fsl,pins = <
> > + MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x49
> > + MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x49
> > + >;
> > + };
> > +
> > + pinctrl_usdhc2: usdhc2grp {
> > + fsl,pins = <
> > + MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x190
> > + MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d0
> > + MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d0
> > + MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d0
> > + MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d0
> > + MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d0
> > + MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
> > + >;
> > + };
> > +
> > + pinctrl_usdhc2_100mhz: usdhc2grp-100mhz {
>
> Hm, you upstreamed something based on downstream source. Please avoid
> that. Instead take upstream, clean DTS and customize it to your needs.
> Otherwise you send patch with the same issues we fixed.
OK. Got it. Will avoid that in the future.
>
> Standard form letter:
> It does not look like you tested the DTS against bindings. Please run
> `make dtbs_check W=1` (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
>
> Nodes end on 'grp' I believe.
I did run it, but I might have messed up something, as I did not get
the results your automatic check reported. Let me run it again and fix
the issues.
>
>
> Best regards,
> Krzysztof
>
regards
Gilles.
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: adc: Document XuanTie TH1520 ADC
From: Rob Herring @ 2024-03-29 21:29 UTC (permalink / raw)
To: wefu
Cc: nuno.sa, okan.sahin, palmer, conor, mike.looijmans, devicetree,
jic23, marcelo.schmitt, marius.cristea, guoren, andriy.shevchenko,
jszhang, bigunclemax, lee, linux-kernel, linux-riscv,
krzysztof.kozlowski+dt, linux-iio, paul.walmsley, aou,
marcus.folkesson, lars, fr0st61te, schnelle
In-Reply-To: <20240329200241.4122000-4-wefu@redhat.com>
On Sat, 30 Mar 2024 04:01:26 +0800, wefu@redhat.com wrote:
> From: Wei Fu <wefu@redhat.com>
>
> Document devicetree bindings for the XuanTie TH1520 AP sub-system ADC.
>
> Signed-off-by: Wei Fu <wefu@redhat.com>
> ---
> .../bindings/iio/adc/thead,th1520.yaml | 52 +++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
./Documentation/devicetree/bindings/iio/adc/thead,th1520.yaml:45:1: [error] syntax error: found character '\t' that cannot start any token (syntax)
dtschema/dtc warnings/errors:
make[2]: *** Deleting file 'Documentation/devicetree/bindings/iio/adc/thead,th1520.example.dts'
Documentation/devicetree/bindings/iio/adc/thead,th1520.yaml:45:1: found a tab character where an indentation space is expected
make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/iio/adc/thead,th1520.example.dts] Error 1
make[2]: *** Waiting for unfinished jobs....
./Documentation/devicetree/bindings/iio/adc/thead,th1520.yaml:45:1: found a tab character where an indentation space is expected
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/iio/adc/thead,th1520.yaml: ignoring, error parsing file
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2
make: *** [Makefile:240: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240329200241.4122000-4-wefu@redhat.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: qcm6490-idp: Add change to name the regulators
From: Elliot Berman @ 2024-03-29 21:09 UTC (permalink / raw)
To: Umang Chheda
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
quic_kamalw
In-Reply-To: <20240329122940.3649730-1-quic_uchheda@quicinc.com>
Nit: the subject line should be:
arm64: dts: qcom: qcm6490: Name the regulators
I don't know if it merits a resend, though.
On Fri, Mar 29, 2024 at 05:59:40PM +0530, Umang Chheda wrote:
> Without explicitly specifying names for the regulators they are named
> based on the DeviceTree node name. This results in multiple regulators
> with the same name, making it impossible to reason debug prints and
> regulator_summary.
>
> Signed-off-by: Umang Chheda <quic_uchheda@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 41 ++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> index f8f8a43f638d..ac6d741868ca 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> @@ -195,129 +195,151 @@ regulators-0 {
> vdd-l14-l16-supply = <&vreg_s8b_1p272>;
>
> vreg_s1b_1p872: smps1 {
> + regulator-name = "vreg_s1b_1p872";
> regulator-min-microvolt = <1840000>;
> regulator-max-microvolt = <2040000>;
> };
>
> vreg_s2b_0p876: smps2 {
> + regulator-name = "vreg_s2b_0p876";
> regulator-min-microvolt = <570070>;
> regulator-max-microvolt = <1050000>;
> };
>
> vreg_s7b_0p972: smps7 {
> + regulator-name = "vreg_s7b_0p972";
> regulator-min-microvolt = <535000>;
> regulator-max-microvolt = <1120000>;
> };
>
> vreg_s8b_1p272: smps8 {
> + regulator-name = "vreg_s8b_1p272";
> regulator-min-microvolt = <1200000>;
> regulator-max-microvolt = <1500000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_RET>;
> };
>
> vreg_l1b_0p912: ldo1 {
> + regulator-name = "vreg_l1b_0p912";
> regulator-min-microvolt = <825000>;
> regulator-max-microvolt = <925000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l2b_3p072: ldo2 {
> + regulator-name = "vreg_l2b_3p072";
> regulator-min-microvolt = <2700000>;
> regulator-max-microvolt = <3544000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l3b_0p504: ldo3 {
> + regulator-name = "vreg_l3b_0p504";
> regulator-min-microvolt = <312000>;
> regulator-max-microvolt = <910000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l4b_0p752: ldo4 {
> + regulator-name = "vreg_l4b_0p752";
> regulator-min-microvolt = <752000>;
> regulator-max-microvolt = <820000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> reg_l5b_0p752: ldo5 {
> + regulator-name = "reg_l5b_0p752";
> regulator-min-microvolt = <552000>;
> regulator-max-microvolt = <832000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l6b_1p2: ldo6 {
> + regulator-name = "vreg_l6b_1p2";
> regulator-min-microvolt = <1140000>;
> regulator-max-microvolt = <1260000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l7b_2p952: ldo7 {
> + regulator-name = "vreg_l7b_2p952";
> regulator-min-microvolt = <2400000>;
> regulator-max-microvolt = <3544000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l8b_0p904: ldo8 {
> + regulator-name = "vreg_l8b_0p904";
> regulator-min-microvolt = <870000>;
> regulator-max-microvolt = <970000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l9b_1p2: ldo9 {
> + regulator-name = "vreg_l9b_1p2";
> regulator-min-microvolt = <1200000>;
> regulator-max-microvolt = <1304000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l11b_1p504: ldo11 {
> + regulator-name = "vreg_l11b_1p504";
> regulator-min-microvolt = <1504000>;
> regulator-max-microvolt = <2000000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l12b_0p751: ldo12 {
> + regulator-name = "vreg_l12b_0p751";
> regulator-min-microvolt = <751000>;
> regulator-max-microvolt = <824000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l13b_0p53: ldo13 {
> + regulator-name = "vreg_l13b_0p53";
> regulator-min-microvolt = <530000>;
> regulator-max-microvolt = <824000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l14b_1p08: ldo14 {
> + regulator-name = "vreg_l14b_1p08";
> regulator-min-microvolt = <1080000>;
> regulator-max-microvolt = <1304000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l15b_0p765: ldo15 {
> + regulator-name = "vreg_l15b_0p765";
> regulator-min-microvolt = <765000>;
> regulator-max-microvolt = <1020000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l16b_1p1: ldo16 {
> + regulator-name = "vreg_l16b_1p1";
> regulator-min-microvolt = <1100000>;
> regulator-max-microvolt = <1300000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l17b_1p7: ldo17 {
> + regulator-name = "vreg_l17b_1p7";
> regulator-min-microvolt = <1700000>;
> regulator-max-microvolt = <1900000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l18b_1p8: ldo18 {
> + regulator-name = "vreg_l18b_1p8";
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <2000000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l19b_1p8: ldo19 {
> + regulator-name = "vreg_l19b_1p8";
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <2000000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> @@ -349,109 +371,128 @@ regulators-1 {
> vdd-bob-supply = <&vph_pwr>;
>
> vreg_s1c_2p19: smps1 {
> + regulator-name = "vreg_s1c_2p19";
> regulator-min-microvolt = <2190000>;
> regulator-max-microvolt = <2210000>;
> };
>
> vreg_s2c_0p752: smps2 {
> + regulator-name = "vreg_s2c_0p752";
> regulator-min-microvolt = <750000>;
> regulator-max-microvolt = <800000>;
> };
>
> vreg_s5c_0p752: smps5 {
> + regulator-name = "vreg_s5c_0p752";
> regulator-min-microvolt = <465000>;
> regulator-max-microvolt = <1050000>;
> };
>
> vreg_s7c_0p752: smps7 {
> + regulator-name = "vreg_s7c_0p752";
> regulator-min-microvolt = <465000>;
> regulator-max-microvolt = <800000>;
> };
>
> vreg_s9c_1p084: smps9 {
> + regulator-name = "vreg_s9c_1p084";
> regulator-min-microvolt = <1010000>;
> regulator-max-microvolt = <1170000>;
> };
>
> vreg_l1c_1p8: ldo1 {
> + regulator-name = "vreg_l1c_1p8";
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <1980000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l2c_1p62: ldo2 {
> + regulator-name = "vreg_l2c_1p62";
> regulator-min-microvolt = <1620000>;
> regulator-max-microvolt = <1980000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l3c_2p8: ldo3 {
> + regulator-name = "vreg_l3c_2p8";
> regulator-min-microvolt = <2800000>;
> regulator-max-microvolt = <3540000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l4c_1p62: ldo4 {
> + regulator-name = "vreg_l4c_1p62";
> regulator-min-microvolt = <1620000>;
> regulator-max-microvolt = <3300000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l5c_1p62: ldo5 {
> + regulator-name = "vreg_l5c_1p62";
> regulator-min-microvolt = <1620000>;
> regulator-max-microvolt = <3300000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l6c_2p96: ldo6 {
> + regulator-name = "vreg_l6c_2p96";
> regulator-min-microvolt = <1650000>;
> regulator-max-microvolt = <3544000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l7c_3p0: ldo7 {
> + regulator-name = "vreg_l7c_3p0";
> regulator-min-microvolt = <3000000>;
> regulator-max-microvolt = <3544000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l8c_1p62: ldo8 {
> + regulator-name = "vreg_l8c_1p62";
> regulator-min-microvolt = <1620000>;
> regulator-max-microvolt = <2000000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l9c_2p96: ldo9 {
> + regulator-name = "vreg_l9c_2p96";
> regulator-min-microvolt = <2700000>;
> regulator-max-microvolt = <35440000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l10c_0p88: ldo10 {
> + regulator-name = "vreg_l10c_0p88";
> regulator-min-microvolt = <720000>;
> regulator-max-microvolt = <1050000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l11c_2p8: ldo11 {
> + regulator-name = "vreg_l11c_2p8";
> regulator-min-microvolt = <2800000>;
> regulator-max-microvolt = <3544000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l12c_1p65: ldo12 {
> + regulator-name = "vreg_l12c_1p65";
> regulator-min-microvolt = <1650000>;
> regulator-max-microvolt = <2000000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_l13c_2p7: ldo13 {
> + regulator-name = "vreg_l13c_2p7";
> regulator-min-microvolt = <2700000>;
> regulator-max-microvolt = <3544000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> vreg_bob_3p296: bob {
> + regulator-name = "vreg_bob_3p296";
> regulator-min-microvolt = <3008000>;
> regulator-max-microvolt = <3960000>;
> };
> --
> 2.25.1
>
>
^ 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