* [PATCH v4 0/2] dt-bindings: interrupt-controller: sifive, plic: Miscellaneous improvements
From: Geert Uytterhoeven @ 2022-01-28 9:03 UTC (permalink / raw)
To: Thomas Gleixner, Marc Zyngier, Palmer Dabbelt, Paul Walmsley,
Sagar Kadam
Cc: Rob Herring, linux-kernel, devicetree, linux-riscv,
Geert Uytterhoeven
Hi all,
This patch series contains two improvements for the SiFive PLIC DT
bindings.
Changes compared to v3[1]:
- Use architectural maximum instead of practical maximum of 9,
Changes compared to v2[2]:
- Add Acked-by, Reviewed-by.
Changes compared to v1[3]:
- Split in two patches,
- Improve patch description and document limit rationale.
Thanks!
[1] https://lore.kernel.org/r/cover.1639744106.git.geert@linux-m68k.org/
[2] https://lore.kernel.org/r/cover.1639661878.git.geert@linux-m68k.org
[3] https://lore.kernel.org/r/20211125152233.162868-1-geert@linux-m68k.org
Geert Uytterhoeven (2):
dt-bindings: interrupt-controller: sifive,plic: Fix number of
interrupts
dt-bindings: interrupt-controller: sifive,plic: Group interrupt tuples
.../interrupt-controller/sifive,plic-1.0.0.yaml | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 2/2] dt-bindings: interrupt-controller: sifive,plic: Group interrupt tuples
From: Geert Uytterhoeven @ 2022-01-28 9:03 UTC (permalink / raw)
To: Thomas Gleixner, Marc Zyngier, Palmer Dabbelt, Paul Walmsley,
Sagar Kadam
Cc: Rob Herring, linux-kernel, devicetree, linux-riscv,
Geert Uytterhoeven, Rob Herring
In-Reply-To: <cover.1643360419.git.geert@linux-m68k.org>
To improve human readability and enable automatic validation, the tuples
in "interrupts-extended" properties should be grouped using angle
brackets.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v4:
- No changes,
v3:
- Add Reviewed-by,
v2:
- Split in two patches.
---
.../interrupt-controller/sifive,plic-1.0.0.yaml | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index 57c06126c99502fa..0dfa6b26e09910a8 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -91,12 +91,11 @@ examples:
#interrupt-cells = <1>;
compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0";
interrupt-controller;
- interrupts-extended = <
- &cpu0_intc 11
- &cpu1_intc 11 &cpu1_intc 9
- &cpu2_intc 11 &cpu2_intc 9
- &cpu3_intc 11 &cpu3_intc 9
- &cpu4_intc 11 &cpu4_intc 9>;
+ interrupts-extended = <&cpu0_intc 11>,
+ <&cpu1_intc 11>, <&cpu1_intc 9>,
+ <&cpu2_intc 11>, <&cpu2_intc 9>,
+ <&cpu3_intc 11>, <&cpu3_intc 9>,
+ <&cpu4_intc 11>, <&cpu4_intc 9>;
reg = <0xc000000 0x4000000>;
riscv,ndev = <10>;
};
--
2.25.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: interrupt-controller: sifive,plic: Fix number of interrupts
From: Geert Uytterhoeven @ 2022-01-28 9:03 UTC (permalink / raw)
To: Thomas Gleixner, Marc Zyngier, Palmer Dabbelt, Paul Walmsley,
Sagar Kadam
Cc: Rob Herring, linux-kernel, devicetree, linux-riscv,
Geert Uytterhoeven, Rob Herring
In-Reply-To: <cover.1643360419.git.geert@linux-m68k.org>
The number of interrupts lacks an upper bound, thus assuming one,
causing properly grouped "interrupts-extended" properties to be flagged
as an error by "make dtbs_check".
Fix this by adding the missing "maxItems", using the architectural
maximum of 15872 interrupts.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Herring <robh@kernel.org>
---
v4:
- Use architectural maximum instead of practical maximum of 9,
v3:
- Add Acked-by,
v2:
- Split in two patches,
- Improve patch description and document limit rationale.
---
.../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index 28b6b17fe4b26778..57c06126c99502fa 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -62,6 +62,7 @@ properties:
interrupts-extended:
minItems: 1
+ maxItems: 15872
description:
Specifies which contexts are connected to the PLIC, with "-1" specifying
that a context is not present. Each node pointed to should be a
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 1/2] dt-bindings: interrupt-controller: sifive, plic: Fix number of interrupts
From: Anup Patel @ 2022-01-28 9:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Gleixner, Marc Zyngier, Palmer Dabbelt, Paul Walmsley,
Sagar Kadam, Rob Herring, linux-kernel@vger.kernel.org List, DTML,
linux-riscv, Rob Herring
In-Reply-To: <f73a0aead89e1426b146c4c64f797aa035868bf0.1643360419.git.geert@linux-m68k.org>
On Fri, Jan 28, 2022 at 2:34 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> The number of interrupts lacks an upper bound, thus assuming one,
> causing properly grouped "interrupts-extended" properties to be flagged
> as an error by "make dtbs_check".
>
> Fix this by adding the missing "maxItems", using the architectural
> maximum of 15872 interrupts.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Acked-by: Rob Herring <robh@kernel.org>
Looks good to me.
Reviewed-by: Anup Patel <anup@brainfault.org>
Regards,
Anup
> ---
> v4:
> - Use architectural maximum instead of practical maximum of 9,
>
> v3:
> - Add Acked-by,
>
> v2:
> - Split in two patches,
> - Improve patch description and document limit rationale.
> ---
> .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> index 28b6b17fe4b26778..57c06126c99502fa 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> @@ -62,6 +62,7 @@ properties:
>
> interrupts-extended:
> minItems: 1
> + maxItems: 15872
> description:
> Specifies which contexts are connected to the PLIC, with "-1" specifying
> that a context is not present. Each node pointed to should be a
> --
> 2.25.1
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH v4 2/2] dt-bindings: interrupt-controller: sifive,plic: Group interrupt tuples
From: Anup Patel @ 2022-01-28 9:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Gleixner, Marc Zyngier, Palmer Dabbelt, Paul Walmsley,
Sagar Kadam, Rob Herring, linux-kernel@vger.kernel.org List, DTML,
linux-riscv, Rob Herring
In-Reply-To: <211705e74a2ce77de43d036c5dea032484119bf7.1643360419.git.geert@linux-m68k.org>
On Fri, Jan 28, 2022 at 2:34 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> To improve human readability and enable automatic validation, the tuples
> in "interrupts-extended" properties should be grouped using angle
> brackets.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
Looks good to me.
Reviewed-by: Anup Patel <anup@brainfault.org>
Regards,
Anup
> ---
> v4:
> - No changes,
>
> v3:
> - Add Reviewed-by,
>
> v2:
> - Split in two patches.
> ---
> .../interrupt-controller/sifive,plic-1.0.0.yaml | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> index 57c06126c99502fa..0dfa6b26e09910a8 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> @@ -91,12 +91,11 @@ examples:
> #interrupt-cells = <1>;
> compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0";
> interrupt-controller;
> - interrupts-extended = <
> - &cpu0_intc 11
> - &cpu1_intc 11 &cpu1_intc 9
> - &cpu2_intc 11 &cpu2_intc 9
> - &cpu3_intc 11 &cpu3_intc 9
> - &cpu4_intc 11 &cpu4_intc 9>;
> + interrupts-extended = <&cpu0_intc 11>,
> + <&cpu1_intc 11>, <&cpu1_intc 9>,
> + <&cpu2_intc 11>, <&cpu2_intc 9>,
> + <&cpu3_intc 11>, <&cpu3_intc 9>,
> + <&cpu4_intc 11>, <&cpu4_intc 9>;
> reg = <0xc000000 0x4000000>;
> riscv,ndev = <10>;
> };
> --
> 2.25.1
>
^ permalink raw reply
* [PATCH v4 0/2] dt-bindings: timer: sifive, clint: Miscellaneous improvements
From: Geert Uytterhoeven @ 2022-01-28 9:07 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Palmer Dabbelt, Paul Walmsley,
Anup Patel
Cc: Rob Herring, linux-kernel, devicetree, linux-riscv,
Geert Uytterhoeven
Hi all,
This patch series contains two improvements for the SiFive CLINT DT
bindings.
Changes compared to v3[1]:
- Use architectural maximum instead of practical maximum of 10,
- Add Reviewed-by (this time for real ;-).
Changes compared to v2[2]:
- Add Acked-by, Reviewed-by.
Changes compared to v1[3]:
- Split in two patches,
- Improve patch description and document limit rationale.
Thanks!
[1] https://lore.kernel.org/r/cover.1639744468.git.geert@linux-m68k.org/
[2] https://lore.kernel.org/r/cover.1639662093.git.geert@linux-m68k.org
[3] https://lore.kernel.org/r/20211125152317.162958-1-geert@linux-m68k.org
Geert Uytterhoeven (2):
dt-bindings: timer: sifive,clint: Fix number of interrupts
dt-bindings: timer: sifive,clint: Group interrupt tuples
.../devicetree/bindings/timer/sifive,clint.yaml | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: timer: sifive,clint: Fix number of interrupts
From: Geert Uytterhoeven @ 2022-01-28 9:07 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Palmer Dabbelt, Paul Walmsley,
Anup Patel
Cc: Rob Herring, linux-kernel, devicetree, linux-riscv,
Geert Uytterhoeven, Rob Herring
In-Reply-To: <cover.1643360652.git.geert@linux-m68k.org>
The number of interrupts lacks an upper bound, thus assuming one,
causing properly grouped "interrupts-extended" properties to be flagged
as an error by "make dtbs_check".
Fix this by adding the missing "maxItems", using the architectural
maximum of 4095 interrupts.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Herring <robh@kernel.org>
---
v4:
- Use architectural maximum instead of practical maximum of 10,
v3:
- Add Acked-by,
v2:
- Split in two patches,
- Improve patch description and document limit rationale.
---
Documentation/devicetree/bindings/timer/sifive,clint.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index 8d5f4687add9e81e..fe4b73c3f269fc0f 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -44,6 +44,7 @@ properties:
interrupts-extended:
minItems: 1
+ maxItems: 4095
additionalProperties: false
--
2.25.1
^ permalink raw reply related
* [PATCH v4 2/2] dt-bindings: timer: sifive,clint: Group interrupt tuples
From: Geert Uytterhoeven @ 2022-01-28 9:07 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Palmer Dabbelt, Paul Walmsley,
Anup Patel
Cc: Rob Herring, linux-kernel, devicetree, linux-riscv,
Geert Uytterhoeven, Rob Herring
In-Reply-To: <cover.1643360652.git.geert@linux-m68k.org>
To improve human readability and enable automatic validation, the tuples
in "interrupts-extended" properties should be grouped using angle
brackets.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v4:
- Add Reviewed-by (this time for real ;-),
v3:
- Add Reviewed-by,
v2:
- Split in two patches.
---
Documentation/devicetree/bindings/timer/sifive,clint.yaml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index fe4b73c3f269fc0f..e64f46339079fa3f 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -57,10 +57,10 @@ examples:
- |
timer@2000000 {
compatible = "sifive,fu540-c000-clint", "sifive,clint0";
- interrupts-extended = <&cpu1intc 3 &cpu1intc 7
- &cpu2intc 3 &cpu2intc 7
- &cpu3intc 3 &cpu3intc 7
- &cpu4intc 3 &cpu4intc 7>;
+ interrupts-extended = <&cpu1intc 3>, <&cpu1intc 7>,
+ <&cpu2intc 3>, <&cpu2intc 7>,
+ <&cpu3intc 3>, <&cpu3intc 7>,
+ <&cpu4intc 3>, <&cpu4intc 7>;
reg = <0x2000000 0x10000>;
};
...
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 2/2] iommu/mediatek: Add mt8186 iommu support
From: Yong Wu @ 2022-01-28 9:39 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu, Joerg Roedel,
Rob Herring, Matthias Brugger, Will Deacon
In-Reply-To: <b52a1df8-58f4-baa2-cfb6-9c56244caa0f@collabora.com>
On Thu, 2022-01-27 at 12:28 +0100, AngeloGioacchino Del Regno wrote:
> Il 25/01/22 10:32, Yong Wu ha scritto:
> > Add mt8186 iommu supports.
> >
> > Signed-off-by: Anan Sun <anan.sun@mediatek.com>
> > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > ---
> > drivers/iommu/mtk_iommu.c | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
[snip]
> > static const struct mtk_iommu_plat_data mt8192_data = {
> > .m4u_plat = M4U_MT8192,
> > .flags = HAS_BCLK | HAS_SUB_COMM_2BITS |
> > OUT_ORDER_WR_EN |
> > @@ -1470,6 +1486,7 @@ static const struct of_device_id
> > mtk_iommu_of_ids[] = {
> > { .compatible = "mediatek,mt8167-m4u", .data = &mt8167_data},
> > { .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
> > { .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
> > + { .compatible = "mediatek,mt8186-iommu-mm", .data =
> > &mt8186_data_mm},
>
> Hello!
>
> Is there any particular reason why this compatible is not
> "mediatek,mt8186-m4u"?
There is no special reason. In the previous SoC, We only support MM
IOMMU, it was called by "m4u". In the lastest SoC, We have the other
types IOMMU, like for INFRA masters and APU, thus they are called "mm
iommu", "infra iommu" and "apu iommu". Of course, "m4u" means "mm
iommu".
>
> Thanks,
> Angelo
>
> > { .compatible = "mediatek,mt8192-m4u", .data = &mt8192_data},
> > { .compatible = "mediatek,mt8195-iommu-infra", .data =
> > &mt8195_data_infra},
> > { .compatible = "mediatek,mt8195-iommu-vdo", .data =
> > &mt8195_data_vdo},
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v21 3/4] PCI: microchip: Add host driver for Microchip PCIe controller
From: Marc Zyngier @ 2022-01-28 9:55 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: daire.mcnamara, lorenzo.pieralisi, bhelgaas, robh, linux-pci,
robh+dt, devicetree, david.abdurachmanov, cyril.jean
In-Reply-To: <20220127202000.GA126335@bhelgaas>
On Thu, 27 Jan 2022 20:20:00 +0000,
Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> [+cc Marc]
>
> On Mon, Jan 25, 2021 at 04:29:33PM +0000, daire.mcnamara@microchip.com wrote:
> > From: Daire McNamara <daire.mcnamara@microchip.com>
> >
> > Add support for the Microchip PolarFire PCIe controller when
> > configured in host (Root Complex) mode.
>
> > +static void mc_handle_msi(struct irq_desc *desc)
> > +{
> > + struct mc_port *port = irq_desc_get_handler_data(desc);
> > + struct device *dev = port->dev;
> > + struct mc_msi *msi = &port->msi;
> > + void __iomem *bridge_base_addr = port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
> > + unsigned long status;
> > + u32 bit;
> > + u32 virq;
> > +
> > + status = readl_relaxed(bridge_base_addr + ISTATUS_LOCAL);
> > + if (status & PM_MSI_INT_MSI_MASK) {
> > + status = readl_relaxed(bridge_base_addr + ISTATUS_MSI);
> > + for_each_set_bit(bit, &status, msi->num_vectors) {
> > + virq = irq_find_mapping(msi->dev_domain, bit);
> > + if (virq)
> > + generic_handle_irq(virq);
Wrong construct. Please use generic_handle_domain_irq().
> > + else
> > + dev_err_ratelimited(dev, "bad MSI IRQ %d\n", bit);
> > + }
> > + }
> > +}
> > +
> > +static void mc_msi_bottom_irq_ack(struct irq_data *data)
> > +{
> > + struct mc_port *port = irq_data_get_irq_chip_data(data);
> > + void __iomem *bridge_base_addr = port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
> > + u32 bitpos = data->hwirq;
> > + unsigned long status;
> > +
> > + writel_relaxed(BIT(bitpos), bridge_base_addr + ISTATUS_MSI);
> > + status = readl_relaxed(bridge_base_addr + ISTATUS_MSI);
> > + if (!status)
> > + writel_relaxed(BIT(PM_MSI_INT_MSI_SHIFT), bridge_base_addr + ISTATUS_LOCAL);
>
> This looks like it might be racy. What happens if we read 0 from
> ISTATUS_MSI, but a new MSI is latched before we write ISTATUS_LOCAL?
I agree, this looks really odd. The irq_ack callback is per interrupt,
while this seems to deal with some global state. This cannot be right.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics
From: Krzysztof Kozlowski @ 2022-01-28 9:57 UTC (permalink / raw)
To: Luca Weiss, Petr Vorel, linux-arm-msm, Rob Herring
Cc: Shawn Guo, Oleksij Rempel, Sam Ravnborg, Linus Walleij,
Daniel Palmer, Max Merchel, Hao Fang, devicetree, linux-kernel,
Jean THOMAS
In-Reply-To: <5883435.31r3eYUQgx@g550jk>
On 27/01/2022 21:51, Luca Weiss wrote:
> Hi all,
>
> On Donnerstag, 27. Jänner 2022 08:45:33 CET Krzysztof Kozlowski wrote:
>> On 27/01/2022 01:20, Petr Vorel wrote:
>>> Hi all,
>>>
>>>>> Hi Krzysztof,
>>>>>
>>>>> On Montag, 13. September 2021 10:49:43 CEST Krzysztof Kozlowski wrote:
>>>>>> On 12/09/2021 01:27, Luca Weiss wrote:
>>>>>>> LG Electronics is a part of the LG Corporation and produces, amongst
>>>>>>> other things, consumer electronics such as phones and smartwatches.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for the patches.
>>>>>>
>>>>>> I think "lge" it's the same prefix as "lg". There is no sense in having
>>>>>> multiple vendor prefixes just because company splits inside business
>>>>>> units or subsidiaries. The same as with other conglomerates, e.g.
>>>>>> Samsung - if we wanted to be specific, there will be 4-5 Samsung
>>>>>> vendors... Not mentioning that company organisation is not always
>>>>>> disclosed and can change.
>>>>>
>>>>> I was mostly following qcom-msm8974-lge-nexus5-hammerhead as it's the
>>>>> other LG device tree I am aware of so I've picked lge instead of lg.
>>>>> Also worth noting that Google uses "LGE" in the Android device tree[1]
>>>>> or in the model name in the LG G Watch R kernel sources ("LGE APQ
>>>>> 8026v2 LENOK rev-1.0")
>>>>
>>>> [1] Does not point to kernel tree. Downstream user could be a good
>>>> argument to switch to lge, but then I would expect correcting other "lg"
>>>> devices which are in fact made by LGE.
>>>>
>>>>> I don't have a strong opinion either way so I'm fine with either.
>>>>>
>>>>> If we decide to go with "lg" do we want to change the Nexus 5 devicetree
>>>>> (hammerhead) also, that one has the lge name in at least compatible and
>>>>> filename (I don't know how much of a breaking change that would be
>>>>> considered as).
>>>>
>>>> We would have to add a new one and mark the old compatible as deprecated.
>>>
>>> Have we sorted this lg- vs. lge- ?
>>>
>>> There are both:
>>> arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
>>> vs
>>> arch/arm/boot/dts/qcom-apq8026-lg-lenok.dts
>>
>> Probably renaming/unifying/correcting prefix in existing compatibles is
>> not worth the effort. This would make a mess and affect other DTS users.
>
> If wanted I can send a patch renaming the Nexus 5 to just LG, this would
> adjust both compatible in the file (which shouldn't really affect anything) and
> the filename (which probably will affect various scripts and whatnot used by
> existing users of the dtb).
> Is this something that can be done in mainline or should we rather just let it
> be? I'm not sure what the policies there are.
The "lge" compatible is already in the bindings, so it should not be
changed without valid reason. Imagine there is an user-space code
parsing compatibles to adjust some power-management settings to
different models. It would be broken now.
What could be done is to mark it as deprecated and a add new one:
compatible = "lg,hammerhead", "lge,hammerhead", "qcom,msm8974";
This should be safe for user-space and allow transition to common "lg".
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v20 2/3] Input: mt6779-keypad - Add MediaTek keypad driver
From: Mattijs Korpershoek @ 2022-01-28 10:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dmitry Torokhov, Marco Felsch, Rob Herring, Matthias Brugger,
Fengping Yu, Yingjoe Chen, Fabien Parent, Kevin Hilman,
linux-input, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <YfK4UcuCfF7JfI7H@smile.fi.intel.com>
On Thu, Jan 27, 2022 at 17:20, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Thu, Jan 27, 2022 at 12:15:25PM +0100, Mattijs Korpershoek wrote:
>> From: "fengping.yu" <fengping.yu@mediatek.com>
>>
>> This patch adds matrix keypad support for Mediatek SoCs.
>
> Some comments which may be addressed now or in the follow-up patch(es).
> Up to you.
Hi Andy,
Thank you for your review and your suggestions.
>
> ...
>
>> +static const struct regmap_config mt6779_keypad_regmap_cfg = {
>> + .reg_bits = 32,
>> + .val_bits = 32,
>
>> + .reg_stride = sizeof(u32),
>
> I'm wondering if we need this when we have reg_bits = 32 already.
Per my understanding, .reg_stride is mainly used to check for invalid register
addresses in regmap_{read,write}():
if (!IS_ALIGNED(reg, map->reg_stride))
return -EINVAL;
If .reg_stride is not set, regmap core will default it to 1.
It's not computed from reg_bits.
So I think we still need it.
>
>> + .max_register = 36,
>> +};
>
> ...
>
>> + regmap_write(keypad->regmap, MTK_KPD_DEBOUNCE,
>> + (debounce * 32) & MTK_KPD_DEBOUNCE_MASK);
>
> I'm wondering if << 5 is more specific to show that the value
> is based on 2^5 units.
The datasheet I've seen states: "De-bounce time = KP_DEBOUNCE / 32ms"
But rewriting it as 1 << 5 seems reasonable as well:
regmap_write(keypad->regmap, MTK_KPD_DEBOUNCE,
(debounce * (1 << 5)) & MTK_KPD_DEBOUNCE_MASK);
I don't have any preference on this one.
If I have to send a v21, I will rewrite it using (1 << 5)
>
> ...
>
>> + error = devm_add_action_or_reset(&pdev->dev, mt6779_keypad_clk_disable, keypad->clk);
>
> You have this long line...
>
>> + error = devm_request_threaded_irq(&pdev->dev, irq,
>> + NULL, mt6779_keypad_irq_handler,
>> + IRQF_ONESHOT,
>> + MTK_KPD_NAME, keypad);
>
> ...at the same time you may reduce LOCs here...
Ack. will join lines to reduce LOCs if I have to send v21.
>
>> + if (error) {
>> + dev_err(&pdev->dev, "Failed to request IRQ#%d:%d\n",
>> + irq, error);
>
> ...and here.
Ack. will join lines to reduce LOCs if I have to send v21.
>
>> + return error;
>> + }
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 00/19] add support for WCN6750
From: Kalle Valo @ 2022-01-28 10:07 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: ath11k, linux-wireless, devicetree, robh
In-Reply-To: <1642337235-8618-1-git-send-email-quic_mpubbise@quicinc.com>
Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:
> WCN6750 is non-DBS 2x2 11AX chipset. Unlike QCA6390/WCN6855 which
> are DBS (dual band simultaneous) solutions (2 LMACs), WCN6750 has a
> single LMAC supporting 2G, 5G and 6G bands. It can be operated only
> on one band at any given point.
>
> WCN6750 is a PCIe device. Unlike other supported ATH11K PCIe devices
> which are directly attached to APSS (Application Processor SubSystem),
> WCN6750 is not attached to APSS, it is attached to the WPSS
> (Wireless Processor SubSystem) Q6 processor, the FW which runs on the
> Q6 processor will enumerate the PCIe device. Since APSS is unaware of
> such a device, it has to be registered as a platform device(AHB) to the
> kernel for device probing. Like other AHB devices, remoteproc APIs are
> used to boot up or shutdown of WCN6750.
>
> WCN6750 uses both AHB and PCIe ATH11K APIs for it's operation.
> It uses AHB APIs for device probe and booting of the remote processor.
> Once device is booted up, it uses ATH11K PCIe APIs for initialization
> and register access. Hence, it is referred as hybrid bus device in
> the rest of this series.
>
> Since the chip is enumerated by WPSS Q6, device information like
> BAR and BAR size is not known to the APSS processor. A new QMI message
> called device info QMI request will be sent to the target for fetching
> these details.
>
> STA and AP modes are supported; Basic connectivity and ping are
> verified in both the modes.
>
> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00573-QCAMSLSWPLZ-1
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1
>
> Note:
> * Remoteproc driver changes for WCN6750 which takes care of
> downloading the FW and booting of Q6 processor are under
> upstream review.
> Link: https://patchwork.kernel.org/project/linux-remoteproc/list/?series=582475
This is a very good overview, thanks for that. But I think something
which is not clearly mentioned here is that this only works on Qualcomm
Snapdragon SoC, right? So even though WCN6750 is a PCI device, it cannot
be attached to any platform. It would be good to emphasise that.
> Manikanta Pubbisetty (19):
> ath11k: PCI changes to support WCN6750
> ath11k: Refactor PCI code to support hybrid bus devices
> ath11k: Choose MSI config based on HW revision
> ath11k: Refactor MSI logic
> ath11k: Remove core PCI references from PCI common code
> ath11k: Add HW params for WCN6750
> ath11k: Add bus params for WCN6750
> ath11k: Add register access logic for WCN6750
> ath11k: Fetch device information via QMI for WCN6750
> ath11k: Add QMI changes for WCN6750
> ath11k: HAL changes to support WCN6750
> ath11k: Datapath changes to support WCN6750
> ath11k: Fix RX de-fragmentation issue on WCN6750
> ath11k: Do not put HW in DBS mode for WCN6750
> ath11k: WMI changes to support WCN6750
> ath11k: Update WBM idle ring HP after FW mode on
> ath11k: Add support for WCN6750 device
> ath11k: Add support for targets without trustzone
> dt: bindings: net: add bindings of WCN6750 for ath11k
19 patches is a lot to chew on in one go, my recommendation is to have
max 10-12 patches per set.
In this case having three patchsets would make it a lot easier for
reviewers, but not sure how to split them. Maybe you could submit these
patches separate for preparing WCN6750 support, after a quick look they
seem pretty independent:
ath11k: Fetch device information via QMI for WCN6750
ath11k: HAL changes to support WCN6750
ath11k: Fix RX de-fragmentation issue on WCN6750
ath11k: Do not put HW in DBS mode for WCN6750
ath11k: WMI changes to support WCN6750
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 02/19] ath11k: Refactor PCI code to support hybrid bus devices
From: Kalle Valo @ 2022-01-28 10:16 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: ath11k, linux-wireless, devicetree, robh
In-Reply-To: <1642337235-8618-3-git-send-email-quic_mpubbise@quicinc.com>
Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:
> Unlike other ATH11K PCIe devices which are enumerated by APSS
> processor (Application Processor SubSystem), WCN6750 gets
> enumerated by the WPSS Q6 processor (Wireless Processor SubSystem);
> In simple terms, though WCN6750 is PCIe device, it is not attached
> to the APSS processor, APSS will not know of such a device being
> present in the system and therefore WCN6750 will be registered as
> a platform device to the kernel core like other supported AHB
> devices.
>
> WCN6750 uses both AHB and PCI APIs for it's operation, it uses
> AHB APIs for device probe/boot and PCI APIs for device setup
> and register accesses; Because of this nature, it is referred
> as a hybrid bus device.
>
> Refactor PCI code to support hybrid bus devices like WCN6750.
>
> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00573-QCAMSLSWPLZ-1
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
[...]
> --- a/drivers/net/wireless/ath/ath11k/Makefile
> +++ b/drivers/net/wireless/ath/ath11k/Makefile
> @@ -29,7 +29,7 @@ obj-$(CONFIG_ATH11K_AHB) += ath11k_ahb.o
> ath11k_ahb-y += ahb.o
>
> obj-$(CONFIG_ATH11K_PCI) += ath11k_pci.o
> -ath11k_pci-y += mhi.o pci.o
> +ath11k_pci-y += mhi.o pci.o pci_cmn.o
So the end result looks like this:
obj-$(CONFIG_ATH11K_AHB) += ath11k_ahb.o
ath11k_ahb-y += ahb.o pci_cmn.o
obj-$(CONFIG_ATH11K_PCI) += ath11k_pci.o
ath11k_pci-y += mhi.o pci.o pci_cmn.o
Linking pci_cmn.o to both ath11k_pci.ko and ath11k_ahb.ko looks wrong.
Does that even compile if ath11k is linked to the kernel, eg. with
allyesconfig?
One way to solve is to link pci_cmn.o to ath11k.ko. But for another
approach, for a long time I have been thinking about what's the point to
have separate ath11k_pci.ko and ath11k_ahb.ko modules?,They are very
small anyway compared to ath11k.ko. So my ideais that should we have
just one ath11k.ko module, it contains all AHB and PCI code as well, and
ath11k_pci.ko and ath11k_ahb.ko would not be created anymore. It would
simplify things a bit, especially here.
Thoughts?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 05/19] ath11k: Remove core PCI references from PCI common code
From: Kalle Valo @ 2022-01-28 10:20 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: ath11k, linux-wireless, devicetree, robh
In-Reply-To: <1642337235-8618-6-git-send-email-quic_mpubbise@quicinc.com>
Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:
> Remove core PCI and ath11k PCI references(struct ath11k_pci)
> from PCI common code. Since, PCI common code will be used
> by hybrid bus devices, this code should be independent
> from ATH11K PCI references and Linux core PCI references
> like struct pci_dev.
>
> Since this change introduces function callbacks for bus wakeup
> and bus release operations, wakeup_mhi HW param is no longer
> needed and hence it is removed completely. Alternatively, bus
> wakeup/release ops for QCA9074 are initialized to NULL as
> QCA9704 does not need bus wakeup/release for register accesses.
>
> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00573-QCAMSLSWPLZ-1
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
[...]
> @@ -651,6 +653,13 @@ struct ath11k_bus_params {
> bool fixed_bdf_addr;
> bool fixed_mem_region;
> bool static_window_map;
> + struct {
> + void (*wakeup)(struct ath11k_base *ab);
> + void (*release)(struct ath11k_base *ab);
> + int (*get_msi_irq)(struct ath11k_base *ab, unsigned int vector);
> + void (*window_write32)(struct ath11k_base *ab, u32 offset, u32 value);
> + u32 (*window_read32)(struct ath11k_base *ab, u32 offset);
> + } ops;
> };
Please don't use bus_params for this, I'm starting to suspect that we
actually need to remove struct ath11k_bus_params altogether. It would be
cleaner to have separate 'struct ath11k_pci_ops' or something like that.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [git:media_tree/master] media: dt-bindings: media: camss: Add qcom,sm8250-camss binding
From: Mauro Carvalho Chehab @ 2022-01-23 20:18 UTC (permalink / raw)
To: linuxtv-commits
Cc: devicetree, Bryan O'Donoghue, Jonathan Marek, Rob Herring,
Hans Verkuil
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: dt-bindings: media: camss: Add qcom,sm8250-camss binding
Author: Jonathan Marek <jonathan@marek.ca>
Date: Wed Dec 22 01:37:33 2021 +0100
Add bindings for qcom,sm8250-camss in order to support the camera
subsystem for SM8250.
Cc: devicetree@vger.kernel.org
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
.../bindings/media/qcom,sm8250-camss.yaml | 450 +++++++++++++++++++++
1 file changed, 450 insertions(+)
---
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml
new file mode 100644
index 000000000000..af877d61b607
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml
@@ -0,0 +1,450 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/media/qcom,sm8250-camss.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Qualcomm CAMSS ISP
+
+maintainers:
+ - Robert Foss <robert.foss@linaro.org>
+
+description: |
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,sm8250-camss
+
+ clocks:
+ minItems: 37
+ maxItems: 37
+
+ clock-names:
+ items:
+ - const: cam_ahb_clk
+ - const: cam_hf_axi
+ - const: cam_sf_axi
+ - const: camnoc_axi
+ - const: camnoc_axi_src
+ - const: core_ahb
+ - const: cpas_ahb
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: csiphy5
+ - const: csiphy5_timer
+ - const: slow_ahb_src
+ - const: vfe0_ahb
+ - const: vfe0_axi
+ - const: vfe0
+ - const: vfe0_cphy_rx
+ - const: vfe0_csid
+ - const: vfe0_areg
+ - const: vfe1_ahb
+ - const: vfe1_axi
+ - const: vfe1
+ - const: vfe1_cphy_rx
+ - const: vfe1_csid
+ - const: vfe1_areg
+ - const: vfe_lite_ahb
+ - const: vfe_lite_axi
+ - const: vfe_lite
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+
+ interrupts:
+ minItems: 14
+ maxItems: 14
+
+ interrupt-names:
+ items:
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid3
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ iommus:
+ minItems: 8
+ maxItems: 8
+
+ interconnects:
+ minItems: 4
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: cam_ahb
+ - const: cam_hf_0_mnoc
+ - const: cam_sf_0_mnoc
+ - const: cam_sf_icp_mnoc
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@4:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@5:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ reg:
+ minItems: 10
+ maxItems: 10
+
+ reg-names:
+ items:
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+required:
+ - clock-names
+ - clocks
+ - compatible
+ - interconnects
+ - interconnect-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - power-domains
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,camcc-sm8250.h>
+ #include <dt-bindings/interconnect/qcom,sm8250.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8250.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss: camss@ac6a000 {
+ compatible = "qcom,sm8250-camss";
+
+ reg = <0 0xac6a000 0 0x2000>,
+ <0 0xac6c000 0 0x2000>,
+ <0 0xac6e000 0 0x1000>,
+ <0 0xac70000 0 0x1000>,
+ <0 0xac72000 0 0x1000>,
+ <0 0xac74000 0 0x1000>,
+ <0 0xacb4000 0 0xd000>,
+ <0 0xacc3000 0 0xd000>,
+ <0 0xacd9000 0 0x2200>,
+ <0 0xacdb200 0 0x2200>;
+ reg-names = "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interrupts = <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "csid0",
+ "csid1",
+ "csid2",
+ "csid3",
+ "vfe0",
+ "vfe1",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ power-domains = <&camcc IFE_0_GDSC>,
+ <&camcc IFE_1_GDSC>,
+ <&camcc TITAN_TOP_GDSC>;
+
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_CLK_SRC>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY3_CLK>,
+ <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY5_CLK>,
+ <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
+ <&camcc CAM_CC_SLOW_AHB_CLK_SRC>,
+ <&camcc CAM_CC_IFE_0_AHB_CLK>,
+ <&camcc CAM_CC_IFE_0_AXI_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_0_CSID_CLK>,
+ <&camcc CAM_CC_IFE_0_AREG_CLK>,
+ <&camcc CAM_CC_IFE_1_AHB_CLK>,
+ <&camcc CAM_CC_IFE_1_AXI_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_1_CSID_CLK>,
+ <&camcc CAM_CC_IFE_1_AREG_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AXI_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
+ clock-names = "cam_ahb_clk",
+ "cam_hf_axi",
+ "cam_sf_axi",
+ "camnoc_axi",
+ "camnoc_axi_src",
+ "core_ahb",
+ "cpas_ahb",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "csiphy5",
+ "csiphy5_timer",
+ "slow_ahb_src",
+ "vfe0_ahb",
+ "vfe0_axi",
+ "vfe0",
+ "vfe0_cphy_rx",
+ "vfe0_csid",
+ "vfe0_areg",
+ "vfe1_ahb",
+ "vfe1_axi",
+ "vfe1",
+ "vfe1_cphy_rx",
+ "vfe1_csid",
+ "vfe1_areg",
+ "vfe_lite_ahb",
+ "vfe_lite_axi",
+ "vfe_lite",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ iommus = <&apps_smmu 0x800 0x400>,
+ <&apps_smmu 0x801 0x400>,
+ <&apps_smmu 0x840 0x400>,
+ <&apps_smmu 0x841 0x400>,
+ <&apps_smmu 0xC00 0x400>,
+ <&apps_smmu 0xC01 0x400>,
+ <&apps_smmu 0xC40 0x400>,
+ <&apps_smmu 0xC41 0x400>;
+
+ interconnects = <&gem_noc MASTER_AMPSS_M0 &config_noc SLAVE_CAMERA_CFG>,
+ <&mmss_noc MASTER_CAMNOC_HF &mc_virt SLAVE_EBI_CH0>,
+ <&mmss_noc MASTER_CAMNOC_SF &mc_virt SLAVE_EBI_CH0>,
+ <&mmss_noc MASTER_CAMNOC_ICP &mc_virt SLAVE_EBI_CH0>;
+ interconnect-names = "cam_ahb",
+ "cam_hf_0_mnoc",
+ "cam_sf_0_mnoc",
+ "cam_sf_icp_mnoc";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
^ permalink raw reply related
* Re: [PATCH v2 05/19] ath11k: Remove core PCI references from PCI common code
From: Kalle Valo @ 2022-01-28 10:37 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: ath11k, linux-wireless, devicetree, robh
In-Reply-To: <87a6fggo0h.fsf@kernel.org>
Kalle Valo <kvalo@kernel.org> writes:
> Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:
>
>> Remove core PCI and ath11k PCI references(struct ath11k_pci)
>> from PCI common code. Since, PCI common code will be used
>> by hybrid bus devices, this code should be independent
>> from ATH11K PCI references and Linux core PCI references
>> like struct pci_dev.
>>
>> Since this change introduces function callbacks for bus wakeup
>> and bus release operations, wakeup_mhi HW param is no longer
>> needed and hence it is removed completely. Alternatively, bus
>> wakeup/release ops for QCA9074 are initialized to NULL as
>> QCA9704 does not need bus wakeup/release for register accesses.
>>
>> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00573-QCAMSLSWPLZ-1
>> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
>> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
>> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1
>>
>> Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
>
> [...]
>
>> @@ -651,6 +653,13 @@ struct ath11k_bus_params {
>> bool fixed_bdf_addr;
>> bool fixed_mem_region;
>> bool static_window_map;
>> + struct {
>> + void (*wakeup)(struct ath11k_base *ab);
>> + void (*release)(struct ath11k_base *ab);
>> + int (*get_msi_irq)(struct ath11k_base *ab, unsigned int vector);
>> + void (*window_write32)(struct ath11k_base *ab, u32 offset, u32 value);
>> + u32 (*window_read32)(struct ath11k_base *ab, u32 offset);
>> + } ops;
>> };
>
> Please don't use bus_params for this, I'm starting to suspect that we
> actually need to remove struct ath11k_bus_params altogether. It would be
> cleaner to have separate 'struct ath11k_pci_ops' or something like that.
And after looking at this more it seems .get_msi_irq is the only
function which actually has two different implementations. The other
four are either run or not run, there's no difference in the
implementation. So would it be cleaner to have a some sort check within
the function for these other four, instead using function pointers?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 19/19] dt: bindings: net: add bindings of WCN6750 for ath11k
From: Kalle Valo @ 2022-01-28 10:39 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: ath11k, linux-wireless, devicetree, robh
In-Reply-To: <1642337235-8618-20-git-send-email-quic_mpubbise@quicinc.com>
Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:
> Add WCN6750 wireless driver support, its based on ath11k driver.
>
> Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Device tree bindings should be first in the patchset.
I'm no DT expert, but you have a lot of changes in the bindings and it
would be nice to have some kind of description what you are doing here.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 18/19] ath11k: Add support for targets without trustzone
From: Kalle Valo @ 2022-01-28 10:42 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: ath11k, linux-wireless, devicetree, robh
In-Reply-To: <1642337235-8618-19-git-send-email-quic_mpubbise@quicinc.com>
Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:
> Add the support to attach WCN6750 and map iommu domain
> for targets which do not have the support of TrustZone.
>
> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00573-QCAMSLSWPLZ-1
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Is this not needed in the initial WCN6750 support? If yes, please submit
this patch after WCN6750 support has been commited. That way we can
reduce patchset size.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 10/19] ath11k: Add QMI changes for WCN6750
From: Kalle Valo @ 2022-01-28 10:50 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: ath11k, linux-wireless, devicetree, robh
In-Reply-To: <1642337235-8618-11-git-send-email-quic_mpubbise@quicinc.com>
Manikanta Pubbisetty <quic_mpubbise@quicinc.com> writes:
> In the case of WCN6750, FW doesn't request for DDR memory
> via QMI, instead it uses a fixed 12MB reserved Memory region
> in the DDR which is called as MSA region. As a result, QMI
> message sequence is not same as other ath11k supported devices.
>
> Also, M3 firmware will be bundled into the FW and will be
> downloaded to the target as part of Q6 boot.
>
> This is the QMI flow in the case of WCN6750,
>
> 1) QMI firmware indication REQ/RESP
> 2) QMI host capability REQ/RESP
> 3) QMI target capability REQ/RESP
> 4) QMI device info REQ/RESP
> 5) QMI BDF download
> 6) QMI FW ready
>
> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00573-QCAMSLSWPLZ-1
> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
[...]
> @@ -2490,6 +2497,13 @@ static int ath11k_qmi_wlanfw_m3_info_send(struct ath11k_base *ab)
> struct qmi_txn txn;
> int ret = 0;
>
> + /* In the case of WCN6750, M3 is bundled into the FW
> + * binary, and will be downloaded as part of Q6 boot.
> + */
> + if (!ab->bus_params.m3_fw_support &&
> + ab->bus_params.hybrid_bus_type)
> + return 0;
A check like this makes me think if it's just better to m3_fw_support to
ath11k_hw_params. That way you could disable m3 for WCN6750 via
hw_params.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH 1/2] dt-bindings: display: imx: Add fsl,imx21-lcdc docs
From: Uwe Kleine-König @ 2022-01-28 10:58 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring
Cc: David Airlie, Daniel Vetter, Shawn Guo, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, dri-devel, linux-arm-kernel,
devicetree
In-Reply-To: <20220128105849.368438-1-u.kleine-koenig@pengutronix.de>
From: Marian Cichy <m.cichy@pengutronix.de>
This files documents the device tree for the new imx21-lcdc DRM driver.
Signed-off-by: Marian Cichy <m.cichy@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
.../bindings/display/imx/fsl,imx21-lcdc.yaml | 79 +++++++++++++++++++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx21-lcdc.yaml
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx21-lcdc.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx21-lcdc.yaml
new file mode 100644
index 000000000000..edf71cfac81c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx21-lcdc.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx21-lcdc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX21 LCD Controller
+
+maintainers:
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,imx21-lcdc
+ - items:
+ - enum:
+ - fsl,imx25-lcdc
+ - fsl,imx27-lcdc
+ - const: fsl,imx21-lcdc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: per
+ - const: ahb
+
+ resets:
+ maxItems: 1
+
+ port:
+ type: object
+ description:
+ "Video port for DPI RGB output."
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ lcdc: lcdc@53fbc000 {
+ compatible = "fsl,imx25-lcdc", "fsl,imx21-lcdc";
+ reg = <0x53fbc000 0x4000>;
+ interrupts = <39>;
+ clocks = <&clks 103>, <&clks 66>, <&clks 49>;
+ clock-names = "ipg", "ahb", "per";
+
+ port {
+ parallel_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+
+ };
+
+ panel: panel {
+ compatible = "edt,etm0700g0dh6";
+ power-supply = <&lcd_supply>;
+ backlight = <&bl>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <¶llel_out>;
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] drm/imx/lcdc: drm driver for imx21/25/27
From: Uwe Kleine-König @ 2022-01-28 10:58 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring
Cc: David Airlie, Daniel Vetter, Shawn Guo, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, dri-devel, linux-arm-kernel,
devicetree
Hello,
this patchset was created mostly by Marian Cichy, who in the meantime
left Pengutronix. I still kept his name and email address as author, but
note that the email address doesn't reach Marian any more.
There is already a maintainer entry for imx DRM drivers that matches
good enough.
This was tested on an i.MX25 based customer machine.
Best regards
Uwe
Marian Cichy (2):
dt-bindings: display: imx: Add fsl,imx21-lcdc docs
drm/imx/lcdc: Implement DRM driver for imx21
.../bindings/display/imx/fsl,imx21-lcdc.yaml | 79 +++
drivers/gpu/drm/imx/Kconfig | 9 +
drivers/gpu/drm/imx/Makefile | 2 +
drivers/gpu/drm/imx/imx21-lcdc/imx21-lcdc.c | 631 ++++++++++++++++++
4 files changed, 721 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx21-lcdc.yaml
create mode 100644 drivers/gpu/drm/imx/imx21-lcdc/imx21-lcdc.c
--
2.34.1
^ permalink raw reply
* [PATCH v2 0/2] refine the NFC clock framework
From: Liang Yang @ 2022-01-28 11:32 UTC (permalink / raw)
To: Miquel Raynal, linux-mtd
Cc: Liang Yang, Rob Herring, Richard Weinberger, Vignesh Raghavendra,
Jerome Brunet, Neil Armstrong, Martin Blumenstingl, Kevin Hilman,
Jianxin Pan, Victor Wan, XianWei Zhao, Kelvin Zhang, BiChao Zheng,
YongHui Yu, linux-arm-kernel, linux-amlogic, linux-kernel,
devicetree
Background firstly,
EMMC and NAND has the same clock control register named 'SD_EMMC_CLOCK' which is
defined in EMMC port internally. bit0~5 of 'SD_EMMC_CLOCK' is the divider and
bit6~7 is the mux for fix pll and xtal.
Previously a common MMC sub clock framework is implemented and shared by EMMC and
NAND, but that is coupling the EMMC and NAND, although EMMC and NAND is mutually
exclusive. see the link:
[https://lore.kernel.org/all/1jy23226sa.fsf@starbuckisacylon.baylibre.com/]
Now we plan to abandon common mmc sub clock framework and recovery the series.
Changes since v1 [2]
- use clk_parent_data instead of parent_names
- define a reg resource instead of sd_emmc_c_clkc
[1]
https://lore.kernel.org/r/20220106033130.37623-1-liang.yang@amlogic.com
https://lore.kernel.org/r/20220106032504.23310-1-liang.yang@amlogic.com
Liang Yang (2):
mtd: rawnand: meson: discard the common MMC sub clock framework
dt-bindings: nand: meson: refine Amlogic NAND controller driver
.../bindings/mtd/amlogic,meson-nand.txt | 60 -------
.../bindings/mtd/amlogic,meson-nand.yaml | 70 ++++++++
drivers/mtd/nand/raw/meson_nand.c | 161 ++++++++++--------
3 files changed, 159 insertions(+), 132 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
create mode 100644 Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
--
2.34.1
^ permalink raw reply
* [PATCH v2 1/2] mtd: rawnand: meson: discard the common MMC sub clock framework
From: Liang Yang @ 2022-01-28 11:32 UTC (permalink / raw)
To: Miquel Raynal, linux-mtd
Cc: Liang Yang, Rob Herring, Richard Weinberger, Vignesh Raghavendra,
Jerome Brunet, Neil Armstrong, Martin Blumenstingl, Kevin Hilman,
Jianxin Pan, Victor Wan, XianWei Zhao, Kelvin Zhang, BiChao Zheng,
YongHui Yu, linux-arm-kernel, linux-amlogic, linux-kernel,
devicetree
In-Reply-To: <20220128113237.39996-1-liang.yang@amlogic.com>
EMMC and NAND has the same clock control register named 'SD_EMMC_CLOCK' which is
defined in EMMC port internally. bit0~5 of 'SD_EMMC_CLOCK' is the divider and
bit6~7 is the mux for fix pll and xtal.
Previously a common MMC sub clock framework is implemented and shared by EMMC and
NAND, but that is coupling the EMMC and NAND, although EMMC and NAND is mutually
exclusive.
Change-Id: Ibeb4c7ff886f5886aac4d6c664d7bbd1b1bcb997
Signed-off-by: Liang Yang <liang.yang@amlogic.com>
---
drivers/mtd/nand/raw/meson_nand.c | 161 +++++++++++++++++-------------
1 file changed, 89 insertions(+), 72 deletions(-)
diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
index ac3be92872d0..f6a3d5c2ea1c 100644
--- a/drivers/mtd/nand/raw/meson_nand.c
+++ b/drivers/mtd/nand/raw/meson_nand.c
@@ -2,7 +2,7 @@
/*
* Amlogic Meson Nand Flash Controller Driver
*
- * Copyright (c) 2018 Amlogic, inc.
+ * Copyright (c) 2018-2021 Amlogic, inc.
* Author: Liang Yang <liang.yang@amlogic.com>
*/
@@ -10,6 +10,7 @@
#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
#include <linux/clk.h>
+#include <linux/clk-provider.h>
#include <linux/mtd/rawnand.h>
#include <linux/mtd/mtd.h>
#include <linux/mfd/syscon.h>
@@ -19,6 +20,7 @@
#include <linux/iopoll.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_address.h>
#include <linux/sched/task_stack.h>
#define NFC_REG_CMD 0x00
@@ -104,6 +106,9 @@
#define PER_INFO_BYTE 8
+#define CLK_DIV_SHIFT 0
+#define CLK_DIV_WIDTH 6
+
struct meson_nfc_nand_chip {
struct list_head node;
struct nand_chip nand;
@@ -151,15 +156,17 @@ struct meson_nfc {
struct nand_controller controller;
struct clk *core_clk;
struct clk *device_clk;
- struct clk *phase_tx;
- struct clk *phase_rx;
+ struct clk *nand_clk;
+ struct clk_divider nand_divider;
unsigned long clk_rate;
u32 bus_timing;
struct device *dev;
- void __iomem *reg_base;
- struct regmap *reg_clk;
+ struct {
+ void __iomem *reg_base;
+ void __iomem *sd_emmc_clock;
+ } res;
struct completion completion;
struct list_head chips;
const struct meson_nfc_data *data;
@@ -244,8 +251,8 @@ static void meson_nfc_select_chip(struct nand_chip *nand, int chip)
}
if (nfc->bus_timing != meson_chip->bus_timing) {
value = (NFC_CLK_CYCLE - 1) | (meson_chip->bus_timing << 5);
- writel(value, nfc->reg_base + NFC_REG_CFG);
- writel((1 << 31), nfc->reg_base + NFC_REG_CMD);
+ writel(value, nfc->res.reg_base + NFC_REG_CFG);
+ writel((1 << 31), nfc->res.reg_base + NFC_REG_CMD);
nfc->bus_timing = meson_chip->bus_timing;
}
}
@@ -253,13 +260,13 @@ static void meson_nfc_select_chip(struct nand_chip *nand, int chip)
static void meson_nfc_cmd_idle(struct meson_nfc *nfc, u32 time)
{
writel(nfc->param.chip_select | NFC_CMD_IDLE | (time & 0x3ff),
- nfc->reg_base + NFC_REG_CMD);
+ nfc->res.reg_base + NFC_REG_CMD);
}
static void meson_nfc_cmd_seed(struct meson_nfc *nfc, u32 seed)
{
writel(NFC_CMD_SEED | (0xc2 + (seed & 0x7fff)),
- nfc->reg_base + NFC_REG_CMD);
+ nfc->res.reg_base + NFC_REG_CMD);
}
static void meson_nfc_cmd_access(struct nand_chip *nand, int raw, bool dir,
@@ -276,7 +283,7 @@ static void meson_nfc_cmd_access(struct nand_chip *nand, int raw, bool dir,
if (raw) {
len = mtd->writesize + mtd->oobsize;
cmd = (len & GENMASK(5, 0)) | scrambler | DMA_DIR(dir);
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
return;
}
@@ -285,7 +292,7 @@ static void meson_nfc_cmd_access(struct nand_chip *nand, int raw, bool dir,
cmd = CMDRWGEN(DMA_DIR(dir), scrambler, bch,
NFC_CMD_SHORTMODE_DISABLE, pagesize, pages);
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
}
static void meson_nfc_drain_cmd(struct meson_nfc *nfc)
@@ -312,7 +319,7 @@ static int meson_nfc_wait_cmd_finish(struct meson_nfc *nfc,
int ret;
/* wait cmd fifo is empty */
- ret = readl_relaxed_poll_timeout(nfc->reg_base + NFC_REG_CMD, cmd_size,
+ ret = readl_relaxed_poll_timeout(nfc->res.reg_base + NFC_REG_CMD, cmd_size,
!NFC_CMD_GET_SIZE(cmd_size),
10, timeout_ms * 1000);
if (ret)
@@ -396,16 +403,16 @@ static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms)
meson_nfc_drain_cmd(nfc);
meson_nfc_wait_cmd_finish(nfc, CMD_FIFO_EMPTY_TIMEOUT);
- cfg = readl(nfc->reg_base + NFC_REG_CFG);
+ cfg = readl(nfc->res.reg_base + NFC_REG_CFG);
cfg |= NFC_RB_IRQ_EN;
- writel(cfg, nfc->reg_base + NFC_REG_CFG);
+ writel(cfg, nfc->res.reg_base + NFC_REG_CFG);
reinit_completion(&nfc->completion);
/* use the max erase time as the maximum clock for waiting R/B */
cmd = NFC_CMD_RB | NFC_CMD_RB_INT
| nfc->param.chip_select | nfc->timing.tbers_max;
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
ret = wait_for_completion_timeout(&nfc->completion,
msecs_to_jiffies(timeout_ms));
@@ -485,10 +492,10 @@ static int meson_nfc_dma_buffer_setup(struct nand_chip *nand, void *databuf,
return ret;
}
cmd = GENCMDDADDRL(NFC_CMD_ADL, nfc->daddr);
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
cmd = GENCMDDADDRH(NFC_CMD_ADH, nfc->daddr);
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
if (infobuf) {
nfc->iaddr = dma_map_single(nfc->dev, infobuf, infolen, dir);
@@ -500,10 +507,10 @@ static int meson_nfc_dma_buffer_setup(struct nand_chip *nand, void *databuf,
return ret;
}
cmd = GENCMDIADDRL(NFC_CMD_AIL, nfc->iaddr);
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
cmd = GENCMDIADDRH(NFC_CMD_AIH, nfc->iaddr);
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
}
return ret;
@@ -537,7 +544,7 @@ static int meson_nfc_read_buf(struct nand_chip *nand, u8 *buf, int len)
goto out;
cmd = NFC_CMD_N2M | (len & GENMASK(5, 0));
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
meson_nfc_drain_cmd(nfc);
meson_nfc_wait_cmd_finish(nfc, 1000);
@@ -561,7 +568,7 @@ static int meson_nfc_write_buf(struct nand_chip *nand, u8 *buf, int len)
return ret;
cmd = NFC_CMD_M2N | (len & GENMASK(5, 0));
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
meson_nfc_drain_cmd(nfc);
meson_nfc_wait_cmd_finish(nfc, 1000);
@@ -610,11 +617,11 @@ static int meson_nfc_rw_cmd_prepare_and_execute(struct nand_chip *nand,
for (i = 0; i < cmd_num; i++)
writel_relaxed(nfc->cmdfifo.cmd[i],
- nfc->reg_base + NFC_REG_CMD);
+ nfc->res.reg_base + NFC_REG_CMD);
if (in) {
nfc->cmdfifo.rw.cmd1 = cs | NFC_CMD_CLE | NAND_CMD_READSTART;
- writel(nfc->cmdfifo.rw.cmd1, nfc->reg_base + NFC_REG_CMD);
+ writel(nfc->cmdfifo.rw.cmd1, nfc->res.reg_base + NFC_REG_CMD);
meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tR_max));
} else {
meson_nfc_cmd_idle(nfc, nfc->timing.tadl);
@@ -660,7 +667,7 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
}
cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_PAGEPROG;
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tPROG_max));
meson_nfc_dma_buffer_release(nand, data_len, info_len, DMA_TO_DEVICE);
@@ -912,7 +919,7 @@ static int meson_nfc_exec_op(struct nand_chip *nand,
case NAND_OP_CMD_INSTR:
cmd = nfc->param.chip_select | NFC_CMD_CLE;
cmd |= instr->ctx.cmd.opcode & 0xff;
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
meson_nfc_cmd_idle(nfc, delay_idle);
break;
@@ -920,7 +927,7 @@ static int meson_nfc_exec_op(struct nand_chip *nand,
for (i = 0; i < instr->ctx.addr.naddrs; i++) {
cmd = nfc->param.chip_select | NFC_CMD_ALE;
cmd |= instr->ctx.addr.addrs[i] & 0xff;
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ writel(cmd, nfc->res.reg_base + NFC_REG_CMD);
}
meson_nfc_cmd_idle(nfc, delay_idle);
break;
@@ -988,6 +995,8 @@ static const struct mtd_ooblayout_ops meson_ooblayout_ops = {
static int meson_nfc_clk_init(struct meson_nfc *nfc)
{
int ret;
+ struct clk_init_data init = {0};
+ struct clk_parent_data nfc_divider_parent_data[1];
/* request core clock */
nfc->core_clk = devm_clk_get(nfc->dev, "core");
@@ -1002,21 +1011,26 @@ static int meson_nfc_clk_init(struct meson_nfc *nfc)
return PTR_ERR(nfc->device_clk);
}
- nfc->phase_tx = devm_clk_get(nfc->dev, "tx");
- if (IS_ERR(nfc->phase_tx)) {
- dev_err(nfc->dev, "failed to get TX clk\n");
- return PTR_ERR(nfc->phase_tx);
- }
-
- nfc->phase_rx = devm_clk_get(nfc->dev, "rx");
- if (IS_ERR(nfc->phase_rx)) {
- dev_err(nfc->dev, "failed to get RX clk\n");
- return PTR_ERR(nfc->phase_rx);
- }
+ init.name = devm_kstrdup(nfc->dev, "nfc#div", GFP_KERNEL);
+ init.ops = &clk_divider_ops;
+ nfc_divider_parent_data[0].fw_name = __clk_get_name(nfc->device_clk);
+ init.parent_data = nfc_divider_parent_data;
+ init.num_parents = 1;
+ nfc->nand_divider.reg = nfc->res.sd_emmc_clock;
+ nfc->nand_divider.shift = CLK_DIV_SHIFT;
+ nfc->nand_divider.width = CLK_DIV_WIDTH;
+ nfc->nand_divider.hw.init = &init;
+ nfc->nand_divider.flags = CLK_DIVIDER_ONE_BASED |
+ CLK_DIVIDER_ROUND_CLOSEST |
+ CLK_DIVIDER_ALLOW_ZERO;
+
+ nfc->nand_clk = devm_clk_register(nfc->dev, &nfc->nand_divider.hw);
+ if (IS_ERR(nfc->nand_clk))
+ return PTR_ERR(nfc->nand_clk);
/* init SD_EMMC_CLOCK to sane defaults w/min clock rate */
- regmap_update_bits(nfc->reg_clk,
- 0, CLK_SELECT_NAND, CLK_SELECT_NAND);
+ writel(CLK_SELECT_NAND | readl(nfc->res.sd_emmc_clock),
+ nfc->res.sd_emmc_clock);
ret = clk_prepare_enable(nfc->core_clk);
if (ret) {
@@ -1030,29 +1044,21 @@ static int meson_nfc_clk_init(struct meson_nfc *nfc)
goto err_device_clk;
}
- ret = clk_prepare_enable(nfc->phase_tx);
- if (ret) {
- dev_err(nfc->dev, "failed to enable TX clock\n");
- goto err_phase_tx;
- }
-
- ret = clk_prepare_enable(nfc->phase_rx);
+ ret = clk_prepare_enable(nfc->nand_clk);
if (ret) {
- dev_err(nfc->dev, "failed to enable RX clock\n");
- goto err_phase_rx;
+ dev_err(nfc->dev, "pre enable NFC divider fail\n");
+ goto err_nand_clk;
}
ret = clk_set_rate(nfc->device_clk, 24000000);
if (ret)
- goto err_disable_rx;
+ goto err_disable_clk;
return 0;
-err_disable_rx:
- clk_disable_unprepare(nfc->phase_rx);
-err_phase_rx:
- clk_disable_unprepare(nfc->phase_tx);
-err_phase_tx:
+err_disable_clk:
+ clk_disable_unprepare(nfc->nand_clk);
+err_nand_clk:
clk_disable_unprepare(nfc->device_clk);
err_device_clk:
clk_disable_unprepare(nfc->core_clk);
@@ -1061,8 +1067,7 @@ static int meson_nfc_clk_init(struct meson_nfc *nfc)
static void meson_nfc_disable_clk(struct meson_nfc *nfc)
{
- clk_disable_unprepare(nfc->phase_rx);
- clk_disable_unprepare(nfc->phase_tx);
+ clk_disable_unprepare(nfc->nand_clk);
clk_disable_unprepare(nfc->device_clk);
clk_disable_unprepare(nfc->core_clk);
}
@@ -1339,12 +1344,12 @@ static irqreturn_t meson_nfc_irq(int irq, void *id)
struct meson_nfc *nfc = id;
u32 cfg;
- cfg = readl(nfc->reg_base + NFC_REG_CFG);
+ cfg = readl(nfc->res.reg_base + NFC_REG_CFG);
if (!(cfg & NFC_RB_IRQ_EN))
return IRQ_NONE;
cfg &= ~(NFC_RB_IRQ_EN);
- writel(cfg, nfc->reg_base + NFC_REG_CFG);
+ writel(cfg, nfc->res.reg_base + NFC_REG_CFG);
complete(&nfc->completion);
return IRQ_HANDLED;
@@ -1370,11 +1375,31 @@ static const struct of_device_id meson_nfc_id_table[] = {
};
MODULE_DEVICE_TABLE(of, meson_nfc_id_table);
+static int meson_nfc_reg_resource(struct device *dev, struct meson_nfc *nfc)
+{
+ struct resource res;
+ void __iomem *base[2];
+ struct device_node *node = dev->of_node;
+ int i;
+
+ for (i = 0; i < 2; i++) {
+ if (of_address_to_resource(node, i, &res))
+ return -ENOENT;
+
+ base[i] = devm_ioremap_resource(dev, &res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+ }
+ nfc->res.reg_base = base[0];
+ nfc->res.sd_emmc_clock = base[1];
+
+ return 0;
+}
+
static int meson_nfc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct meson_nfc *nfc;
- struct resource *res;
int ret, irq;
nfc = devm_kzalloc(dev, sizeof(*nfc), GFP_KERNEL);
@@ -1388,20 +1413,12 @@ static int meson_nfc_probe(struct platform_device *pdev)
nand_controller_init(&nfc->controller);
INIT_LIST_HEAD(&nfc->chips);
init_completion(&nfc->completion);
-
nfc->dev = dev;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- nfc->reg_base = devm_ioremap_resource(dev, res);
- if (IS_ERR(nfc->reg_base))
- return PTR_ERR(nfc->reg_base);
-
- nfc->reg_clk =
- syscon_regmap_lookup_by_phandle(dev->of_node,
- "amlogic,mmc-syscon");
- if (IS_ERR(nfc->reg_clk)) {
- dev_err(dev, "Failed to lookup clock base\n");
- return PTR_ERR(nfc->reg_clk);
+ ret = meson_nfc_reg_resource(dev, nfc);
+ if (ret) {
+ dev_err(dev, "Failed to get reg resource\n");
+ return ret;
}
irq = platform_get_irq(pdev, 0);
@@ -1414,7 +1431,7 @@ static int meson_nfc_probe(struct platform_device *pdev)
return ret;
}
- writel(0, nfc->reg_base + NFC_REG_CFG);
+ writel(0, nfc->res.reg_base + NFC_REG_CFG);
ret = devm_request_irq(dev, irq, meson_nfc_irq, 0, dev_name(dev), nfc);
if (ret) {
dev_err(dev, "failed to request NFC IRQ\n");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] mtd: rawnand: meson: discard the common MMC sub clock framework
From: Miquel Raynal @ 2022-01-28 11:40 UTC (permalink / raw)
To: Liang Yang
Cc: linux-mtd, Rob Herring, Richard Weinberger, Vignesh Raghavendra,
Jerome Brunet, Neil Armstrong, Martin Blumenstingl, Kevin Hilman,
Jianxin Pan, Victor Wan, XianWei Zhao, Kelvin Zhang, BiChao Zheng,
YongHui Yu, linux-arm-kernel, linux-amlogic, linux-kernel,
devicetree
In-Reply-To: <20220128113237.39996-2-liang.yang@amlogic.com>
Hi Liang,
liang.yang@amlogic.com wrote on Fri, 28 Jan 2022 19:32:36 +0800:
> EMMC and NAND has the same clock control register named 'SD_EMMC_CLOCK' which is
have
> defined in EMMC port internally. bit0~5 of 'SD_EMMC_CLOCK' is the divider and
> bit6~7 is the mux for fix pll and xtal.
> Previously a common MMC sub clock framework is implemented and shared by EMMC and
I believe you meant that this hasa already been contributed? I would
then rephrase with:
A common MMC and NAND sub-clock has been implemented and can be used by
the eMMC and NAND controller (which are mutually exclusive anyway).
Let's use this new clock.
> NAND, but that is coupling the EMMC and NAND, although EMMC and NAND is mutually
> exclusive.
>
> Change-Id: Ibeb4c7ff886f5886aac4d6c664d7bbd1b1bcb997
No change Ids.
> Signed-off-by: Liang Yang <liang.yang@amlogic.com>
> ---
> drivers/mtd/nand/raw/meson_nand.c | 161 +++++++++++++++++-------------
> 1 file changed, 89 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
> index ac3be92872d0..f6a3d5c2ea1c 100644
> --- a/drivers/mtd/nand/raw/meson_nand.c
> +++ b/drivers/mtd/nand/raw/meson_nand.c
> @@ -2,7 +2,7 @@
> /*
> * Amlogic Meson Nand Flash Controller Driver
> *
> - * Copyright (c) 2018 Amlogic, inc.
> + * Copyright (c) 2018-2021 Amlogic, inc.
Please don't.
> * Author: Liang Yang <liang.yang@amlogic.com>
> */
>
> @@ -10,6 +10,7 @@
> #include <linux/dma-mapping.h>
> #include <linux/interrupt.h>
> #include <linux/clk.h>
> +#include <linux/clk-provider.h>
> #include <linux/mtd/rawnand.h>
> #include <linux/mtd/mtd.h>
> #include <linux/mfd/syscon.h>
> @@ -19,6 +20,7 @@
> #include <linux/iopoll.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> +#include <linux/of_address.h>
> #include <linux/sched/task_stack.h>
>
> #define NFC_REG_CMD 0x00
> @@ -104,6 +106,9 @@
>
> #define PER_INFO_BYTE 8
>
> +#define CLK_DIV_SHIFT 0
> +#define CLK_DIV_WIDTH 6
> +
> struct meson_nfc_nand_chip {
> struct list_head node;
> struct nand_chip nand;
> @@ -151,15 +156,17 @@ struct meson_nfc {
> struct nand_controller controller;
> struct clk *core_clk;
> struct clk *device_clk;
> - struct clk *phase_tx;
> - struct clk *phase_rx;
> + struct clk *nand_clk;
> + struct clk_divider nand_divider;
>
> unsigned long clk_rate;
> u32 bus_timing;
>
> struct device *dev;
> - void __iomem *reg_base;
> - struct regmap *reg_clk;
> + struct {
> + void __iomem *reg_base;
> + void __iomem *sd_emmc_clock;
> + } res;
Please split your commit: first the mechanical changes, then the use of
the new area or something like that.
Otherwise there are too many lines changed, I can't spot where it is
interesting.
Thanks,
Miquèl
^ 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