* [PATCH v4 1/2] dt-bindings: mtd: amlogic,meson-nand: support fields for boot ROM code
From: Arseniy Krasnov @ 2024-04-10 18:54 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-mtd, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel, oxffffaa, kernel, Arseniy Krasnov
In-Reply-To: <20240410185409.2635622-1-avkrasnov@salutedevices.com>
Boot ROM code on Meson requires that some pages on NAND must be written
in special mode: "short" ECC mode where each block is 384 bytes and
scrambling mode is on. Such pages located with the specified interval
within specified offset. Both interval and offset are located in the
device tree and used by driver if 'nand-is-boot-medium' is set for
NAND chip.
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
---
.../bindings/mtd/amlogic,meson-nand.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
index 57b6957c8415..838ae1847ef0 100644
--- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
@@ -64,11 +64,25 @@ patternProperties:
items:
maximum: 0
+ amlogic,boot-pages:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The NFC driver needs this information to select ECC
+ algorithms supported by the boot ROM.
+
+ amlogic,boot-page-step:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The NFC driver needs this information to select ECC
+ algorithms supported by the boot ROM (in pages).
+
unevaluatedProperties: false
dependencies:
nand-ecc-strength: [nand-ecc-step-size]
nand-ecc-step-size: [nand-ecc-strength]
+ amlogic,boot-pages: [nand-is-boot-medium, "amlogic,boot-page-step"]
+ amlogic,boot-page-step: [nand-is-boot-medium, "amlogic,boot-pages"]
required:
--
2.35.0
^ permalink raw reply related
* [PATCH v4 2/2] mtd: rawnand: meson: support R/W mode for boot ROM
From: Arseniy Krasnov @ 2024-04-10 18:54 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-mtd, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel, oxffffaa, kernel, Arseniy Krasnov
In-Reply-To: <20240410185409.2635622-1-avkrasnov@salutedevices.com>
Boot ROM code on Meson requires that some pages on NAND must be written
in special mode: "short" ECC mode where each block is 384 bytes and
scrambling mode is on. Such pages located with the specified interval
within specified offset. Both interval and offset are located in the
device tree and used by driver if 'nand-is-boot-medium' is set for
NAND chip.
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
---
drivers/mtd/nand/raw/meson_nand.c | 88 +++++++++++++++++++++----------
1 file changed, 59 insertions(+), 29 deletions(-)
diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
index 00ce0e5bb970..9ee11243b257 100644
--- a/drivers/mtd/nand/raw/meson_nand.c
+++ b/drivers/mtd/nand/raw/meson_nand.c
@@ -35,6 +35,7 @@
#define NFC_CMD_RB BIT(20)
#define NFC_CMD_SCRAMBLER_ENABLE BIT(19)
#define NFC_CMD_SCRAMBLER_DISABLE 0
+#define NFC_CMD_SHORTMODE_ENABLE 1
#define NFC_CMD_SHORTMODE_DISABLE 0
#define NFC_CMD_RB_INT BIT(14)
#define NFC_CMD_RB_INT_NO_PIN ((0xb << 10) | BIT(18) | BIT(16))
@@ -78,6 +79,8 @@
#define DMA_DIR(dir) ((dir) ? NFC_CMD_N2M : NFC_CMD_M2N)
#define DMA_ADDR_ALIGN 8
+#define NFC_SHORT_MODE_ECC_SZ 384
+
#define ECC_CHECK_RETURN_FF (-1)
#define NAND_CE0 (0xe << 10)
@@ -125,6 +128,8 @@ struct meson_nfc_nand_chip {
u32 twb;
u32 tadl;
u32 tbers_max;
+ u32 boot_pages;
+ u32 boot_page_step;
u32 bch_mode;
u8 *data_buf;
@@ -298,28 +303,49 @@ static void meson_nfc_cmd_seed(struct meson_nfc *nfc, u32 seed)
nfc->reg_base + NFC_REG_CMD);
}
-static void meson_nfc_cmd_access(struct nand_chip *nand, int raw, bool dir,
- int scrambler)
+static int meson_nfc_page_is_boot(struct nand_chip *nand, int page)
+{
+ const struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
+
+ return (nand->options & NAND_IS_BOOT_MEDIUM) &&
+ !(page % meson_chip->boot_page_step) &&
+ (page < meson_chip->boot_pages);
+}
+
+static void meson_nfc_cmd_access(struct nand_chip *nand, bool raw, bool dir, int page)
{
+ const struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
struct mtd_info *mtd = nand_to_mtd(nand);
struct meson_nfc *nfc = nand_get_controller_data(mtd_to_nand(mtd));
- struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
- u32 bch = meson_chip->bch_mode, cmd;
int len = mtd->writesize, pagesize, pages;
+ int scrambler;
+ u32 cmd;
- pagesize = nand->ecc.size;
+ if (nand->options & NAND_NEED_SCRAMBLING)
+ scrambler = NFC_CMD_SCRAMBLER_ENABLE;
+ else
+ scrambler = NFC_CMD_SCRAMBLER_DISABLE;
if (raw) {
len = mtd->writesize + mtd->oobsize;
cmd = len | scrambler | DMA_DIR(dir);
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
- return;
- }
+ } else if (meson_nfc_page_is_boot(nand, page)) {
+ pagesize = NFC_SHORT_MODE_ECC_SZ >> 3;
+ pages = mtd->writesize / 512;
+
+ scrambler = NFC_CMD_SCRAMBLER_ENABLE;
+ cmd = CMDRWGEN(DMA_DIR(dir), scrambler, NFC_ECC_BCH8_1K,
+ NFC_CMD_SHORTMODE_ENABLE, pagesize, pages);
+ } else {
+ pagesize = nand->ecc.size >> 3;
+ pages = len / nand->ecc.size;
- pages = len / nand->ecc.size;
+ cmd = CMDRWGEN(DMA_DIR(dir), scrambler, meson_chip->bch_mode,
+ NFC_CMD_SHORTMODE_DISABLE, pagesize, pages);
+ }
- cmd = CMDRWGEN(DMA_DIR(dir), scrambler, bch,
- NFC_CMD_SHORTMODE_DISABLE, pagesize, pages);
+ if (scrambler == NFC_CMD_SCRAMBLER_ENABLE)
+ meson_nfc_cmd_seed(nfc, page);
writel(cmd, nfc->reg_base + NFC_REG_CMD);
}
@@ -743,15 +769,7 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
if (ret)
return ret;
- if (nand->options & NAND_NEED_SCRAMBLING) {
- meson_nfc_cmd_seed(nfc, page);
- meson_nfc_cmd_access(nand, raw, DIRWRITE,
- NFC_CMD_SCRAMBLER_ENABLE);
- } else {
- meson_nfc_cmd_access(nand, raw, DIRWRITE,
- NFC_CMD_SCRAMBLER_DISABLE);
- }
-
+ meson_nfc_cmd_access(nand, raw, DIRWRITE, page);
cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_PAGEPROG;
writel(cmd, nfc->reg_base + NFC_REG_CMD);
meson_nfc_queue_rb(nand, PSEC_TO_MSEC(sdr->tPROG_max), false);
@@ -829,15 +847,7 @@ static int meson_nfc_read_page_sub(struct nand_chip *nand,
if (ret)
return ret;
- if (nand->options & NAND_NEED_SCRAMBLING) {
- meson_nfc_cmd_seed(nfc, page);
- meson_nfc_cmd_access(nand, raw, DIRREAD,
- NFC_CMD_SCRAMBLER_ENABLE);
- } else {
- meson_nfc_cmd_access(nand, raw, DIRREAD,
- NFC_CMD_SCRAMBLER_DISABLE);
- }
-
+ meson_nfc_cmd_access(nand, raw, DIRREAD, page);
ret = meson_nfc_wait_dma_finish(nfc);
meson_nfc_check_ecc_pages_valid(nfc, nand, raw);
@@ -1436,6 +1446,26 @@ meson_nfc_nand_chip_init(struct device *dev,
if (ret)
return ret;
+ if (nand->options & NAND_IS_BOOT_MEDIUM) {
+ ret = of_property_read_u32(np, "amlogic,boot-pages",
+ &meson_chip->boot_pages);
+ if (ret) {
+ dev_err(dev, "could not retrieve 'amlogic,boot-pages' property: %d",
+ ret);
+ nand_cleanup(nand);
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "amlogic,boot-page-step",
+ &meson_chip->boot_page_step);
+ if (ret) {
+ dev_err(dev, "could not retrieve 'amlogic,boot-page-step' property: %d",
+ ret);
+ nand_cleanup(nand);
+ return ret;
+ }
+ }
+
ret = mtd_device_register(mtd, NULL, 0);
if (ret) {
dev_err(dev, "failed to register MTD device: %d\n", ret);
--
2.35.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
From: Rob Herring @ 2024-04-10 19:15 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: chunkuang.hu, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied,
daniel, maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
shawn.sung, yu-chang.lee, ck.hu, jitao.shi, devicetree,
linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, wenst,
kernel
In-Reply-To: <20240409120211.321153-3-angelogioacchino.delregno@collabora.com>
On Tue, Apr 09, 2024 at 02:02:10PM +0200, AngeloGioacchino Del Regno wrote:
> Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
> per HW instance (so potentially up to six displays for multi-vdo SoCs).
>
> The MMSYS or VDOSYS is always the first component in the DDP pipeline,
> so it only supports an output port with multiple endpoints - where each
> endpoint defines the starting point for one of the (currently three)
> possible hardware paths.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> index b3c6888c1457..4e9acd966aa5 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> @@ -93,6 +93,29 @@ properties:
> '#reset-cells':
> const: 1
>
> + port:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + Output port node. This port connects the MMSYS/VDOSYS output to
> + the first component of one display pipeline, for example one of
> + the available OVL or RDMA blocks.
> + Some MediaTek SoCs support up to three display outputs per MMSYS.
I'm have a hard time understanding this, but is it 3 outputs
simultaneously or connect mmsys to 1 of 3. Generally it's multiple ports
for the former and endpoints for the latter.
> + properties:
> + endpoint@0:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: Output to the primary display pipeline
> +
> + endpoint@1:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: Output to the secondary display pipeline
> +
> + endpoint@2:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: Output to the tertiary display pipeline
> +
> + required:
> + - endpoint@0
> +
> required:
> - compatible
> - reg
> --
> 2.44.0
>
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
From: Russell King (Oracle) @ 2024-04-10 19:19 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Romain Gantois, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Clément Léger, Thomas Petazzoni,
netdev, devicetree, linux-kernel, linux-renesas-soc, linux-stm32,
linux-arm-kernel, Maxime Chevallier
In-Reply-To: <20240409183404.7d3eb04f@kernel.org>
On Tue, Apr 09, 2024 at 06:34:04PM -0700, Jakub Kicinski wrote:
> On Tue, 09 Apr 2024 11:21:46 +0200 Romain Gantois wrote:
> > + struct regmap_config pcs_regmap_cfg = {
> > + .reg_bits = 16,
> > + .val_bits = 16,
> > + .reg_shift = regmap_upshift(1),
>
> This appears to displease the compiler:
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:389:16: error: call to undeclared function 'regmap_upshift'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 389 | .reg_shift = regmap_upshift(1),
> | ^
Yes, annoyingly I accidentally it 'u' instead of 'y' in vi which
lower-cased the entire function, and didn't realise before sending the
patch as a theoretical solution to Romain. After build-testing it locally
I did notice it. I would've thought that Romain would've build-tested
before sending out his patch set and would've fixed it up... I didn't
have time to properly fix up my patch (essentially would've ment
redoing the edits from scratch to ensure that it was correct.) Still
don't have time to do that. Sorry.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next 1/1] dt-bindings: ptp: Add device tree binding for IDT FemtoClock
From: Krzysztof Kozlowski @ 2024-04-10 19:23 UTC (permalink / raw)
To: Min Li, richardcochran, robh+dt, krzysztof.kozlowski+dt, conor+dt
Cc: devicetree, linux-kernel, netdev, Min Li
In-Reply-To: <LV3P220MB1202BACF71E85F949FC09A29A0062@LV3P220MB1202.NAMP220.PROD.OUTLOOK.COM>
On 10/04/2024 20:41, Min Li wrote:
> From: Min Li <min.li.xe@renesas.com>
>
> Add device tree binding doc for the IDT FemtoClock Frequency
> Clock Synthesizers.
A nit, subject: drop second/last, redundant "device tree binding for"
The "dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Signed-off-by: Min Li <min.li.xe@renesas.com>
> ---
> .../devicetree/bindings/ptp/ptp-idtfc3.yaml | 47 +++++++++++++++++++
Filename based on compatible, e.g. idt,rc38xxx.yaml
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml
>
> diff --git a/Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml b/Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml
> new file mode 100644
> index 000000000000..3e1c3135df5a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/ptp/ptp-idtfc3.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RENESAS FemtoClock (TM) Frequency Clock Synthesizers
> +
> +maintainers:
> + - Min Li <min.li.xe@renesas.com>
> +
> +properties:
> + compatible:
> + enum:
> + # For System Synchronizer
> + - idt,rc38xxx0
> + - idt,rc38xxx1
> + - idt,rc38xxx2
> + - idt,rc38xxx3
> + - idt,rc38xxx4
> + - idt,rc38xxx5
> + - idt,rc38xxx6
> + - idt,rc38xxx7
> + - idt,rc38xxx8
> + - idt,rc38xxx9
What are the "xxx"? Wild-cards? Are these compatible? Please read
writing-bindings.
> +
> + reg:
> + maxItems: 1
> + description:
> + I2C slave address of the device.
Drop description, it is redundant.
This looks quite incomplete. Why it cannot be part of existing idt binding?
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phc@9 { /* FemtoClock3 */
You have totally messed indentation. What's more, this was not tested.
What is "FemtoClock3" doing here? What is it exactly?
> + compatible = "idt,rc38xxx0";
> + reg = <0x9>;
What's more, where is any user of it? What's the point of adding binding
without any users? Please read submitting patches in DT bindings directory.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/6] drm/msm/adreno: Implement SMEM-based speed bin
From: Dmitry Baryshkov @ 2024-04-10 19:26 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Rob Clark, Abhinav Kumar, Sean Paul,
Marijn Suijten, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-kernel,
dri-devel, freedreno, devicetree, Neil Armstrong
In-Reply-To: <730d6b9e-d6b4-41fd-bef3-b1fa6e914a35@linaro.org>
On Wed, Apr 10, 2024 at 01:42:33PM +0200, Konrad Dybcio wrote:
>
>
> On 4/6/24 05:23, Dmitry Baryshkov wrote:
> > On Fri, Apr 05, 2024 at 10:41:32AM +0200, Konrad Dybcio wrote:
> > > On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
> > > abstracted through SMEM, instead of being directly available in a fuse.
> > >
> > > Add support for SMEM-based speed binning, which includes getting
> > > "feature code" and "product code" from said source and parsing them
> > > to form something that lets us match OPPs against.
> > >
> > > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> > > ---
>
> [...]
>
> >
> > > + }
> > > +
> > > + ret = qcom_smem_get_product_code(&pcode);
> > > + if (ret) {
> > > + dev_err(dev, "Couldn't get product code from SMEM!\n");
> > > + return ret;
> > > + }
> > > +
> > > + /* Don't consider fcode for external feature codes */
> > > + if (fcode <= SOCINFO_FC_EXT_RESERVE)
> > > + fcode = SOCINFO_FC_UNKNOWN;
> > > +
> > > + *speedbin = FIELD_PREP(ADRENO_SKU_ID_PCODE, pcode) |
> > > + FIELD_PREP(ADRENO_SKU_ID_FCODE, fcode);
> >
> > What about just asking the qcom_smem for the 'gpu_bin' and hiding gory
> > details there? It almost feels that handling raw PCODE / FCODE here is
> > too low-level and a subject to change depending on the socinfo format.
>
> No, the FCODE & PCODE can be interpreted differently across consumers.
That's why I wrote about asking for 'gpu_bin'.
>
> >
> > > +
> > > + return ret;
> > > }
> > > int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
> > > @@ -1098,9 +1129,9 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
> > > devm_pm_opp_set_clkname(dev, "core");
> > > }
> > > - if (adreno_read_speedbin(dev, &speedbin) || !speedbin)
> > > + if (adreno_read_speedbin(adreno_gpu, dev, &speedbin) || !speedbin)
> > > speedbin = 0xffff;
> > > - adreno_gpu->speedbin = (uint16_t) (0xffff & speedbin);
> >
> > the &= 0xffff should probably go to the adreno_read_speedbin / nvmem
> > case. WDYT?
>
> Ok, I can keep it, though realistically if this ever does anything
> useful, it likely means the dt is wrong
Yes, but if DT is wrong, we should probably fail in a sensible way. I
just wanted to point out that previously we had this &0xffff, while your
patch silently removes it.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 4/4] dt-bindings: PCI: mediatek,mt7621-pcie: switch from deprecated pci-bus.yaml
From: Rob Herring @ 2024-04-10 19:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-rockchip, Scott Branden, Thippeswamy Havalige,
Sergio Paracuellos, Will Deacon, Sven Peter, Heiko Stuebner,
Jiaxun Yang, Florian Fainelli, Linus Walleij, devicetree,
Jim Quinlan, Krzysztof Kozlowski, Bjorn Helgaas, linux-arm-kernel,
Bharat Kumar Gogada, asahi, linux-arm-msm, Hector Martin,
Alyssa Rosenzweig, Matthias Brugger, Krzysztof Wilczyński,
Lorenzo Pieralisi, AngeloGioacchino Del Regno, Mark Kettenis,
Geert Uytterhoeven, Tom Joseph, linux-renesas-soc, Jianjun Wang,
Gustavo Pimentel, Jingoo Han, linux-pci, Conor Dooley,
linux-rpi-kernel, linux-kernel, Yoshihiro Shimoda, Michal Simek,
Manivannan Sadhasivam, Nicolas Saenz Julienne, Ray Jui,
Broadcom internal kernel review list, Daire McNamara, Marek Vasut,
linux-mediatek, Konrad Dybcio, Srikanth Thokala, Ryder Lee,
Bjorn Andersson, Ahmad Zainie, Kishon Vijay Abraham I,
Magnus Damm, Neil Armstrong, Shawn Lin
In-Reply-To: <20240410181521.269431-4-krzysztof.kozlowski@linaro.org>
On Wed, 10 Apr 2024 20:15:21 +0200, Krzysztof Kozlowski wrote:
> dtschema package with core schemas deprecated pci-bus.yaml schema in
> favor of individual schemas per host, device and pci-pci.
>
> Switch Mediatek MT7621 PCIe host bridge binding to this new schema.
>
> This requires dtschema package newer than v2024.02 to work fully.
> v2024.02 will partially work: with a warning.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
>
> Important: v2024.03 (said dtschema newer than v2024.02) was not yet
> released, therefore this patch probably should wait a bit. Previous
> patches do not depend anyhow on future release, so they can be taken as
> is.
>
> Changes in v2:
> 1. New patch
> 2. Split mediatek,mt7621-pcie to separate patch as it uses
> pci-pci-bridge schema.
> ---
> .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.example.dtb: pcie@1e140000: pcie@0,0: Unevaluated properties are not allowed ('clocks', 'phy-names', 'phys', 'resets' were unexpected)
from schema $id: http://devicetree.org/schemas/pci/mediatek,mt7621-pcie.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.example.dtb: pcie@1e140000: pcie@1,0: Unevaluated properties are not allowed ('clocks', 'phy-names', 'phys', 'resets' were unexpected)
from schema $id: http://devicetree.org/schemas/pci/mediatek,mt7621-pcie.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.example.dtb: pcie@1e140000: pcie@2,0: Unevaluated properties are not allowed ('clocks', 'phy-names', 'phys', 'resets' were unexpected)
from schema $id: http://devicetree.org/schemas/pci/mediatek,mt7621-pcie.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240410181521.269431-4-krzysztof.kozlowski@linaro.org
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 net-next 1/1] dt-bindings: ptp: Add device tree binding for IDT FemtoClock
From: Rob Herring @ 2024-04-10 19:32 UTC (permalink / raw)
To: Min Li
Cc: richardcochran, linux-kernel, robh+dt, conor+dt, Min Li,
devicetree, krzysztof.kozlowski+dt, netdev
In-Reply-To: <LV3P220MB1202BACF71E85F949FC09A29A0062@LV3P220MB1202.NAMP220.PROD.OUTLOOK.COM>
On Wed, 10 Apr 2024 14:41:47 -0400, Min Li wrote:
> From: Min Li <min.li.xe@renesas.com>
>
> Add device tree binding doc for the IDT FemtoClock Frequency
> Clock Synthesizers.
>
> Signed-off-by: Min Li <min.li.xe@renesas.com>
> ---
> .../devicetree/bindings/ptp/ptp-idtfc3.yaml | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml:43:1: [error] syntax error: found character '\t' that cannot start any token (syntax)
dtschema/dtc warnings/errors:
make[2]: *** Deleting file 'Documentation/devicetree/bindings/ptp/ptp-idtfc3.example.dts'
Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml:43:1: found a tab character where an indentation space is expected
make[2]: *** [Documentation/devicetree/bindings/Makefile:26: Documentation/devicetree/bindings/ptp/ptp-idtfc3.example.dts] Error 1
make[2]: *** Waiting for unfinished jobs....
./Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml:43:1: found a tab character where an indentation space is expected
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/ptp/ptp-idtfc3.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/LV3P220MB1202BACF71E85F949FC09A29A0062@LV3P220MB1202.NAMP220.PROD.OUTLOOK.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 v12 4/7] drm/meson: gate px_clk when setting rate
From: Martin Blumenstingl @ 2024-04-10 19:34 UTC (permalink / raw)
To: Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jerome Brunet,
Kevin Hilman, Michael Turquette, Stephen Boyd, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Jagan Teki, Nicolas Belin, devicetree, linux-kernel,
linux-amlogic, linux-clk, linux-arm-kernel, dri-devel
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-4-99ecdfdc87fc@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]
Hi Neil,
On Wed, Apr 3, 2024 at 9:46 AM Neil Armstrong <neil.armstrong@linaro.org> wrote:
>
> Disable the px_clk when setting the rate to recover a fully
> configured and correctly reset VCLK clock tree after the rate
> is set.
>
> Fixes: 77d9e1e6b846 ("drm/meson: add support for MIPI-DSI transceiver")
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
> index a6bc1bdb3d0d..a10cff3ca1fe 100644
> --- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
> @@ -95,6 +95,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
> return ret;
> }
>
> + clk_disable_unprepare(mipi_dsi->px_clk);
nit-pick: clk_disable(mipi_dsi->px_clk); should be enough here as my
understanding is that we only need to {un,}prepare a clock once.
> ret = clk_set_rate(mipi_dsi->px_clk, mipi_dsi->mode->clock * 1000);
>
> if (ret) {
> @@ -103,6 +104,12 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
> return ret;
> }
>
> + ret = clk_prepare_enable(mipi_dsi->px_clk);
> + if (ret) {
> + dev_err(mipi_dsi->dev, "Failed to enable DSI Pixel clock (ret %d)\n", ret);
> + return ret;
If we ever hit this error case then there will be a lot of additional
errors in the kernel log:
- initially the clock is prepared and enabled in
meson_dw_mipi_dsi_probe() by calling devm_clk_get_enabled()
- we then disable the clock above (generally disabling a clock is
expected to always succeed)
- if the clock can NOT be re-enabled here we just log the error
- in case a user tries to rmmod the driver (to modprobe it again) to
try and recover from an error the automatic disabling of the pix_clk
(based on devm_clk_get_enabled() where it was enabled initially) there
will be a splat because the clock is already disabled (and enabled
count is zero, so it cannot be disabled any further)
For the 32-bit SoC video clocks I keep track of them being enabled or
disabled, see [0], [1] and [2].
In my case this is important because we can run into cases where the
PLL doesn't lock (I am not sure how likely this is for your case).
It *seems* like we need to do something similar as
dw_mipi_dsi_phy_init() can be called when changing the display
resolution (or whenever drm_bridge_funcs.atomic_pre_enable) is called.
To illustrate what I have in mind I attached a diff (it's based on
this patch) - it's compile tested only as I have no DSI hardware.
In case dw_mipi_dsi_phy_init() is called only once per device
lifecycle things may get easier.
PS: I'm so happy that we don't need any clock notifiers for this!
So: good work with the clock driver bits.
Let me know what you think,
Martin
[0] https://github.com/xdarklight/linux/blob/meson-mx-integration-6.9-20240323/drivers/gpu/drm/meson/meson_vclk.c#L1177-L1179
[1] https://github.com/xdarklight/linux/blob/meson-mx-integration-6.9-20240323/drivers/gpu/drm/meson/meson_vclk.c#L1077
[2] https://github.com/xdarklight/linux/blob/meson-mx-integration-6.9-20240323/drivers/gpu/drm/meson/meson_vclk.c#L1053
[-- Attachment #2: meson_dw_mipi_dsi-clk-disable-enable.diff --]
[-- Type: text/x-patch, Size: 1837 bytes --]
diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
index a6bc1bdb3d0d..926618d0e622 100644
--- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -46,6 +46,7 @@ struct meson_dw_mipi_dsi {
struct clk *bit_clk;
struct clk *px_clk;
struct reset_control *top_rst;
+ bool px_clk_enabled;
};
#define encoder_to_meson_dw_mipi_dsi(x) \
@@ -87,6 +88,11 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ if (mipi_dsi->px_clk_enabled) {
+ clk_disable(mipi_dsi->px_clk);
+ mipi_dsi->px_clk_enabled = false;
+ }
+
/* Make sure the rate of the bit clock is not modified by someone else */
ret = clk_rate_exclusive_get(mipi_dsi->bit_clk);
if (ret) {
@@ -103,6 +109,14 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ ret = clk_prepare_enable(mipi_dsi->px_clk);
+ if (ret) {
+ dev_err(mipi_dsi->dev, "Failed to enable DSI Pixel clock (ret %d)\n", ret);
+ return ret;
+ }
+
+ mipi_dsi->px_clk_enabled = true;
+
switch (mipi_dsi->dsi_device->format) {
case MIPI_DSI_FMT_RGB888:
dpi_data_format = DPI_COLOR_24BIT;
@@ -287,7 +301,7 @@ static int meson_dw_mipi_dsi_probe(struct platform_device *pdev)
return dev_err_probe(dev, ret, "Unable to get enabled bit_clk\n");
}
- mipi_dsi->px_clk = devm_clk_get_enabled(dev, "px");
+ mipi_dsi->px_clk = devm_clk_get_prepared(dev, "px");
if (IS_ERR(mipi_dsi->px_clk))
return dev_err_probe(dev, PTR_ERR(mipi_dsi->px_clk),
"Unable to get enabled px_clk\n");
@@ -327,6 +341,9 @@ static void meson_dw_mipi_dsi_remove(struct platform_device *pdev)
{
struct meson_dw_mipi_dsi *mipi_dsi = platform_get_drvdata(pdev);
+ if (mipi_dsi->px_clk_enabled)
+ clk_disable(mipi_dsi->px_clk);
+
dw_mipi_dsi_remove(mipi_dsi->dmd);
}
^ permalink raw reply related
* Re: [PATCH v2 5/7] dt-bindings: phy: qcom,ipq8074-qmp-pcie: add ipq9574 gen3x2 PHY
From: Krzysztof Kozlowski @ 2024-04-10 19:36 UTC (permalink / raw)
To: mr.nuke.me, Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <d827ec3c-84fd-9352-b321-79bdc4bdcd40@gmail.com>
On 10/04/2024 18:29, mr.nuke.me@gmail.com wrote:
>
>
> On 4/10/24 02:02, Krzysztof Kozlowski wrote:
>> On 10/04/2024 08:59, Krzysztof Kozlowski wrote:
>>> On 09/04/2024 22:19, mr.nuke.me@gmail.com wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> clock-names:
>>>>>> items:
>>>>>> - const: aux
>>>>>> - const: cfg_ahb
>>>>>> - const: pipe
>>>>>> + - const: anoc
>>>>>> + - const: snoc
>>>>>
>>>>> OK, you did not test it. Neither this, nor DTS. I stop review, please
>>>>> test first.
>>>>
>>>> I ran both `checkpatch.pl` and `make dt_binding_check`. What in this
>>>> patch makes you say I "did not test it", and what test or tests did I miss?
>>>>
>>>
>>> ... and no, you did not. If you tested, you would easily see error:
>>> clock-names: ['aux', 'cfg_ahb', 'pipe'] is too short
>>>
>>> When you receive comment from reviewer, please investigate thoroughly
>>> what could get wrong. Don't answer just to get rid of reviewer. It's
>>> fine to make mistakes, but if reviewer points to issue and you
>>> immediately respond "no issue", that's waste of my time.
>>
>> To clarify: "no issue" response is waste of my time. If you responded
>> "oh, I see the error, but I don't know how to fix it", it would be ok, I
>> can clarify and help in this.
>
> I apologize if I gave you this impression. I tried to follow the testing
> process, it did not turn out as expected. Obviously, I missed something.
> I tried to ask what I missed, and in order for that question to make
> sense, I need to describe what I tried.
>
> It turns out what I missed was "make check_dtbs". I only found that out
> after an automated email from Rob describing some troubleshooting steps.
No, the dt_binding_check fails. You don't need to go to dtbs_check even,
because the binding already has a failure.
>
> If I may have a few sentences to rant, I see the dt-schema as a hurdle
> to making an otherwise useful change. I am told I can ask for help when
> I get stuck, yet I manage to insult the maintainer by aking for help. I
> find this very intimidating.
I don't feel insulted but I feel my time is wasted if I tell you to test
your binding and you immediately within few minutes respond "I tested",
but then:
1. Bot confirms it was not tested,
2. I apply your patch and test it and see the failure.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 4/9] spi: cadence-qspi: allow FIFO depth detection
From: Mark Brown @ 2024-04-10 20:03 UTC (permalink / raw)
To: Théo Lebrun
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vaishnav Achath,
Thomas Bogendoerfer, Rob Herring, linux-spi, devicetree,
linux-kernel, linux-mips, Vladimir Kondratiev, Gregory CLEMENT,
Thomas Petazzoni, Tawfik Bayouk
In-Reply-To: <20240410-cdns-qspi-mbly-v3-4-7b7053449cf7@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
On Wed, Apr 10, 2024 at 11:29:07AM +0200, Théo Lebrun wrote:
> If FIFO depth DT property is provided, check it matches what hardware
> reports and warn otherwise. Else, use hardware provided value.
>
> Hardware exposes FIFO depth indirectly because
> CQSPI_REG_SRAMPARTITION is partially read-only.
This breaks an allmodconfig build:
/build/stage/linux/drivers/spi/spi-cadence-quadspi.c: In function ‘cqspi_of_get_
pdata’:
/build/stage/linux/drivers/spi/spi-cadence-quadspi.c:1506:45: error: unused vari
able ‘ddata’ [-Werror=unused-variable]
1506 | const struct cqspi_driver_platdata *ddata = cqspi->ddata;
| ^~~~~
/build/stage/linux/drivers/spi/spi-cadence-quadspi.c: In function ‘cqspi_control
ler_detect_fifo_depth’:
/build/stage/linux/drivers/spi/spi-cadence-quadspi.c:1582:45: error: unused vari
able ‘ddata’ [-Werror=unused-variable]
1582 | const struct cqspi_driver_platdata *ddata = cqspi->ddata;
| ^~~~~
cc1: all warnings being treated as errors
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/5] dt-bindings: rng: Add vmgenid support
From: Rob Herring @ 2024-04-10 20:09 UTC (permalink / raw)
To: Sudan Landge
Cc: graf, tytso, krzysztof.kozlowski+dt, linux-kernel, xmarcalx,
robh+dt, Jason, bchalios, thomas.lendacky, dwmw, devicetree,
sathyanarayanan.kuppuswamy, conor+dt, dan.j.williams
In-Reply-To: <20240409181154.9962-5-sudanl@amazon.com>
On Tue, 09 Apr 2024 19:11:53 +0100, Sudan Landge wrote:
> Virtual Machine Generation ID driver was introduced in commit af6b54e2b5ba
> ("virt: vmgenid: notify RNG of VM fork and supply generation ID"), as an
> ACPI only device.
>
> VMGenID specification http://go.microsoft.com/fwlink/?LinkId=260709 defines
> a mechanism for the BIOS/hypervisors to communicate to the virtual machine
> that it is executed with a different configuration (e.g. snapshot execution
> or creation from a template).
> The guest operating system can use the notification for various purposes
> such as re-initializing its random number generator etc.
>
> As per the specs, hypervisor should provide a globally unique identified,
> or GUID via ACPI.
>
> This patch tries to mimic the mechanism to provide the same functionality
> which is for a hypervisor/BIOS to notify the virtual machine when it is
> executed with a different configuration.
>
> As part of this support the devicetree bindings requires the hypervisors or
> BIOS to provide a memory address which holds the GUID and an IRQ which is
> used to notify when there is a change in the GUID.
> The memory exposed in the DT should follow the rules defined in the
> vmgenid spec mentioned above.
>
> *Reason for this change*:
> Chosing ACPI or devicetree is an intrinsic part of an hypervisor design.
> Without going into details of why a hypervisor would choose DT over ACPI,
> we would like to highlight that the hypervisors that have chose devicetree
> and now want to make use of the vmgenid functionality cannot do so today
> because vmgenid is an ACPI only device.
> This forces these hypervisors to change their design which could have
> undesirable impacts on their use-cases, test-scenarios etc.
>
> vmgenid exposes to the guest a 16-byte cryptographically random number,
> the value of which changes every time it starts executing from a new
> configuration (snapshot, backup, etc.). During initialization, the device
> exposes to the guest the address of the generation ID and
> an interrupt number, which the device will use to notify the guest when
> the generation ID changes.
> These attributes can be trivially communicated via device tree bindings.
>
> We believe that adding a devicetree binding for vmgenid is a simpler
> alternative way to expose the device to the guest than forcing the
> hypervisors to implement ACPI.
>
> More references to vmgenid specs:
> - https://www.qemu.org/docs/master/specs/vmgenid.html
> - https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/virtual-
> machine-generation-identifier
>
> Signed-off-by: Sudan Landge <sudanl@amazon.com>
> ---
> .../bindings/rng/microsoft,vmgenid.yaml | 49 +++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rng/microsoft,vmgenid.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 3/9] spi: dt-bindings: cdns,qspi-nor: make cdns,fifo-depth optional
From: Rob Herring @ 2024-04-10 20:22 UTC (permalink / raw)
To: Théo Lebrun
Cc: Vladimir Kondratiev, Gregory CLEMENT, Mark Brown,
Thomas Bogendoerfer, Thomas Petazzoni, devicetree,
Krzysztof Kozlowski, Rob Herring, Tawfik Bayouk, Vaishnav Achath,
linux-kernel, linux-spi, Conor Dooley, linux-mips
In-Reply-To: <20240410-cdns-qspi-mbly-v3-3-7b7053449cf7@bootlin.com>
On Wed, 10 Apr 2024 11:29:06 +0200, Théo Lebrun wrote:
> Make cdns,fifo-depth devicetree property optional.
> Value can be detected at runtime.
>
> Upper SRAMPARTITION register bits are read-only. Procedure to find FIFO
> depth is therefore to write 0xFFFFFFFF and read back to get amount of
> writeable bits.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
> Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml | 1 -
> 1 file changed, 1 deletion(-)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: thermal: loongson,ls2k-thermal: Add Loongson-2K0500 compaible
From: Rob Herring @ 2024-04-10 20:23 UTC (permalink / raw)
To: Binbin Zhou
Cc: Rob Herring, Zhang Rui, Daniel Lezcano, Krzysztof Kozlowski,
loongson-kernel, linux-pm, Conor Dooley, devicetree, Binbin Zhou,
Yinbo Zhu, Amit Kucheria, loongarch, Huacai Chen, WANG Xuerui,
Huacai Chen, Rafael J . Wysocki
In-Reply-To: <7f6a9ea7ad32584d3d3aa1553e5cc033870fb02c.1712733065.git.zhoubinbin@loongson.cn>
On Wed, 10 Apr 2024 17:49:01 +0800, Binbin Zhou wrote:
> The thermal on the Loongson-2K0500 shares the design with the
> Loongson-2K1000. Define corresponding compatible string, having the
> loongson,ls2k1000-thermal as a fallback.
>
> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> ---
> .../devicetree/bindings/thermal/loongson,ls2k-thermal.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: rtc: lpc32xx-rtc: convert to dtschema
From: Alexandre Belloni @ 2024-04-10 20:43 UTC (permalink / raw)
To: Javier Carrasco
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue, linux-rtc, devicetree, linux-kernel,
linux-arm-kernel, linux-aspeed, linux-stm32
In-Reply-To: <20240410-rtc_dtschema-v2-2-d32a11ab0745@gmail.com>
On 10/04/2024 17:55:34+0200, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> Add the undocumented 'clocks' property.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
> .../devicetree/bindings/rtc/lpc32xx-rtc.txt | 15 --------
> .../devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml | 41 ++++++++++++++++++++++
> 2 files changed, 41 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt b/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
> deleted file mode 100644
> index a87a1e9bc060..000000000000
> --- a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -* NXP LPC32xx SoC Real Time Clock controller
> -
> -Required properties:
> -- compatible: must be "nxp,lpc3220-rtc"
> -- reg: physical base address of the controller and length of memory mapped
> - region.
> -- interrupts: The RTC interrupt
> -
> -Example:
> -
> - rtc@40024000 {
> - compatible = "nxp,lpc3220-rtc";
> - reg = <0x40024000 0x1000>;
> - interrupts = <52 0>;
> - };
> diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml b/Documentation/devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml
> new file mode 100644
> index 000000000000..62ddeef961e9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/nxp,lpc32xx-rtc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP LPC32xx SoC Real Time Clock
> +
> +maintainers:
> + - Javier Carrasco <javier.carrasco.cruz@gmail.com>
> +
> +allOf:
> + - $ref: rtc.yaml#
> +
> +properties:
> + compatible:
> + const: nxp,lpc3220-rtc
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
As I explained the clock doesn't really exist, there is no control over
it, it is a fixed 32768 Hz crystal, there is no point in describing it
as this is already the input clock of the SoC.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sa8155p-adp: use correct gpio for SDHC2 CD
From: Stephan Gerhold @ 2024-04-10 20:43 UTC (permalink / raw)
To: Volodymyr Babchuk
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20240410134022.732767-1-volodymyr_babchuk@epam.com>
On Wed, Apr 10, 2024 at 01:41:30PM +0000, Volodymyr Babchuk wrote:
> Card Detect pin for SHDC2 on SA8155P-ADP is connected to GPIO4 of
> PMM8155AU_1, not to internal TLMM. This change fixes two issues at
> once: not working ethernet (because GPIO4 is used for MAC TX) and SD
> detection.
>
> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
> ---
> arch/arm64/boot/dts/qcom/sa8155p-adp.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sa8155p-adp.dts b/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
> index 5e4287f8c8cd1..6b08ce246b78c 100644
> --- a/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
> +++ b/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
> @@ -384,7 +384,7 @@ &remoteproc_cdsp {
> &sdhc_2 {
> status = "okay";
>
> - cd-gpios = <&tlmm 4 GPIO_ACTIVE_LOW>;
> + cd-gpios = <&pmm8155au_1_gpios 4 GPIO_ACTIVE_LOW>;
Good catch!
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <&sdc2_on>;
> pinctrl-1 = <&sdc2_off>;
These two pinctrl configure "gpio96" for "sd-cd-pins". Yet another wrong
GPIO? Should probably drop that and add proper pinctrl for the actual
GPIO in the PMIC. Seems like Qualcomm configured the PMIC GPIO with
pull-up downstream [1] (not sure if this is the right file). It might be
redundant if there is an external pull-up on the board, but only the
schematic could tell that for sure.
FWIW: Looking closer at the broken commit, the regulator voltage setup
of &sdhc_2 looks suspicious too. Typically one would want a 1.8V capable
regulator for the vqmmc-supply to properly use ultra high-speed modes,
but &vreg_l13c_2p96 seems to be configured with 2.504V-2.960V at the
moment. On downstream it seems to be 1.8V-2.96V [2] (again, not sure if
this is the right file). I would recommend re-checking this too and
testing if UHS cards are detected correctly (if you have the board).
&vreg_l17a_2p96 has the same 2.504V-2.960V, but has 2.704V-2.960V
downstream [3]. This is close at least, might be fine as-is (but I'm not
convinced there is a good reason to differ there).
Thanks,
Stephan
[1]: https://git.codelinaro.org/clo/la/kernel/msm-4.14/-/blob/484af352989c912db8f3b6393fc090006029066f/arch/arm64/boot/dts/qcom/sa8155-pmic-overlay.dtsi#L206-214
[2]: https://git.codelinaro.org/clo/la/kernel/msm-4.14/-/blob/484af352989c912db8f3b6393fc090006029066f/arch/arm64/boot/dts/qcom/sa8155-regulator.dtsi#L635-642
[3]: https://git.codelinaro.org/clo/la/kernel/msm-4.14/-/blob/484af352989c912db8f3b6393fc090006029066f/arch/arm64/boot/dts/qcom/sa8155-regulator.dtsi#L363-370
^ permalink raw reply
* Re: [PATCH V5] PCI: Add support for preserving boot configuration
From: Bjorn Helgaas @ 2024-04-10 20:50 UTC (permalink / raw)
To: Vidya Sagar
Cc: bhelgaas, rafael, lenb, will, lpieralisi, kw, robh, frowand.list,
linux-pci, linux-acpi, linux-kernel, linux-arm-kernel, devicetree,
treding, jonathanh, kthota, mmaddireddy, sagar.tv
In-Reply-To: <20240401075031.3337211-1-vidyas@nvidia.com>
On Mon, Apr 01, 2024 at 01:20:31PM +0530, Vidya Sagar wrote:
> Add support for preserving the boot configuration done by the
> platform firmware per host bridge basis, based on the presence of
> 'linux,pci-probe-only' property in the respective PCI host bridge
> device-tree node. It also unifies the ACPI and DT based boot flows
> in this regard.
> drivers/acpi/pci_root.c | 12 -----
> drivers/pci/controller/pci-host-common.c | 4 --
> drivers/pci/of.c | 57 +++++++++++++++++++-----
> drivers/pci/probe.c | 46 ++++++++++++++-----
> include/linux/of_pci.h | 6 +++
> 5 files changed, 88 insertions(+), 37 deletions(-)
What does this apply to? I tried v6.9-rc1:
$ git checkout -b wip/2404-vidya-preserve-boot-v5 v6.9-rc1
Switched to a new branch 'wip/2404-vidya-preserve-boot-v5'
$ git am m/v5_20240401_vidyas_pci_add_support_for_preserving_boot_configuration.mbx
Applying: PCI: Add support for preserving boot configuration
error: patch failed: drivers/acpi/pci_root.c:1050
error: drivers/acpi/pci_root.c: patch does not apply
Patch failed at 0001 PCI: Add support for preserving boot configuration
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 84030804a763..ddc2b3e89111 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -1008,7 +1008,6 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
> int node = acpi_get_node(device->handle);
> struct pci_bus *bus;
> struct pci_host_bridge *host_bridge;
> - union acpi_object *obj;
>
> info->root = root;
> info->bridge = device;
> @@ -1050,17 +1049,6 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
> if (!(root->osc_ext_control_set & OSC_CXL_ERROR_REPORTING_CONTROL))
> host_bridge->native_cxl_error = 0;
>
> - /*
> - * Evaluate the "PCI Boot Configuration" _DSM Function. If it
> - * exists and returns 0, we must preserve any PCI resource
> - * assignments made by firmware for this host bridge.
> - */
> - obj = acpi_evaluate_dsm(ACPI_HANDLE(bus->bridge), &pci_acpi_dsm_guid, 1,
> - DSM_PCI_PRESERVE_BOOT_CONFIG, NULL);
> - if (obj && obj->type == ACPI_TYPE_INTEGER && obj->integer.value == 0)
> - host_bridge->preserve_config = 1;
> - ACPI_FREE(obj);
> -
> acpi_dev_power_up_children_with_adr(device);
>
> pci_scan_child_bus(bus);
> diff --git a/drivers/pci/controller/pci-host-common.c b/drivers/pci/controller/pci-host-common.c
> index 6be3266cd7b5..e2602e38ae45 100644
> --- a/drivers/pci/controller/pci-host-common.c
> +++ b/drivers/pci/controller/pci-host-common.c
> @@ -73,10 +73,6 @@ int pci_host_common_probe(struct platform_device *pdev)
> if (IS_ERR(cfg))
> return PTR_ERR(cfg);
>
> - /* Do not reassign resources if probe only */
> - if (!pci_has_flag(PCI_PROBE_ONLY))
> - pci_add_flags(PCI_REASSIGN_ALL_BUS);
> -
> bridge->sysdata = cfg;
> bridge->ops = (struct pci_ops *)&ops->pci_ops;
> bridge->msi_domain = true;
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 51e3dd0ea5ab..e6da3654f9ac 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -239,24 +239,61 @@ EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
> */
> void of_pci_check_probe_only(void)
> {
> - u32 val;
> + bool is_preserve_config = of_pci_bridge_preserve_resources(of_chosen);
No need for a bool here:
if (of_pci_bridge_preserve_resources(of_chosen))
pci_add_flags(PCI_PROBE_ONLY);
I think it would make more sense to add
of_pci_bridge_preserve_resources() *above* of_pci_check_probe_only()
since the usual order is to define functions earlier in the file than
the calls.
> +
> + if (is_preserve_config)
> + pci_add_flags(PCI_PROBE_ONLY);
> + else
> + pci_clear_flags(PCI_PROBE_ONLY);
Not related to *this* patch, but I see that of_pci_check_probe_only()
already clears PCI_PROBE_ONLY (added by f81c11af617c ("of/pci: Add
of_pci_check_probe_only to parse "linux,pci-probe-only"").
I'm concerned about clearing PCI_PROBE_ONLY because some platforms set
this unconditionally, and I don't think they necessarily have
"linux,pci-probe-only" in DT.
Apparently none of them currently calls of_pci_check_probe_only() so
PCI_PROBE_ONLY remains set, but clearing it here feels like a landmine
waiting for somebody to move this into a unified call path.
I guess if we were to drop pci_clear_flags(), that should be a
separate patch in case it breaks something.
> + pr_info("PROBE_ONLY %s\n", is_preserve_config ? "enabled" : "disabled");
> +}
> +EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
> +
> +/**
> + * of_pci_bridge_preserve_resources - Return true if the boot configuration
> + * needs to be preserved
> + * @node: Device tree node.
> + *
> + * This function looks for "linux,pci-probe-only" property for a given
> + * PCI controller's node and returns true if found. It will also look in the
> + * chosen node if the property is not found in the given controller's node.
> + * Having this property ensures that the kernel doesn't reconfigure the
> + * BARs and bridge windows that are already done by the platform firmware.
> + *
> + * Return: true if the property exists false otherwise.
> + */
> +bool of_pci_bridge_preserve_resources(struct device_node *node)
> +{
> + u32 val = 0;
> int ret;
>
> - ret = of_property_read_u32(of_chosen, "linux,pci-probe-only", &val);
> + if (!node) {
> + pr_warn("device node is NULL, trying with of_chosen\n");
> + node = of_chosen;
> + }
> +
> +retry:
> + ret = of_property_read_u32(node, "linux,pci-probe-only", &val);
> if (ret) {
> - if (ret == -ENODATA || ret == -EOVERFLOW)
> - pr_warn("linux,pci-probe-only without valid value, ignoring\n");
> - return;
> + if (ret == -ENODATA || ret == -EOVERFLOW) {
> + pr_warn("Incorrect value for linux,pci-probe-only in %pOF, ignoring\n", node);
> + return false;
> + }
> + if (ret == -EINVAL) {
> + if (node == of_chosen)
> + return false;
> +
> + node = of_chosen;
> + goto retry;
> + }
> }
>
> if (val)
> - pci_add_flags(PCI_PROBE_ONLY);
> + return true;
> else
> - pci_clear_flags(PCI_PROBE_ONLY);
> -
> - pr_info("PROBE_ONLY %s\n", val ? "enabled" : "disabled");
> + return false;
> }
> -EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
>
> /**
> * devm_of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 795534589b98..b0e0226a8da8 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -15,6 +15,7 @@
> #include <linux/cpumask.h>
> #include <linux/aer.h>
> #include <linux/acpi.h>
> +#include <linux/pci-acpi.h>
> #include <linux/hypervisor.h>
> #include <linux/irqdomain.h>
> #include <linux/pm_runtime.h>
> @@ -877,6 +878,28 @@ static void pci_set_bus_msi_domain(struct pci_bus *bus)
> dev_set_msi_domain(&bus->dev, d);
> }
>
> +static void pci_check_config_preserve(struct pci_host_bridge *host_bridge)
> +{
> + if (ACPI_HANDLE(&host_bridge->dev)) {
> + union acpi_object *obj;
> +
> + /*
> + * Evaluate the "PCI Boot Configuration" _DSM Function. If it
> + * exists and returns 0, we must preserve any PCI resource
> + * assignments made by firmware for this host bridge.
> + */
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(&host_bridge->dev), &pci_acpi_dsm_guid, 1,
> + DSM_PCI_PRESERVE_BOOT_CONFIG, NULL);
> + if (obj && obj->type == ACPI_TYPE_INTEGER && obj->integer.value == 0)
> + host_bridge->preserve_config = 1;
> + ACPI_FREE(obj);
> + }
> +
> + if (host_bridge->dev.parent && host_bridge->dev.parent->of_node)
> + host_bridge->preserve_config =
> + of_pci_bridge_preserve_resources(host_bridge->dev.parent->of_node);
> +}
> +
> static int pci_register_host_bridge(struct pci_host_bridge *bridge)
> {
> struct device *parent = bridge->dev.parent;
> @@ -971,6 +994,9 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge)
> if (nr_node_ids > 1 && pcibus_to_node(bus) == NUMA_NO_NODE)
> dev_warn(&bus->dev, "Unknown NUMA node; performance will be reduced\n");
>
> + /* Check if the boot configuration by FW needs to be preserved */
> + pci_check_config_preserve(bridge);
I really have an allergic reaction to functions named "..._check_..."
We can tell that the function has something to do with preserving
configuration, and it's void so obviously the side effects are the
important thing, but there's no clue in the caller about what the side
effects are.
I'd prefer something like:
bridge->preserve_config = pci_must_preserve_config(bridge);
where pci_must_preserve_config() has no side effects, returns bool,
and the action is at the caller.
> /* Coalesce contiguous windows */
> resource_list_for_each_entry_safe(window, n, &resources) {
> if (list_is_last(&window->node, &resources))
> @@ -3080,20 +3106,18 @@ int pci_host_probe(struct pci_host_bridge *bridge)
>
> bus = bridge->bus;
>
> + /* If we must preserve the resource configuration, claim now */
> + if (bridge->preserve_config)
> + pci_bus_claim_resources(bus);
> +
> /*
> - * We insert PCI resources into the iomem_resource and
> - * ioport_resource trees in either pci_bus_claim_resources()
> - * or pci_bus_assign_resources().
> + * Assign whatever was left unassigned. If we didn't claim above,
> + * this will reassign everything.
> */
> - if (pci_has_flag(PCI_PROBE_ONLY)) {
> - pci_bus_claim_resources(bus);
> - } else {
> - pci_bus_size_bridges(bus);
> - pci_bus_assign_resources(bus);
> + pci_assign_unassigned_root_bus_resources(bus);
>
> - list_for_each_entry(child, &bus->children, node)
> - pcie_bus_configure_settings(child);
> - }
> + list_for_each_entry(child, &bus->children, node)
> + pcie_bus_configure_settings(child);
>
> pci_bus_add_devices(bus);
> return 0;
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 29658c0ee71f..3f3909a5d55d 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -13,6 +13,7 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
> unsigned int devfn);
> int of_pci_get_devfn(struct device_node *np);
> void of_pci_check_probe_only(void);
> +bool of_pci_bridge_preserve_resources(struct device_node *node);
This looks like it should be in drivers/pci/pci.h since it's not used
outside drivers/pci/.
> #else
> static inline struct device_node *of_pci_find_child_device(struct device_node *parent,
> unsigned int devfn)
> @@ -26,6 +27,11 @@ static inline int of_pci_get_devfn(struct device_node *np)
> }
>
> static inline void of_pci_check_probe_only(void) { }
> +
> +static inline bool of_pci_bridge_preserve_resources(struct device_node *node)
> +{
> + return false;
> +}
> #endif
>
> #if IS_ENABLED(CONFIG_OF_IRQ)
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 1/2] media: dt-bindings: i2c: add Giantec GT97xx VCM driver
From: Rob Herring @ 2024-04-10 20:52 UTC (permalink / raw)
To: Conor Dooley
Cc: Zhi Mao, Mauro Carvalho Chehab, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Philipp Zabel,
Laurent Pinchart, Heiko Stuebner, Sakari Ailus, Hans Verkuil,
Hans de Goede, Tomi Valkeinen, Alain Volmat, Paul Elder,
Mehdi Djait, Andy Shevchenko, Bingbu Cao, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, shengnan.wang,
yaya.chang, yunkec, 10572168
In-Reply-To: <20240410-rice-fringe-4ae992217a2f@spud>
On Wed, Apr 10, 2024 at 12:27:07PM +0100, Conor Dooley wrote:
> Hey,
>
> On Wed, Apr 10, 2024 at 06:40:01PM +0800, Zhi Mao wrote:
> > Add YAML device tree binding for GT97xx VCM driver,
>
> Please don't mention drivers here, bindings are for hardware.
>
> > and the relevant MAINTAINERS entries.
> >
> > Signed-off-by: Zhi Mao <zhi.mao@mediatek.com>
> > ---
> > .../bindings/media/i2c/giantec,gt97xx.yaml | 91 +++++++++++++++++++
> > 1 file changed, 91 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/giantec,gt97xx.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/giantec,gt97xx.yaml b/Documentation/devicetree/bindings/media/i2c/giantec,gt97xx.yaml
> > new file mode 100644
> > index 000000000000..8c9f1eb4dac8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/giantec,gt97xx.yaml
> > @@ -0,0 +1,91 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/i2c/giantec,gt97xx.yaml#
>
> Filename patching compatible please.
>
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Giantec Semiconductor, Crop. GT97xx Voice Coil Motor (VCM)
> > +
> > +maintainers:
> > + - Zhi Mao <zhi.mao@mediatek.com>
> > +
> > +description: |-
> > + The Giantec GT97xx is a 10-bit DAC with current sink capability.
> > + The DAC is controlled via I2C bus that operates at clock rates up to 1MHz.
> > + This chip integrates Advanced Actuator Control (AAC) technology
> > + and is intended for driving voice coil lens in camera modules.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - giantec,gt9768 # for GT9768 VCM
> > + - giantec,gt9769 # for GT9769 VCM
>
> I don't think these comments are needed, they should be clear from the
> compatibles, no?
>
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + vin-supply: true
> > +
> > + vdd-supply: true
> > +
> > + giantec,aac-mode:
> > + description:
> > + Indication of AAC mode select.
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + enum:
> > + - 1 # AAC2 mode(operation time# 0.48 x Tvib)
> > + - 2 # AAC3 mode(operation time# 0.70 x Tvib)
> > + - 3 # AAC4 mode(operation time# 0.75 x Tvib)
> > + - 5 # AAC8 mode(operation time# 1.13 x Tvib)
>
> I dislike these enum based properties and I would rather this either be
> the values themselves (0.48, 0.70 etc).
Except that those would have to be strings for floats or fractions. For
properties which have little chance of being something common and aren't
any form of standard unit, I think it is fine to just use the h/w
specific values.
The first question to ask whether these parameters are common to
all/many voice coil motors?
> > + default: 2
> > +
> > + giantec,aac-timing:
> > + description:
> > + Number of AAC Timing count that controlled by one 6-bit period of
> > + vibration register AACT[5:0], the unit of which is 100 us.
>
> Then the property should be in a standard unit of time, not "random" hex
> numbers that correspond to register values.
Here, I agree.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: rtc: lpc32xx-rtc: convert to dtschema
From: Javier Carrasco @ 2024-04-10 20:56 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue, linux-rtc, devicetree, linux-kernel,
linux-arm-kernel, linux-aspeed, linux-stm32
In-Reply-To: <202404102043571b7450b5@mail.local>
On 4/10/24 22:43, Alexandre Belloni wrote:
> On 10/04/2024 17:55:34+0200, Javier Carrasco wrote:
>> Convert existing binding to dtschema to support validation.
>>
>> Add the undocumented 'clocks' property.
>>
>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>> ---
>> .../devicetree/bindings/rtc/lpc32xx-rtc.txt | 15 --------
>> .../devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml | 41 ++++++++++++++++++++++
>> 2 files changed, 41 insertions(+), 15 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt b/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
>> deleted file mode 100644
>> index a87a1e9bc060..000000000000
>> --- a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
>> +++ /dev/null
>> @@ -1,15 +0,0 @@
>> -* NXP LPC32xx SoC Real Time Clock controller
>> -
>> -Required properties:
>> -- compatible: must be "nxp,lpc3220-rtc"
>> -- reg: physical base address of the controller and length of memory mapped
>> - region.
>> -- interrupts: The RTC interrupt
>> -
>> -Example:
>> -
>> - rtc@40024000 {
>> - compatible = "nxp,lpc3220-rtc";
>> - reg = <0x40024000 0x1000>;
>> - interrupts = <52 0>;
>> - };
>> diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml b/Documentation/devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml
>> new file mode 100644
>> index 000000000000..62ddeef961e9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/rtc/nxp,lpc32xx-rtc.yaml
>> @@ -0,0 +1,41 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/rtc/nxp,lpc32xx-rtc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: NXP LPC32xx SoC Real Time Clock
>> +
>> +maintainers:
>> + - Javier Carrasco <javier.carrasco.cruz@gmail.com>
>> +
>> +allOf:
>> + - $ref: rtc.yaml#
>> +
>> +properties:
>> + compatible:
>> + const: nxp,lpc3220-rtc
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + clocks:
>> + maxItems: 1
>
> As I explained the clock doesn't really exist, there is no control over
> it, it is a fixed 32768 Hz crystal, there is no point in describing it
> as this is already the input clock of the SoC.
>
>
In that case the first approach was right, and it should be moved to
trivial-rtc.
I made the mistake of mentioning the driver and what it does not
support, but strictly talking about the device description, the 'clocks'
property was pointless in the dts where it was added.
If we leave it undocumented, the error I discussed with Krzysztof will
have to stay unless the 'clocks' property gets removed from the dts.
Best regards,
Javier Carrasco
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: PCI: mediatek,mt7621: add missing child node reg
From: Bjorn Helgaas @ 2024-04-10 21:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Sven Peter, Alyssa Rosenzweig, Ray Jui, Scott Branden,
Broadcom internal kernel review list, Florian Fainelli,
Jim Quinlan, Nicolas Saenz Julienne, Will Deacon, Linus Walleij,
Srikanth Thokala, Ryder Lee, Jianjun Wang, Sergio Paracuellos,
Matthias Brugger, AngeloGioacchino Del Regno, Daire McNamara,
Bjorn Andersson, Konrad Dybcio, Marek Vasut, Yoshihiro Shimoda,
Shawn Lin, Heiko Stuebner, Jingoo Han, Gustavo Pimentel,
Manivannan Sadhasivam, Bharat Kumar Gogada, Michal Simek,
Geert Uytterhoeven, Magnus Damm, Neil Armstrong, Mark Kettenis,
Tom Joseph, Ahmad Zainie, Jiaxun Yang, Kishon Vijay Abraham I,
Thippeswamy Havalige, linux-pci, devicetree, linux-kernel, asahi,
linux-arm-kernel, linux-rpi-kernel, linux-mediatek, linux-arm-msm,
linux-renesas-soc, linux-rockchip
In-Reply-To: <20240410181521.269431-2-krzysztof.kozlowski@linaro.org>
On Wed, Apr 10, 2024 at 08:15:19PM +0200, Krzysztof Kozlowski wrote:
> MT7621 PCI host bridge has children which apparently are also PCI host
> bridges, at least that's what the binding suggest.
What does it even mean for a PCI host bridge to have a child that is
also a PCI host bridge?
Does this mean a driver binds to the "parent" host bridge, enumerates
the PCI devices below it, and finds a "child" host bridge?
> The children have
> "reg" property, but do not explicitly define it. Instead they rely on
> pci-bus.yaml schema, but that one has "reg" without any constraints.
>
> Define the "reg" for the children, so the binding will be more specific
> and later will allow dropping reference to deprecated pci-bus.yaml
> schema.
>
> Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
>
> Changes in v2:
> 1. Add tags.
> ---
> .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
> index e63e6458cea8..61d027239910 100644
> --- a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
> @@ -36,6 +36,9 @@ patternProperties:
> $ref: /schemas/pci/pci-bus.yaml#
>
> properties:
> + reg:
> + maxItems: 1
> +
> resets:
> maxItems: 1
>
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH v5 1/2] dt-bindings: arm: qcom: Document the Samsung Galaxy Z Fold5
From: Alexandru Marc Serdeliuc via B4 Relay @ 2024-04-10 21:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Alexandru Marc Serdeliuc
In-Reply-To: <20240410-samsung-galaxy-zfold5-q5q-v5-0-9311ee9a55f7@yahoo.com>
From: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
This documents Samsung Galaxy Z Fold5 (samsung,q5q)
which is a foldable phone by Samsung based on the sm8550 SoC.
Signed-off-by: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 66beaac60e1d..dea2a23b8fc2 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1003,6 +1003,7 @@ properties:
- qcom,sm8550-hdk
- qcom,sm8550-mtp
- qcom,sm8550-qrd
+ - samsung,q5q
- const: qcom,sm8550
- items:
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/2] Samsung Galaxy Z Fold5 initial support
From: Alexandru Marc Serdeliuc via B4 Relay @ 2024-04-10 21:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Alexandru Marc Serdeliuc
This documents and add intial dts support for Samsung Galaxy Z Fold5 (samsung,q5q)
which is a foldable phone by Samsung based on the sm8550 SoC.
ChangeLog
- v5
. Added ChangeLog
. Added missing Acked-by tags in their respective section in ChangeLog
- v4
. removed a spurious new line
. removed pcie_1_phy_aux_clk as requested
. removed secondary pcie1 which does not exists on the device
. changed firmware extension from .mbn to .mdt
. added missing reserved memory regions required by firmware to properly load
- v3
. added b4 version 3
. removed address and size cells in device description
Acked-by: Rob Herring <robh@kernel.org>
- v2
. added both but added an extra v2 in the subject line instead to b4 subject header, was requested to send the patch again, along with following mods:
. removed whole bootargs line
. fixed underscores in reserved memory by removing all reserved memory regions
. added missing idetation to spash_screen remark
. validated the dts with "dtbs_check"
. removed all comments at the end of nodes
. moved status of the node at the end of the node
. reversed pin control name with control numbers
. ordered the nodes alphabetically
- v1
. The initial request was split in two patches sent due to the following checkpatch warning, was requested to re send them together:
WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.rst
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
---
Alexandru Marc Serdeliuc (2):
dt-bindings: arm: qcom: Document the Samsung Galaxy Z Fold5
arm64: dts: qcom: sm8550: Add support for Samsung Galaxy Z Fold5
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts | 593 ++++++++++++++++++++++++
3 files changed, 595 insertions(+)
---
base-commit: 2c71fdf02a95b3dd425b42f28fd47fb2b1d22702
change-id: 20240410-samsung-galaxy-zfold5-q5q-d31cdeeac09f
Best regards,
--
Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
^ permalink raw reply
* [PATCH v5 2/2] arm64: dts: qcom: sm8550: Add support for Samsung Galaxy Z Fold5
From: Alexandru Marc Serdeliuc via B4 Relay @ 2024-04-10 21:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Alexandru Marc Serdeliuc
In-Reply-To: <20240410-samsung-galaxy-zfold5-q5q-v5-0-9311ee9a55f7@yahoo.com>
From: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
Add support for Samsung Galaxy Z Fold5 (q5q) foldable phone based on sm8550
Currently working features:
- Framebuffer
- UFS
- i2c
- Buttons
Signed-off-by: Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts | 593 ++++++++++++++++++++++++
2 files changed, 594 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 7d40ec5e7d21..a7503fd35b6c 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -241,6 +241,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8450-sony-xperia-nagara-pdx224.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-qrd.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm8550-samsung-q5q.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += x1e80100-crd.dtb
diff --git a/arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts b/arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts
new file mode 100644
index 000000000000..4654ae1364ba
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts
@@ -0,0 +1,593 @@
+// SPDX-License-cdsp_memIdentifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024, Alexandru Marc Serdeliuc <serdeliuk@yahoo.com>
+ * Copyright (c) 2024, David Wronek <david@mainlining.org>
+ * Copyright (c) 2022, Linaro Limited
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "sm8550.dtsi"
+#include "pm8550.dtsi"
+#include "pm8550vs.dtsi"
+#include "pmk8550.dtsi"
+
+/delete-node/ &adspslpi_mem;
+/delete-node/ &cdsp_mem;
+/delete-node/ &mpss_dsm_mem;
+/delete-node/ &mpss_mem;
+/delete-node/ &rmtfs_mem;
+
+/ {
+ model = "Samsung Galaxy Z Fold5";
+ compatible = "samsung,q5q", "qcom,sm8550";
+ chassis-type = "handset";
+
+ aliases {
+ serial0 = &uart7;
+ };
+
+ chosen {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ framebuffer: framebuffer@b8000000 {
+ compatible = "simple-framebuffer";
+ reg = <0x0 0xb8000000 0x0 0x2b00000>;
+ width = <2176>;
+ height = <1812>;
+ stride = <(2176 * 4)>;
+ format = "a8r8g8b8";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&volume_up_n>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+ gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
+ debounce-interval = <15>;
+ linux,can-disable;
+ wakeup-source;
+ };
+ };
+
+ vph_pwr: vph-pwr-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ reserved-memory {
+ adspslpi_mem: adspslpi@9ea00000 {
+ reg = <0x0 0x9ea00000 0x0 0x59b4000>;
+ no-map;
+ };
+
+ cdsp_mem: cdsp-region@9c900000 {
+ reg = <0 0x9c900000 0 0x2000000>;
+ no-map;
+ };
+
+ mpss_dsm_mem: mpss-dsm@d4d00000 {
+ reg = <0x0 0xd4d00000 0x0 0x3300000>;
+ no-map;
+ };
+
+ mpss_mem: mpss@8b400000 {
+ reg = <0x0 0x8b400000 0x0 0xfc00000>;
+ no-map;
+ };
+
+ rmtfs_mem: rmtfs-region@d4a80000 {
+ reg = <0x0 0xd4a80000 0x0 0x280000>;
+ no-map;
+ };
+
+ /*
+ * The bootloader will only keep display hardware enabled
+ * if this memory region is named exactly 'splash_region'
+ */
+ splash_region@b8000000 {
+ reg = <0x0 0xb8000000 0x0 0x2b00000>;
+ no-map;
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm8550-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vreg_bob1: bob1 {
+ regulator-name = "vreg_bob1";
+ regulator-min-microvolt = <3296000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_bob2: bob2 {
+ regulator-name = "vreg_bob2";
+ regulator-min-microvolt = <2720000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1b_1p8: ldo1 {
+ regulator-name = "vreg_l1b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2b_3p0: ldo2 {
+ regulator-name = "vreg_l2b_3p0";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5b_3p1: ldo5 {
+ regulator-name = "vreg_l5b_3p1";
+ regulator-min-microvolt = <3104000>;
+ regulator-max-microvolt = <3104000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6b_1p8: ldo6 {
+ regulator-name = "vreg_l6b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_1p8: ldo7 {
+ regulator-name = "vreg_l7b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8b_1p8: ldo8 {
+ regulator-name = "vreg_l8b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_2p9: ldo9 {
+ regulator-name = "vreg_l9b_2p9";
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11b_1p2: ldo11 {
+ regulator-name = "vreg_l11b_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1504000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12b_1p8: ldo12 {
+ regulator-name = "vreg_l12b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l13b_3p0: ldo13 {
+ regulator-name = "vreg_l13b_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l14b_3p2: ldo14 {
+ regulator-name = "vreg_l14b_3p2";
+ regulator-min-microvolt = <3200000>;
+ regulator-max-microvolt = <3200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_1p8: ldo15 {
+ regulator-name = "vreg_l15b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ regulator-always-on;
+ };
+
+ vreg_l16b_2p8: ldo16 {
+ regulator-name = "vreg_l16b_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_2p5: ldo17 {
+ regulator-name = "vreg_l17b_2p5";
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <2504000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vreg_l3c_0p91: ldo3 {
+ regulator-name = "vreg_l3c_0p9";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-2 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "d";
+
+ vreg_l1d_0p88: ldo1 {
+ regulator-name = "vreg_l1d_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-3 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "e";
+
+ vreg_s4e_0p9: smps4 {
+ regulator-name = "vreg_s4e_0p9";
+ regulator-min-microvolt = <904000>;
+ regulator-max-microvolt = <984000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5e_1p1: smps5 {
+ regulator-name = "vreg_s5e_1p1";
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <1120000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1e_0p88: ldo1 {
+ regulator-name = "vreg_l1e_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <880000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2e_0p9: ldo2 {
+ regulator-name = "vreg_l2e_0p9";
+ regulator-min-microvolt = <904000>;
+ regulator-max-microvolt = <970000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3e_1p2: ldo3 {
+ regulator-name = "vreg_l3e_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-4 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+ qcom,pmic-id = "f";
+
+ vreg_s4f_0p5: smps4 {
+ regulator-name = "vreg_s4f_0p5";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <700000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1f_0p9: ldo1 {
+ regulator-name = "vreg_l1f_0p9";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2f_0p88: ldo2 {
+ regulator-name = "vreg_l2f_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3f_0p91: ldo3 {
+ regulator-name = "vreg_l3f_0p91";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-5 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "g";
+
+ vreg_s1g_1p2: smps1 {
+ regulator-name = "vreg_s1g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s2g_0p8: smps2 {
+ regulator-name = "vreg_s2g_0p8";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s3g_0p7: smps3 {
+ regulator-name = "vreg_s3g_0p7";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1004000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4g_1p3: smps4 {
+ regulator-name = "vreg_s4g_1p3";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1352000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5g_0p8: smps5 {
+ regulator-name = "vreg_s5g_0p8";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1004000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s6g_1p8: smps6 {
+ regulator-name = "vreg_s6g_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1g_1p2: ldo1 {
+ regulator-name = "vreg_l1g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2g_1p2: ldo2 {
+ regulator-name = "vreg_l2g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3g_1p2: ldo3 {
+ regulator-name = "vreg_l3g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-6 {
+ compatible = "qcom,pm8010-rpmh-regulators";
+ qcom,pmic-id = "m";
+
+ vreg_l1m_1p056: ldo1 {
+ regulator-name = "vreg_l1m_1p056";
+ regulator-min-microvolt = <1056000>;
+ regulator-max-microvolt = <1056000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2m_1p056: ldo2 {
+ regulator-name = "vreg_l2m_1p056";
+ regulator-min-microvolt = <1056000>;
+ regulator-max-microvolt = <1056000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3m_2p8: ldo3 {
+ regulator-name = "vreg_l3m_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4m_2p8: ldo4 {
+ regulator-name = "vreg_l4m_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5m_1p8: ldo5 {
+ regulator-name = "vreg_l5m_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6m_1p8: ldo6 {
+ regulator-name = "vreg_l6m_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7m_2p9: ldo7 {
+ regulator-name = "vreg_l7m_2p9";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2904000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-7 {
+ compatible = "qcom,pm8010-rpmh-regulators";
+ qcom,pmic-id = "n";
+
+ vreg_l1n_1p1: ldo1 {
+ regulator-name = "vreg_l1n_1p1";
+ regulator-min-microvolt = <1104000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2n_1p1: ldo2 {
+ regulator-name = "vreg_l2n_1p1";
+ regulator-min-microvolt = <1104000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3n_2p8: ldo3 {
+ regulator-name = "vreg_l3n_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4n_2p8: ldo4 {
+ regulator-name = "vreg_l4n_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5n_1p8: ldo5 {
+ regulator-name = "vreg_l5n_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6n_3p3: ldo6 {
+ regulator-name = "vreg_l6n_3p3";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7n_2p96: ldo7 {
+ regulator-name = "vreg_l7n_2p96";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&dispcc {
+ status = "disabled";
+};
+
+&i2c_master_hub_0 {
+ status = "okay";
+};
+
+&pcie0 {
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&pcie0_phy {
+ vdda-phy-supply = <&vreg_l1e_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+ status = "okay";
+};
+
+&pm8550_gpios {
+ volume_up_n: volume-up-n-state {
+ pins = "gpio6";
+ function = "normal";
+ power-source = <1>;
+ bias-pull-up;
+ input-enable;
+ };
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ status = "okay";
+ linux,code = <KEY_VOLUMEDOWN>;
+};
+
+&qupv3_id_0 {
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/sm8550/adsp.mdt",
+ "qcom/sm8550/adsp_dtb.mdt";
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm8550/cdsp.mdt",
+ "qcom/sm8550/cdsp_dtb.mdt";
+ status = "okay";
+};
+
+&remoteproc_mpss {
+ firmware-name = "qcom/sm8550/modem.mdt",
+ "qcom/sm8550/modem_dtb.mdt";
+ status = "okay";
+};
+
+&sleep_clk {
+ clock-frequency = <32000>;
+};
+
+&tlmm {
+ gpio-reserved-ranges = <36 4>, <50 2>;
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l17b_2p5>;
+ vcc-max-microamp = <1300000>;
+ vccq-supply = <&vreg_l1g_1p2>;
+ vccq-max-microamp = <1200000>;
+ vdd-hba-supply = <&vreg_l3g_1p2>;
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l1d_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+ status = "okay";
+};
+
+&xo_board {
+ clock-frequency = <76800000>;
+};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 07/10] riscv: add ISA extension parsing for Zcmop
From: Deepak Gupta @ 2024-04-10 21:32 UTC (permalink / raw)
To: Clément Léger
Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Anup Patel,
Shuah Khan, Atish Patra, linux-doc, linux-riscv, linux-kernel,
devicetree, kvm, kvm-riscv, linux-kselftest
In-Reply-To: <20240410091106.749233-8-cleger@rivosinc.com>
On Wed, Apr 10, 2024 at 11:11:00AM +0200, Clément Léger wrote:
>Add parsing for Zcmop ISA extension which was ratified in commit
>b854a709c00 ("Zcmop is ratified/1.0") of the riscv-isa-manual.
>
>Signed-off-by: Clément Léger <cleger@rivosinc.com>
>---
> arch/riscv/include/asm/hwcap.h | 1 +
> arch/riscv/kernel/cpufeature.c | 1 +
> 2 files changed, 2 insertions(+)
>
>diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
>index b7551bad341b..cff7660de268 100644
>--- a/arch/riscv/include/asm/hwcap.h
>+++ b/arch/riscv/include/asm/hwcap.h
>@@ -86,6 +86,7 @@
> #define RISCV_ISA_EXT_ZCB 77
> #define RISCV_ISA_EXT_ZCD 78
> #define RISCV_ISA_EXT_ZCF 79
>+#define RISCV_ISA_EXT_ZCMOP 80
>
> #define RISCV_ISA_EXT_XLINUXENVCFG 127
>
>diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
>index 09dee071274d..f1450cd7231e 100644
>--- a/arch/riscv/kernel/cpufeature.c
>+++ b/arch/riscv/kernel/cpufeature.c
>@@ -265,6 +265,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
> __RISCV_ISA_EXT_DATA(zcb, RISCV_ISA_EXT_ZCB),
> __RISCV_ISA_EXT_DATA(zcd, RISCV_ISA_EXT_ZCD),
> __RISCV_ISA_EXT_DATA(zcf, RISCV_ISA_EXT_ZCF),
>+ __RISCV_ISA_EXT_DATA(zcmop, RISCV_ISA_EXT_ZCMOP),
As per spec zcmop is dependent on zca. So perhaps below ?
__RISCV_ISA_EXT_SUPERSET(zicboz, RISCV_ISA_EXT_ZCMOP, RISCV_ISA_EXT_ZCA)
> __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA),
> __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
> __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC),
>--
>2.43.0
>
>
^ permalink raw reply
* Re: [PATCH 00/10] Add support for a few Zc* extensions as well as Zcmop
From: Deepak Gupta @ 2024-04-10 21:34 UTC (permalink / raw)
To: Clément Léger
Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Anup Patel,
Shuah Khan, Atish Patra, linux-doc, linux-riscv, linux-kernel,
devicetree, kvm, kvm-riscv, linux-kselftest
In-Reply-To: <20240410091106.749233-1-cleger@rivosinc.com>
For the series:
Reviewed-by: Deepak Gupta <debug@rivosinc.com>
On Wed, Apr 10, 2024 at 2:13 AM Clément Léger <cleger@rivosinc.com> wrote:
>
> Add support for (yet again) more RVA23U64 missing extensions. Add
> support for Zcmop, Zca, Zcf, Zcd and Zcb extensions isa string parsing,
> hwprobe and kvm support. Zce, Zcmt and Zcmp extensions have been left
> out since they target microcontrollers/embedded CPUs and are not needed
> by RVA23U64
>
> This series is based on the Zimop one [1].
>
> Link: https://lore.kernel.org/linux-riscv/20240404103254.1752834-1-cleger@rivosinc.com/ [1]
>
> Clément Léger (10):
> dt-bindings: riscv: add Zca, Zcf, Zcd and Zcb ISA extension
> description
> riscv: add ISA parsing for Zca, Zcf, Zcd and Zcb
> riscv: hwprobe: export Zca, Zcf, Zcd and Zcb ISA extensions
> RISC-V: KVM: Allow Zca, Zcf, Zcd and Zcb extensions for Guest/VM
> KVM: riscv: selftests: Add some Zc* extensions to get-reg-list test
> dt-bindings: riscv: add Zcmop ISA extension description
> riscv: add ISA extension parsing for Zcmop
> riscv: hwprobe: export Zcmop ISA extension
> RISC-V: KVM: Allow Zcmop extension for Guest/VM
> KVM: riscv: selftests: Add Zcmop extension to get-reg-list test
>
> Documentation/arch/riscv/hwprobe.rst | 24 ++++++++++++
> .../devicetree/bindings/riscv/extensions.yaml | 37 +++++++++++++++++++
> arch/riscv/include/asm/hwcap.h | 5 +++
> arch/riscv/include/uapi/asm/hwprobe.h | 5 +++
> arch/riscv/include/uapi/asm/kvm.h | 5 +++
> arch/riscv/kernel/cpufeature.c | 5 +++
> arch/riscv/kernel/sys_hwprobe.c | 5 +++
> arch/riscv/kvm/vcpu_onereg.c | 10 +++++
> .../selftests/kvm/riscv/get-reg-list.c | 20 ++++++++++
> 9 files changed, 116 insertions(+)
>
> --
> 2.43.0
>
>
^ 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