* Re: [PATCH] arm64: dts: allwinner: Add cache information to the SoC dtsi for H6
From: Dragan Simic @ 2024-04-30 11:10 UTC (permalink / raw)
To: Andre Przywara
Cc: linux-sunxi, wens, jernej.skrabec, samuel, linux-arm-kernel,
devicetree, robh, krzk+dt, conor+dt, linux-kernel
In-Reply-To: <20240430114627.0cfcd14a@donnerap.manchester.arm.com>
Hello Andre,
On 2024-04-30 12:46, Andre Przywara wrote:
> On Tue, 30 Apr 2024 02:01:42 +0200
> Dragan Simic <dsimic@manjaro.org> wrote:
>> On 2024-04-30 01:10, Andre Przywara wrote:
>> > On Sun, 28 Apr 2024 13:40:36 +0200
>> > Dragan Simic <dsimic@manjaro.org> wrote:
>> >
>> >> Add missing cache information to the Allwinner H6 SoC dtsi, to allow
>> >> the userspace, which includes lscpu(1) that uses the virtual files
>> >> provided
>> >> by the kernel under the /sys/devices/system/cpu directory, to display
>> >> the
>> >> proper H6 cache information.
>> >>
>> >> Adding the cache information to the H6 SoC dtsi also makes the
>> >> following
>> >> warning message in the kernel log go away:
>> >>
>> >> cacheinfo: Unable to detect cache hierarchy for CPU 0
>> >>
>> >> The cache parameters for the H6 dtsi were obtained and partially
>> >> derived
>> >> by hand from the cache size and layout specifications found in the
>> >> following
>> >> datasheets and technical reference manuals:
>> >>
>> >> - Allwinner H6 V200 datasheet, version 1.1
>> >> - ARM Cortex-A53 revision r0p3 TRM, version E
>> >>
>> >> For future reference, here's a brief summary of the documentation:
>> >>
>> >> - All caches employ the 64-byte cache line length
>> >> - Each Cortex-A53 core has 32 KB of L1 2-way, set-associative
>> >> instruction
>> >> cache and 32 KB of L1 4-way, set-associative data cache
>> >> - The entire SoC has 512 KB of unified L2 16-way, set-associative
>> >> cache
>> >>
>> >> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>> >
>> > I can confirm that the data below matches the manuals, but also the
>> > decoding of the architectural cache type registers (CCSIDR_EL1):
>> > L1D: 32 KB: 128 sets, 4 way associative, 64 bytes/line
>> > L1I: 32 KB: 256 sets, 2 way associative, 64 bytes/line
>> > L2: 512 KB: 512 sets, 16 way associative, 64 bytes/line
>>
>> Thank you very much for reviewing my patch in such a detailed way!
>> It's good to know that the values in the Allwinner datasheets match
>> with the observed reality, so to speak. :)
>
> YW, and yes, I like to double check things when it comes to Allwinner
> documentation ;-) And it was comparably easy for this problem.
Double checking is always good, IMHO. :)
> Out of curiosity: what triggered that patch? Trying to get rid of false
> warning/error messages?
Yes, one of the motivators was to get rid of the false kernel warning,
and the other was to have the cache information nicely available through
lscpu(1). I already did the same for a few Rockchip SoCs, [1][2][3] so
a couple of Allwinner SoCs were the next on my mental TODO list. :)
> And do you plan to address the H616 as well? It's a bit more tricky
> there,
> since there are two die revisions out: one with 256(?)KB of L2, one
> with
> 1MB(!). We know how to tell them apart, so I could provide some TF-A
> code
> to patch that up in the DT. The kernel DT copy could go with 256KB
> then.
I have no boards based on the Allwinner H616, so it wasn't on my radar.
Though, I'd be happy to prepare and submit a similar kernel patch for
the H616, if you'd then take it further and submit a TF-A patch that
fixes the DT according to the detected die revision? Did I understand
the plan right?
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=67a6a98575974416834c2294853b3814376a7ce7
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=8612169a05c5e979af033868b7a9b177e0f9fcdf
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b72633ba5cfa932405832de25d0f0a11716903b4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] rust: add flags for shadow call stack sanitizer
From: Alice Ryhl @ 2024-04-30 11:09 UTC (permalink / raw)
To: will
Cc: Jamie.Cunliffe, a.hindborg, alex.gaynor, aliceryhl, ardb,
benno.lossin, bjorn3_gh, boqun.feng, broonie, catalin.marinas,
gary, keescook, kernel, linux-arm-kernel, linux-kbuild,
linux-kernel, mark.rutland, masahiroy, maz, miguel.ojeda.sandonis,
nathan, ndesaulniers, nicolas, ojeda, rust-for-linux,
samitolvanen, wedsonaf
In-Reply-To: <20240409103120.GA22557@willie-the-truck>
Will Deacon <will@kernel.org> wrote:
> On Tue, Mar 05, 2024 at 01:14:19PM +0100, Miguel Ojeda wrote:
>> Otherwise partially reverting to the `target.json` approach sounds good too.
>>
>> I added the `-Zuse-sync-unwind=n` to the list at
>> https://github.com/Rust-for-Linux/linux/issues/2. Given the default is
>> what we want, I have put it in the "Good to have" section.
>
> I think we have time to do this properly, like we did for the clang
> enablement a few years ago. In hindsight, avoiding hacks for the early
> toolchains back then was a really good idea because it meant we could
> rely on a solid baseline set of compiler features from the start.
>
> So, please can we fix this in rustc and just have SCS dependent on that?
Hi Will,
Just to keep you in the loop, I've posted a PR to make rustc recognize
the reserve-x18 target feature, so that the -Ctarget-feature=+reserve-x18
flag stops emitting a warning.
This should be sufficient for adding support for CONFIG_DYNAMIC_SCS.
You can find it here:
https://github.com/rust-lang/rust/pull/124323
As for non-dynamic SCS, I plan to tackle that after the PR is merged.
See the "Future possibilities" section in the linked PR for more info on
that.
Alice
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 05/16] ACPI: processor: Add acpi_get_processor_handle() helper
From: Jonathan Cameron @ 2024-04-30 11:07 UTC (permalink / raw)
To: Gavin Shan
Cc: Thomas Gleixner, Peter Zijlstra, linux-pm, loongarch, linux-acpi,
linux-arch, linux-kernel, linux-arm-kernel, kvmarm, x86,
Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
Salil Mehta, Jean-Philippe Brucker, Catalin Marinas, Will Deacon,
Marc Zyngier, Hanjun Guo, Ingo Molnar, Borislav Petkov,
Dave Hansen, linuxarm, justin.he, jianyong.wu, Lorenzo Pieralisi,
Sudeep Holla
In-Reply-To: <63f7c71a-fa01-4604-8fc6-9f52b5b31d6b@redhat.com>
On Tue, 30 Apr 2024 14:26:06 +1000
Gavin Shan <gshan@redhat.com> wrote:
> On 4/26/24 23:51, Jonathan Cameron wrote:
> > If CONFIG_ACPI_PROCESSOR provide a helper to retrieve the
> > acpi_handle for a given CPU allowing access to methods
> > in DSDT.
> >
> > Tested-by: Miguel Luis <miguel.luis@oracle.com>
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > ---
> > v8: Code simplification suggested by Rafael.
> > Fixup ;; spotted by Gavin
> > ---
> > drivers/acpi/acpi_processor.c | 11 +++++++++++
> > include/linux/acpi.h | 7 +++++++
> > 2 files changed, 18 insertions(+)
> >
>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
>
Thanks,
> > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > index 3b180e21f325..ecc2721fecae 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -35,6 +35,17 @@ EXPORT_PER_CPU_SYMBOL(processors);
> > struct acpi_processor_errata errata __read_mostly;
> > EXPORT_SYMBOL_GPL(errata);
> >
> > +acpi_handle acpi_get_processor_handle(int cpu)
> > +{
> > + struct acpi_processor *pr;
> > +
> > + pr = per_cpu(processors, cpu);
> > + if (pr)
> > + return pr->handle;
> > +
> > + return NULL;
> > +}
> > +
>
> Maybe it's worthy to have more check here, something like below.
> However, it's also fine without the extra check.
We could harden this, but for now the call sites are only
int arch_(un)register_cpu() so if we get there with either
of these failing something went very wrong.
Maybe if it gets used more widely this defense would be wise.
Jonathan
>
> if (cpu >= nr_cpu_ids || !cpu_possible(cpu))
> return NULL;
>
> > static int acpi_processor_errata_piix4(struct pci_dev *dev)
> > {
> > u8 value1 = 0;
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> > index 34829f2c517a..9844a3f9c4e5 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -309,6 +309,8 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 acpi_id,
> > int acpi_unmap_cpu(int cpu);
> > #endif /* CONFIG_ACPI_HOTPLUG_CPU */
> >
> > +acpi_handle acpi_get_processor_handle(int cpu);
> > +
> > #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> > int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr);
> > #endif
> > @@ -1077,6 +1079,11 @@ static inline bool acpi_sleep_state_supported(u8 sleep_state)
> > return false;
> > }
> >
> > +static inline acpi_handle acpi_get_processor_handle(int cpu)
> > +{
> > + return NULL;
> > +}
> > +
> > #endif /* !CONFIG_ACPI */
> >
> > extern void arch_post_acpi_subsys_init(void);
>
> Thanks,
> Gavin
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/4] arm64: dts: exynos: gs101: Add ufs and ufs-phy dt nodes
From: Peter Griffin @ 2024-04-30 11:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh, krzk+dt, conor+dt, alim.akhtar, devicetree,
linux-arm-kernel, linux-samsung-soc, linux-kernel, tudor.ambarus,
andre.draszik, saravanak, willmcvicker, kernel-team
In-Reply-To: <8b3c9d34-15d5-4aac-b725-4cc25e469a58@kernel.org>
Hi Krzysztof,
On Mon, 29 Apr 2024 at 18:30, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 29/04/2024 13:15, Peter Griffin wrote:
> > + ufs_0: ufs@14700000 {
> > + compatible = "google,gs101-ufs";
> > + reg = <0x14700000 0x200>,
> > + <0x14701100 0x200>,
> > + <0x14780000 0xa000>,
> > + <0x14600000 0x100>;
> > + reg-names = "hci", "vs_hci", "unipro", "ufsp";
> > + interrupts = <GIC_SPI 532 IRQ_TYPE_LEVEL_HIGH 0>;
> > + clocks = <&cmu_hsi2 CLK_GOUT_HSI2_UFS_EMBD_I_ACLK>,
> > + <&cmu_hsi2 CLK_GOUT_HSI2_UFS_EMBD_I_CLK_UNIPRO>,
> > + <&cmu_hsi2 CLK_GOUT_HSI2_UFS_EMBD_I_FMP_CLK>,
> > + <&cmu_hsi2 CLK_GOUT_HSI2_QE_UFS_EMBD_HSI2_ACLK>,
> > + <&cmu_hsi2 CLK_GOUT_HSI2_QE_UFS_EMBD_HSI2_PCLK>,
> > + <&cmu_hsi2 CLK_GOUT_HSI2_SYSREG_HSI2_PCLK>;
> > + clock-names = "core_clk", "sclk_unipro_main", "fmp",
> > + "aclk", "pclk", "sysreg";
> > + freq-table-hz = <0 0>, <0 0>, <0 0>, <0 0>, <0 0>, <0 0>;
> > + pinctrl-0 = <&ufs_rst_n &ufs_refclk_out>;
> > + pinctrl-names = "default";
> > + phys = <&ufs_0_phy>;
> > + phy-names = "ufs-phy";
> > + samsung,sysreg = <&sysreg_hsi2 0x710>;
> > + status = "disabled";
> > + };
> > +
> > + ufs_0_phy: phy@0x14704000 {
>
> Drop 0x from unit address.
Thanks for the review, will fix.
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Properly clean up iommu-dma remnants
From: Robin Murphy @ 2024-04-30 11:00 UTC (permalink / raw)
To: Dmitry Baryshkov; +Cc: joro, will, catalin.marinas, linux-arm-kernel, iommu
In-Reply-To: <CAA8EJprv9At9t-C+EzUt60F1_ke30F78zpGr=vLFBB9Mk1zv+w@mail.gmail.com>
On 2024-04-30 11:32 am, Dmitry Baryshkov wrote:
> On Tue, 30 Apr 2024 at 13:23, Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> Thanks to the somewhat asymmetrical nature, while removing
>> iommu_setup_dma_ops() from the arch_setup_dma_ops() flow, I managed to
>> forget that arm64's teardown path was also specific to iommu-dma. Clean
>> that up to match, otherwise probe deferral will lead to the arch code
>> erroneously removing DMA ops set elsewhere.
>>
>> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> Link: https://lore.kernel.org/linux-iommu/Zi_LV28TR-P-PzXi@eriador.lumag.spb.ru/
>> Fixes: b67483b3c44e ("iommu/dma: Centralise iommu_setup_dma_ops()")
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> arch/arm64/Kconfig | 1 -
>> arch/arm64/mm/dma-mapping.c | 8 --------
>> 2 files changed, 9 deletions(-)
>
>
> Thanks!
>
> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Great! Always nice when the issue is one of simply not deleting *enough*
code :)
Cheers,
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 16/17] mfd: Add support for LAN966x PCI device
From: Herve Codina @ 2024-04-30 8:37 UTC (permalink / raw)
To: Herve Codina, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lee Jones, Arnd Bergmann, Horatiu Vultur,
UNGLinuxDriver, Andrew Lunn, Heiner Kallweit, Russell King,
Saravana Kannan, Bjorn Helgaas, Philipp Zabel, Lars Povlsen,
Steen Hegelund, Daniel Machon, Alexandre Belloni
Cc: linux-kernel, devicetree, netdev, linux-pci, linux-arm-kernel,
Allan Nielsen, Steen Hegelund, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20240430083730.134918-1-herve.codina@bootlin.com>
Add a PCI driver that handles the LAN966x PCI device using a device-tree
overlay. This overlay is applied to the PCI device DT node and allows to
describe components that are present in the device.
The memory from the device-tree is remapped to the BAR memory thanks to
"ranges" properties computed at runtime by the PCI core during the PCI
enumeration.
The PCI device itself acts as an interrupt controller and is used as the
parent of the internal LAN966x interrupt controller to route the
interrupts to the assigned PCI INTx interrupt.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
drivers/mfd/Kconfig | 24 ++++
drivers/mfd/Makefile | 4 +
drivers/mfd/lan966x_pci.c | 229 +++++++++++++++++++++++++++++++++++
drivers/mfd/lan966x_pci.dtso | 167 +++++++++++++++++++++++++
drivers/pci/quirks.c | 1 +
5 files changed, 425 insertions(+)
create mode 100644 drivers/mfd/lan966x_pci.c
create mode 100644 drivers/mfd/lan966x_pci.dtso
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4b023ee229cf..e5f5d2986dd3 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -144,6 +144,30 @@ config MFD_ATMEL_FLEXCOM
by the probe function of this MFD driver according to a device tree
property.
+config MFD_LAN966X_PCI
+ tristate "Microchip LAN966x PCIe Support"
+ depends on PCI
+ select OF
+ select OF_OVERLAY
+ select IRQ_DOMAIN
+ help
+ This enables the support for the LAN966x PCIe device.
+ This is used to drive the LAN966x PCIe device from the host system
+ to which it is connected.
+
+ This driver uses an overlay to load other drivers to support for
+ LAN966x internal components.
+ Even if this driver does not depend on these other drivers, in order
+ to have a fully functional board, the following drivers are needed:
+ - fixed-clock (COMMON_CLK)
+ - lan966x-oic (LAN966X_OIC)
+ - lan966x-cpu-syscon (MFD_SYSCON)
+ - lan966x-switch-reset (RESET_MCHP_SPARX5)
+ - lan966x-pinctrl (PINCTRL_OCELOT)
+ - lan966x-serdes (PHY_LAN966X_SERDES)
+ - lan966x-miim (MDIO_MSCC_MIIM)
+ - lan966x-switch (LAN966X_SWITCH)
+
config MFD_ATMEL_HLCDC
tristate "Atmel HLCDC (High-end LCD Controller)"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c66f07edcd0e..165a9674ff48 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -284,3 +284,7 @@ rsmu-i2c-objs := rsmu_core.o rsmu_i2c.o
rsmu-spi-objs := rsmu_core.o rsmu_spi.o
obj-$(CONFIG_MFD_RSMU_I2C) += rsmu-i2c.o
obj-$(CONFIG_MFD_RSMU_SPI) += rsmu-spi.o
+
+lan966x-pci-objs := lan966x_pci.o
+lan966x-pci-objs += lan966x_pci.dtbo.o
+obj-$(CONFIG_MFD_LAN966X_PCI) += lan966x-pci.o
diff --git a/drivers/mfd/lan966x_pci.c b/drivers/mfd/lan966x_pci.c
new file mode 100644
index 000000000000..d9d886a1948f
--- /dev/null
+++ b/drivers/mfd/lan966x_pci.c
@@ -0,0 +1,229 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Microchip LAN966x PCI driver
+ *
+ * Copyright (c) 2024 Microchip Technology Inc. and its subsidiaries.
+ *
+ * Authors:
+ * Clément Léger <clement.leger@bootlin.com>
+ * Hervé Codina <herve.codina@bootlin.com>
+ */
+
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+
+/* Embedded dtbo symbols created by cmd_wrap_S_dtb in scripts/Makefile.lib */
+extern char __dtbo_lan966x_pci_begin[];
+extern char __dtbo_lan966x_pci_end[];
+
+struct pci_dev_intr_ctrl {
+ struct pci_dev *pci_dev;
+ struct irq_domain *irq_domain;
+ int irq;
+};
+
+static int pci_dev_irq_domain_map(struct irq_domain *d, unsigned int virq, irq_hw_number_t hw)
+{
+ irq_set_chip_and_handler(virq, &dummy_irq_chip, handle_simple_irq);
+ return 0;
+}
+
+static const struct irq_domain_ops pci_dev_irq_domain_ops = {
+ .map = pci_dev_irq_domain_map,
+ .xlate = irq_domain_xlate_onecell,
+};
+
+static irqreturn_t pci_dev_irq_handler(int irq, void *data)
+{
+ struct pci_dev_intr_ctrl *intr_ctrl = data;
+ int ret;
+
+ ret = generic_handle_domain_irq(intr_ctrl->irq_domain, 0);
+ return ret ? IRQ_NONE : IRQ_HANDLED;
+}
+
+static struct pci_dev_intr_ctrl *pci_dev_create_intr_ctrl(struct pci_dev *pdev)
+{
+ struct pci_dev_intr_ctrl *intr_ctrl;
+ struct fwnode_handle *fwnode;
+ int ret;
+
+ if (!pdev->irq)
+ return ERR_PTR(-EOPNOTSUPP);
+
+ fwnode = dev_fwnode(&pdev->dev);
+ if (!fwnode)
+ return ERR_PTR(-ENODEV);
+
+ intr_ctrl = kmalloc(sizeof(*intr_ctrl), GFP_KERNEL);
+ if (!intr_ctrl)
+ return ERR_PTR(-ENOMEM);
+
+ intr_ctrl->pci_dev = pdev;
+
+ intr_ctrl->irq_domain = irq_domain_create_linear(fwnode, 1, &pci_dev_irq_domain_ops,
+ intr_ctrl);
+ if (!intr_ctrl->irq_domain) {
+ pci_err(pdev, "Failed to create irqdomain\n");
+ ret = -ENOMEM;
+ goto err_free_intr_ctrl;
+ }
+
+ ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_LEGACY);
+ if (ret < 0) {
+ pci_err(pdev, "Unable alloc irq vector (%d)\n", ret);
+ goto err_remove_domain;
+ }
+ intr_ctrl->irq = pci_irq_vector(pdev, 0);
+ ret = request_irq(intr_ctrl->irq, pci_dev_irq_handler, IRQF_SHARED,
+ dev_name(&pdev->dev), intr_ctrl);
+ if (ret) {
+ pci_err(pdev, "Unable to request irq %d (%d)\n", intr_ctrl->irq, ret);
+ goto err_free_irq_vector;
+ }
+
+ return intr_ctrl;
+
+err_free_irq_vector:
+ pci_free_irq_vectors(pdev);
+err_remove_domain:
+ irq_domain_remove(intr_ctrl->irq_domain);
+err_free_intr_ctrl:
+ kfree(intr_ctrl);
+ return ERR_PTR(ret);
+}
+
+static void pci_dev_remove_intr_ctrl(struct pci_dev_intr_ctrl *intr_ctrl)
+{
+ free_irq(intr_ctrl->irq, intr_ctrl);
+ pci_free_irq_vectors(intr_ctrl->pci_dev);
+ irq_dispose_mapping(irq_find_mapping(intr_ctrl->irq_domain, 0));
+ irq_domain_remove(intr_ctrl->irq_domain);
+ kfree(intr_ctrl);
+}
+
+static void devm_pci_dev_remove_intr_ctrl(void *data)
+{
+ struct pci_dev_intr_ctrl *intr_ctrl = data;
+
+ pci_dev_remove_intr_ctrl(intr_ctrl);
+}
+
+static int devm_pci_dev_create_intr_ctrl(struct pci_dev *pdev)
+{
+ struct pci_dev_intr_ctrl *intr_ctrl;
+
+ intr_ctrl = pci_dev_create_intr_ctrl(pdev);
+
+ if (IS_ERR(intr_ctrl))
+ return PTR_ERR(intr_ctrl);
+
+ return devm_add_action_or_reset(&pdev->dev, devm_pci_dev_remove_intr_ctrl, intr_ctrl);
+}
+
+struct lan966x_pci {
+ struct device *dev;
+ struct pci_dev *pci_dev;
+ int ovcs_id;
+};
+
+static int lan966x_pci_load_overlay(struct lan966x_pci *data)
+{
+ u32 dtbo_size = __dtbo_lan966x_pci_end - __dtbo_lan966x_pci_begin;
+ void *dtbo_start = __dtbo_lan966x_pci_begin;
+ int ret;
+
+ ret = of_overlay_fdt_apply(dtbo_start, dtbo_size, &data->ovcs_id, data->dev->of_node);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static void lan966x_pci_unload_overlay(struct lan966x_pci *data)
+{
+ of_overlay_remove(&data->ovcs_id);
+}
+
+static int lan966x_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+ struct device *dev = &pdev->dev;
+ struct lan966x_pci *data;
+ int ret;
+
+ if (!dev->of_node) {
+ dev_err(dev, "Missing of_node for device\n");
+ return -EINVAL;
+ }
+
+ /* Need to be done before devm_pci_dev_create_intr_ctrl.
+ * It allocates an IRQ and so pdev->irq is updated
+ */
+ ret = pcim_enable_device(pdev);
+ if (ret)
+ return ret;
+
+ ret = devm_pci_dev_create_intr_ctrl(pdev);
+ if (ret)
+ return ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ dev_set_drvdata(dev, data);
+ data->dev = dev;
+ data->pci_dev = pdev;
+
+ ret = lan966x_pci_load_overlay(data);
+ if (ret)
+ return ret;
+
+ pci_set_master(pdev);
+
+ ret = of_platform_default_populate(dev->of_node, NULL, dev);
+ if (ret)
+ goto err_unload_overlay;
+
+ return 0;
+
+err_unload_overlay:
+ lan966x_pci_unload_overlay(data);
+ return ret;
+}
+
+static void lan966x_pci_remove(struct pci_dev *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct lan966x_pci *data = dev_get_drvdata(dev);
+
+ of_platform_depopulate(dev);
+
+ lan966x_pci_unload_overlay(data);
+
+ pci_clear_master(pdev);
+}
+
+static struct pci_device_id lan966x_pci_ids[] = {
+ { PCI_DEVICE(0x1055, 0x9660) },
+ { 0, }
+};
+MODULE_DEVICE_TABLE(pci, lan966x_pci_ids);
+
+static struct pci_driver lan966x_pci_driver = {
+ .name = "mchp_lan966x_pci",
+ .id_table = lan966x_pci_ids,
+ .probe = lan966x_pci_probe,
+ .remove = lan966x_pci_remove,
+};
+module_pci_driver(lan966x_pci_driver);
+
+MODULE_AUTHOR("Herve Codina <herve.codina@bootlin.com>");
+MODULE_DESCRIPTION("Microchip LAN966x PCI driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/lan966x_pci.dtso b/drivers/mfd/lan966x_pci.dtso
new file mode 100644
index 000000000000..041f4319e4cd
--- /dev/null
+++ b/drivers/mfd/lan966x_pci.dtso
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Microchip UNG
+ */
+
+#include <dt-bindings/clock/microchip,lan966x.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/mfd/atmel-flexcom.h>
+#include <dt-bindings/phy/phy-lan966x-serdes.h>
+#include <dt-bindings/gpio/gpio.h>
+
+/dts-v1/;
+/plugin/;
+
+/ {
+ fragment@0 {
+ target-path="";
+ __overlay__ {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ pci-ep-bus@0 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /*
+ * map @0xe2000000 (32MB) to BAR0 (CPU)
+ * map @0xe0000000 (16MB) to BAR1 (AMBA)
+ */
+ ranges = <0xe2000000 0x00 0x00 0x00 0x2000000
+ 0xe0000000 0x01 0x00 0x00 0x1000000>;
+
+ oic: oic@e00c0120 {
+ compatible = "microchip,lan966x-oic";
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts = <0>; /* PCI INTx assigned interrupt */
+ reg = <0xe00c0120 0x190>;
+ };
+
+ cpu_clk: cpu_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <600000000>; // CPU clock = 600MHz
+ };
+
+ ddr_clk: ddr_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <30000000>; // Fabric clock = 30MHz
+ };
+
+ sys_clk: sys_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <15625000>; // System clock = 15.625MHz
+ };
+
+ cpu_ctrl: syscon@e00c0000 {
+ compatible = "microchip,lan966x-cpu-syscon", "syscon";
+ reg = <0xe00c0000 0xa8>;
+ };
+
+ reset: reset@e200400c {
+ compatible = "microchip,lan966x-switch-reset";
+ reg = <0xe200400c 0x4>;
+ reg-names = "gcb";
+ #reset-cells = <1>;
+ cpu-syscon = <&cpu_ctrl>;
+ };
+
+ gpio: pinctrl@e2004064 {
+ compatible = "microchip,lan966x-pinctrl";
+ reg = <0xe2004064 0xb4>,
+ <0xe2010024 0x138>;
+ resets = <&reset 0>;
+ reset-names = "switch";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&gpio 0 0 78>;
+ interrupt-parent = <&oic>;
+ interrupt-controller;
+ interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <2>;
+
+ tod_pins: tod_pins {
+ pins = "GPIO_36";
+ function = "ptpsync_1";
+ };
+
+ fc0_a_pins: fcb4-i2c-pins {
+ /* RXD, TXD */
+ pins = "GPIO_9", "GPIO_10";
+ function = "fc0_a";
+ };
+
+ };
+
+ serdes: serdes@e202c000 {
+ compatible = "microchip,lan966x-serdes";
+ reg = <0xe202c000 0x9c>,
+ <0xe2004010 0x4>;
+ #phy-cells = <2>;
+ };
+
+ mdio1: mdio@e200413c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "microchip,lan966x-miim";
+ reg = <0xe200413c 0x24>,
+ <0xe2010020 0x4>;
+
+ resets = <&reset 0>;
+ reset-names = "switch";
+
+ lan966x_phy0: ethernet-lan966x_phy@1 {
+ reg = <1>;
+ };
+
+ lan966x_phy1: ethernet-lan966x_phy@2 {
+ reg = <2>;
+ };
+ };
+
+ switch: switch@e0000000 {
+ compatible = "microchip,lan966x-switch";
+ reg = <0xe0000000 0x0100000>,
+ <0xe2000000 0x0800000>;
+ reg-names = "cpu", "gcb";
+
+ interrupt-parent = <&oic>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH>,
+ <9 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "xtr", "ana";
+
+ resets = <&reset 0>;
+ reset-names = "switch";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tod_pins>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port0: port@0 {
+ phy-handle = <&lan966x_phy0>;
+
+ reg = <0>;
+ phy-mode = "gmii";
+ phys = <&serdes 0 CU(0)>;
+ };
+
+ port1: port@1 {
+ phy-handle = <&lan966x_phy1>;
+
+ reg = <1>;
+ phy-mode = "gmii";
+ phys = <&serdes 1 CU(1)>;
+ };
+ };
+ };
+ };
+ };
+ };
+};
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index eff7f5df08e2..9933f245b781 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6241,6 +6241,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0xa76e, dpc_log_size);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5020, of_pci_make_dev_node);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5021, of_pci_make_dev_node);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REDHAT, 0x0005, of_pci_make_dev_node);
+DECLARE_PCI_FIXUP_FINAL(0x1055, 0x9660, of_pci_make_dev_node);
/*
* Devices known to require a longer delay before first config space access
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 15/17] pci: of_property: Add the interrupt-controller property in PCI device nodes
From: Herve Codina @ 2024-04-30 8:37 UTC (permalink / raw)
To: Herve Codina, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lee Jones, Arnd Bergmann, Horatiu Vultur,
UNGLinuxDriver, Andrew Lunn, Heiner Kallweit, Russell King,
Saravana Kannan, Bjorn Helgaas, Philipp Zabel, Lars Povlsen,
Steen Hegelund, Daniel Machon, Alexandre Belloni
Cc: linux-kernel, devicetree, netdev, linux-pci, linux-arm-kernel,
Allan Nielsen, Steen Hegelund, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20240430083730.134918-1-herve.codina@bootlin.com>
PCI devices and bridges DT nodes created during the PCI scan are created
with the interrupt-map property set to handle interrupts.
In order to set this interrupt-map property at a specific level, a
phandle to the parent interrupt controller is needed.
On systems that are not fully described by a device-tree, the parent
interrupt controller may be unavailable (i.e. not described by the
device-tree).
As mentioned in the [1], avoiding the use of the interrupt-map property
and considering a PCI device as an interrupt controller itself avoid the
use of a parent interrupt phandle.
In that case, the PCI device itself as an interrupt controller is
responsible for routing the interrupts described in the device-tree
world (DT overlay) to the PCI interrupts.
Add the 'interrupt-controller' property in the PCI device DT node.
[1]: https://lore.kernel.org/lkml/CAL_Jsq+je7+9ATR=B6jXHjEJHjn24vQFs4Tvi9=vhDeK9n42Aw@mail.gmail.com/
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
drivers/pci/of_property.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/pci/of_property.c b/drivers/pci/of_property.c
index c2c7334152bc..9f8b940029ed 100644
--- a/drivers/pci/of_property.c
+++ b/drivers/pci/of_property.c
@@ -183,6 +183,26 @@ static int of_pci_prop_interrupts(struct pci_dev *pdev,
return of_changeset_add_prop_u32(ocs, np, "interrupts", (u32)pin);
}
+static int of_pci_prop_intr_ctrl(struct pci_dev *pdev, struct of_changeset *ocs,
+ struct device_node *np)
+{
+ int ret;
+ u8 pin;
+
+ ret = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
+ if (ret != 0)
+ return ret;
+
+ if (!pin)
+ return 0;
+
+ ret = of_changeset_add_prop_u32(ocs, np, "#interrupt-cells", 1);
+ if (ret)
+ return ret;
+
+ return of_changeset_add_prop_bool(ocs, np, "interrupt-controller");
+}
+
static int of_pci_prop_intr_map(struct pci_dev *pdev, struct of_changeset *ocs,
struct device_node *np)
{
@@ -334,6 +354,10 @@ int of_pci_add_properties(struct pci_dev *pdev, struct of_changeset *ocs,
ret = of_pci_prop_intr_map(pdev, ocs, np);
if (ret)
return ret;
+ } else {
+ ret = of_pci_prop_intr_ctrl(pdev, ocs, np);
+ if (ret)
+ return ret;
}
ret = of_pci_prop_ranges(pdev, ocs, np);
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 6/7] iommu/dma: Centralise iommu_setup_dma_ops()
From: Dmitry Baryshkov @ 2024-04-30 10:56 UTC (permalink / raw)
To: Robin Murphy
Cc: Joerg Roedel, Christoph Hellwig, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Huacai Chen, WANG Xuerui,
Thomas Bogendoerfer, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Suravee Suthikulpanit,
David Woodhouse, Lu Baolu, Niklas Schnelle, Matthew Rosato,
Gerald Schaefer, Jean-Philippe Brucker, Rob Herring, Frank Rowand,
Marek Szyprowski, Jason Gunthorpe, linux-kernel, linux-arm-kernel,
linux-acpi, iommu, devicetree, Jason Gunthorpe
In-Reply-To: <20d44077-d0a8-470a-bf6f-82683db894cf@arm.com>
On Tue, 30 Apr 2024 at 13:20, Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2024-04-30 1:41 am, Dmitry Baryshkov wrote:
> > On Tue, 30 Apr 2024 at 01:26, Robin Murphy <robin.murphy@arm.com> wrote:
> >>
> >> On 2024-04-29 5:31 pm, Dmitry Baryshkov wrote:
> >>> On Fri, Apr 19, 2024 at 05:54:45PM +0100, Robin Murphy wrote:
> >>>> It's somewhat hard to see, but arm64's arch_setup_dma_ops() should only
> >>>> ever call iommu_setup_dma_ops() after a successful iommu_probe_device(),
> >>>> which means there should be no harm in achieving the same order of
> >>>> operations by running it off the back of iommu_probe_device() itself.
> >>>> This then puts it in line with the x86 and s390 .probe_finalize bodges,
> >>>> letting us pull it all into the main flow properly. As a bonus this lets
> >>>> us fold in and de-scope the PCI workaround setup as well.
> >>>>
> >>>> At this point we can also then pull the call up inside the group mutex,
> >>>> and avoid having to think about whether iommu_group_store_type() could
> >>>> theoretically race and free the domain if iommu_setup_dma_ops() ran just
> >>>> *before* iommu_device_use_default_domain() claims it... Furthermore we
> >>>> replace one .probe_finalize call completely, since the only remaining
> >>>> implementations are now one which only needs to run once for the initial
> >>>> boot-time probe, and two which themselves render that path unreachable.
> >>>>
> >>>> This leaves us a big step closer to realistically being able to unpick
> >>>> the variety of different things that iommu_setup_dma_ops() has been
> >>>> muddling together, and further streamline iommu-dma into core API flows
> >>>> in future.
> >>>>
> >>>> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> # For Intel IOMMU
> >>>> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> >>>> Tested-by: Hanjun Guo <guohanjun@huawei.com>
> >>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >>>> ---
> >>>> v2: Shuffle around to make sure the iommu_group_do_probe_finalize() case
> >>>> is covered as well, with bonus side-effects as above.
> >>>> v3: *Really* do that, remembering the other two probe_finalize sites too.
> >>>> ---
> >>>> arch/arm64/mm/dma-mapping.c | 2 --
> >>>> drivers/iommu/amd/iommu.c | 8 --------
> >>>> drivers/iommu/dma-iommu.c | 18 ++++++------------
> >>>> drivers/iommu/dma-iommu.h | 14 ++++++--------
> >>>> drivers/iommu/intel/iommu.c | 7 -------
> >>>> drivers/iommu/iommu.c | 20 +++++++-------------
> >>>> drivers/iommu/s390-iommu.c | 6 ------
> >>>> drivers/iommu/virtio-iommu.c | 10 ----------
> >>>> include/linux/iommu.h | 7 -------
> >>>> 9 files changed, 19 insertions(+), 73 deletions(-)
> >>>
> >>> This patch breaks UFS on Qualcomm SC8180X Primus platform:
> >>>
> >>>
> >>> [ 3.846856] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x1032db3e0, fsynr=0x130000, cbfrsynra=0x300, cb=4
> >>
> >> Hmm, a context fault implies that the device did get attached to a DMA
> >> domain, thus has successfully been through __iommu_probe_device(), yet
> >> somehow still didn't get the right DMA ops (since that "IOVA" looks more
> >> like a PA to me). Do you see the "Adding to IOMMU group..." message for
> >> this device, and/or any other relevant messages or errors before this
> >> point?
> >
> > No, nothing relevant.
> >
> > [ 8.372395] ufshcd-qcom 1d84000.ufshc: Adding to iommu group 6
> >
> > (please ignore the timestamp, it comes before ufshc being probed).
> >
> >> I'm guessing there's a fair chance probe deferral might be
> >> involved as well. I'd like to understand what path(s) this ends up
> >> taking through __iommu_probe_device() and of_dma_configure(), or at
> >> least the number and order of probe attempts between the UFS and SMMU
> >> drivers.
> >
> > __iommu_probe_device() gets called twice and returns early because ops is NULL.
> >
> > Then finally of_dma_configure_id() is called. The following branches are taken:
> >
> > np == dev->of_node
> > of_dma_get_range() returned 0
> > bus_dma_limit and dma_range_map are set
> > __iommu_probe_device() is called, using the `!group->default_domain &&
> > !group_lis` case, then group->default_domain() is not NULL,
> > In the end, iommu_setup_dma_ops() is called.
> >
> > Then the ufshc probe defers (most likely the PHY is not present or
> > some other device is not there yet).
>
> Ah good, probe deferral. And indeed the half-formed hunch from last
> night grew into a pretty definite idea by this morning... patch incoming.
Thanks a lot for the quick fix!
--
With best wishes
Dmitry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: ti: k3-am62p-main: Fix the reg-range for main_pktdma
From: Jayesh Choudhary @ 2024-04-30 10:52 UTC (permalink / raw)
To: nm, vigneshr, u-kumar1, bb, devicetree, j-choudhary
Cc: kristo, robh, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel
In-Reply-To: <20240430105253.203750-1-j-choudhary@ti.com>
For main_pktdma node, the TX Channel Realtime Register region 'tchanrt'
is 128KB and Ring Realtime Register region 'ringrt' is 2MB as shown in
memory map in the TRM[0] (Table 2-1).
So fix ranges for those register regions.
[0]: <https://www.ti.com/lit/pdf/spruj83>
Fixes: b5080c7c1f7e ("arm64: dts: ti: k3-am62p: Add nodes for more IPs")
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
index 900d1f9530a2..2b9bc77a0540 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
@@ -123,8 +123,8 @@ main_pktdma: dma-controller@485c0000 {
compatible = "ti,am64-dmss-pktdma";
reg = <0x00 0x485c0000 0x00 0x100>,
<0x00 0x4a800000 0x00 0x20000>,
- <0x00 0x4aa00000 0x00 0x40000>,
- <0x00 0x4b800000 0x00 0x400000>,
+ <0x00 0x4aa00000 0x00 0x20000>,
+ <0x00 0x4b800000 0x00 0x200000>,
<0x00 0x485e0000 0x00 0x10000>,
<0x00 0x484a0000 0x00 0x2000>,
<0x00 0x484c0000 0x00 0x2000>,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: ti: k3-am62a-main: Fix the reg-range for main_pktdma
From: Jayesh Choudhary @ 2024-04-30 10:52 UTC (permalink / raw)
To: nm, vigneshr, u-kumar1, bb, devicetree, j-choudhary
Cc: kristo, robh, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel
In-Reply-To: <20240430105253.203750-1-j-choudhary@ti.com>
For main_pktdma node, the TX Channel Realtime Register region 'tchanrt'
is 128KB and Ring Realtime Register region 'ringrt' is 2MB as shown in
memory map in the TRM[0] (Table 2-1).
So fix ranges for those register regions.
[0]: <https://www.ti.com/lit/pdf/spruj16>
Fixes: 3dad70def7ff ("arm64: dts: ti: k3-am62a-main: Add more peripheral nodes")
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
index bf9c2d9c6439..ce4a2f105630 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
@@ -120,8 +120,8 @@ main_pktdma: dma-controller@485c0000 {
compatible = "ti,am64-dmss-pktdma";
reg = <0x00 0x485c0000 0x00 0x100>,
<0x00 0x4a800000 0x00 0x20000>,
- <0x00 0x4aa00000 0x00 0x40000>,
- <0x00 0x4b800000 0x00 0x400000>,
+ <0x00 0x4aa00000 0x00 0x20000>,
+ <0x00 0x4b800000 0x00 0x200000>,
<0x00 0x485e0000 0x00 0x10000>,
<0x00 0x484a0000 0x00 0x2000>,
<0x00 0x484c0000 0x00 0x2000>,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/3] arm64: dts: ti: k3-am62-main: Fix the reg-range for main_pktdma
From: Jayesh Choudhary @ 2024-04-30 10:52 UTC (permalink / raw)
To: nm, vigneshr, u-kumar1, bb, devicetree, j-choudhary
Cc: kristo, robh, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel
In-Reply-To: <20240430105253.203750-1-j-choudhary@ti.com>
For main_pktdma node, the TX Channel Realtime Register region 'tchanrt'
is 128KB and Ring Realtime Register region 'ringrt' is 2MB as shown in
memory map in the TRM[0] (Table 2-1).
So fix ranges for those register regions.
[0]: <https://www.ti.com/lit/pdf/spruiv7>
Fixes: c37c58fdeb8a ("arm64: dts: ti: k3-am62: Add more peripheral nodes")
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index 448a59dc53a7..0f2722c4bcc3 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -141,8 +141,8 @@ main_pktdma: dma-controller@485c0000 {
compatible = "ti,am64-dmss-pktdma";
reg = <0x00 0x485c0000 0x00 0x100>,
<0x00 0x4a800000 0x00 0x20000>,
- <0x00 0x4aa00000 0x00 0x40000>,
- <0x00 0x4b800000 0x00 0x400000>,
+ <0x00 0x4aa00000 0x00 0x20000>,
+ <0x00 0x4b800000 0x00 0x200000>,
<0x00 0x485e0000 0x00 0x10000>,
<0x00 0x484a0000 0x00 0x2000>,
<0x00 0x484c0000 0x00 0x2000>,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/3] Fix reg ranges for main_pktdma dma-controller node
From: Jayesh Choudhary @ 2024-04-30 10:52 UTC (permalink / raw)
To: nm, vigneshr, u-kumar1, bb, devicetree, j-choudhary
Cc: kristo, robh, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel
The dma-controller node 'main_pktdma' has few memory regions with
wrong sizes.
DMASS0_PKTDMA_RINGRT is marked as 4MB region when it is actually a 2MB
region. Similarly, DMASS0_PKTDMA_TCHANRT is marked as 256KB region but
the actual size is 128KB as shown in TRM in the section for Main Memory
Map (Table 2-1)
Fix these region across AM62, AM62A and AM62P (which is also used in
J722S)
TRM:
AM625: <https://www.ti.com/lit/pdf/spruiv7>
AM62A7: <https://www.ti.com/lit/pdf/spruj16>
AM62P: <https://www.ti.com/lit/pdf/spruj83>
J722S: <https://www.ti.com/lit/zip/sprujb3>
Changelog v1->v2:
- Add main_pktdma node name in commit message for more clarity about the
dma-controller and mention the table for memory map in TRM in each patch.
v1 patch:
<https://lore.kernel.org/all/20240405085208.32227-1-j-choudhary@ti.com/>
Jayesh Choudhary (3):
arm64: dts: ti: k3-am62-main: Fix the reg-range for main_pktdma
arm64: dts: ti: k3-am62a-main: Fix the reg-range for main_pktdma
arm64: dts: ti: k3-am62p-main: Fix the reg-range for main_pktdma
arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 4 ++--
arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 4 ++--
arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 04/16] ACPI: processor: Move checks and availability of acpi_processor earlier
From: Rafael J. Wysocki @ 2024-04-30 10:47 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Rafael J. Wysocki, Gavin Shan, Thomas Gleixner, Peter Zijlstra,
linux-pm, loongarch, linux-acpi, linux-arch, linux-kernel,
linux-arm-kernel, kvmarm, x86, Russell King, Miguel Luis,
James Morse, Salil Mehta, Jean-Philippe Brucker, Catalin Marinas,
Will Deacon, Marc Zyngier, Hanjun Guo, Ingo Molnar,
Borislav Petkov, Dave Hansen, linuxarm, justin.he, jianyong.wu,
Lorenzo Pieralisi, Sudeep Holla
In-Reply-To: <20240430114534.0000600e@huawei.com>
On Tue, Apr 30, 2024 at 12:45 PM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Tue, 30 Apr 2024 12:17:38 +0200
> "Rafael J. Wysocki" <rafael@kernel.org> wrote:
>
> > On Tue, Apr 30, 2024 at 12:13 PM Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > >
> > > On Tue, 30 Apr 2024 10:28:38 +0100
> > > Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> > >
> > > > On Tue, 30 Apr 2024 14:17:24 +1000
> > > > Gavin Shan <gshan@redhat.com> wrote:
> > > >
> > > > > On 4/26/24 23:51, Jonathan Cameron wrote:
> > > > > > Make the per_cpu(processors, cpu) entries available earlier so that
> > > > > > they are available in arch_register_cpu() as ARM64 will need access
> > > > > > to the acpi_handle to distinguish between acpi_processor_add()
> > > > > > and earlier registration attempts (which will fail as _STA cannot
> > > > > > be checked).
> > > > > >
> > > > > > Reorder the remove flow to clear this per_cpu() after
> > > > > > arch_unregister_cpu() has completed, allowing it to be used in
> > > > > > there as well.
> > > > > >
> > > > > > Note that on x86 for the CPU hotplug case, the pr->id prior to
> > > > > > acpi_map_cpu() may be invalid. Thus the per_cpu() structures
> > > > > > must be initialized after that call or after checking the ID
> > > > > > is valid (not hotplug path).
> > > > > >
> > > > > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > > >
> > > > > > ---
> > > > > > v8: On buggy bios detection when setting per_cpu structures
> > > > > > do not carry on.
> > > > > > Fix up the clearing of per cpu structures to remove unwanted
> > > > > > side effects and ensure an error code isn't use to reference them.
> > > > > > ---
> > > > > > drivers/acpi/acpi_processor.c | 79 +++++++++++++++++++++--------------
> > > > > > 1 file changed, 48 insertions(+), 31 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > > > > > index ba0a6f0ac841..3b180e21f325 100644
> > > > > > --- a/drivers/acpi/acpi_processor.c
> > > > > > +++ b/drivers/acpi/acpi_processor.c
> > > > > > @@ -183,8 +183,38 @@ static void __init acpi_pcc_cpufreq_init(void) {}
> > > > > > #endif /* CONFIG_X86 */
> > > > > >
> > > > > > /* Initialization */
> > > > > > +static DEFINE_PER_CPU(void *, processor_device_array);
> > > > > > +
> > > > > > +static bool acpi_processor_set_per_cpu(struct acpi_processor *pr,
> > > > > > + struct acpi_device *device)
> > > > > > +{
> > > > > > + BUG_ON(pr->id >= nr_cpu_ids);
> > > > >
> > > > > One blank line after BUG_ON() if we need to follow original implementation.
> > > >
> > > > Sure unintentional - I'll put that back.
> > > >
> > > > >
> > > > > > + /*
> > > > > > + * Buggy BIOS check.
> > > > > > + * ACPI id of processors can be reported wrongly by the BIOS.
> > > > > > + * Don't trust it blindly
> > > > > > + */
> > > > > > + if (per_cpu(processor_device_array, pr->id) != NULL &&
> > > > > > + per_cpu(processor_device_array, pr->id) != device) {
> > > > > > + dev_warn(&device->dev,
> > > > > > + "BIOS reported wrong ACPI id %d for the processor\n",
> > > > > > + pr->id);
> > > > > > + /* Give up, but do not abort the namespace scan. */
> > > > >
> > > > > It depends on how the return value is handled by the caller if the namespace
> > > > > is continued to be scanned. The caller can be acpi_processor_hotadd_init()
> > > > > and acpi_processor_get_info() after this patch is applied. So I think this
> > > > > specific comment need to be moved to the caller.
> > > >
> > > > Good point. This gets messy and was an unintended change.
> > > >
> > > > Previously the options were:
> > > > 1) acpi_processor_get_info() failed for other reasons - this code was never called.
> > > > 2) acpi_processor_get_info() succeeded without acpi_processor_hotadd_init (non hotplug)
> > > > this code then ran and would paper over the problem doing a bunch of cleanup under err.
> > > > 3) acpi_processor_get_info() succeeded with acpi_processor_hotadd_init called.
> > > > This code then ran and would paper over the problem doing a bunch of cleanup under err.
> > > >
> > > > We should maintain that or argue cleanly against it.
> > > >
> > > > This isn't helped the the fact I have no idea which cases we care about for that bios
> > > > bug handling. Do any of those bios's ever do hotplug? Guess we have to try and maintain
> > > > whatever protection this was offering.
> > > >
> > > > Also, the original code leaks data in some paths and I have limited idea
> > > > of whether it is intentional or not. So to tidy the issue up that you've identified
> > > > I'll need to try and make that code consistent first.
> > > >
> > > > I suspect the only way to do that is going to be to duplicate the allocations we
> > > > 'want' to leak to deal with the bios bug detection.
> > > >
> > > > For example acpi_processor_get_info() failing leaks pr and pr->throttling.shared_cpu_map
> > > > before this series. After this series we need pr to leak because it's used for the detection
> > > > via processor_device_array.
> > > >
> > > > I'll work through this but it's going to be tricky to tell if we get right.
> > > > Step 1 will be closing the existing leaks and then we will have something
> > > > consistent to build on.
> > > >
> > > I 'think' that fixing the original leaks makes this all much more straight forward.
> > > That return 0 for acpi_processor_get_info() never made sense as far as I can tell.
> > > The pr isn't used after this point.
> > >
> > > What about something along lines of.
> > >
> > > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > > index 161c95c9d60a..97cff4492304 100644
> > > --- a/drivers/acpi/acpi_processor.c
> > > +++ b/drivers/acpi/acpi_processor.c
> > > @@ -392,8 +392,10 @@ static int acpi_processor_add(struct acpi_device *device,
> > > device->driver_data = pr;
> > >
> > > result = acpi_processor_get_info(device);
> > > - if (result) /* Processor is not physically present or unavailable */
> > > - return 0;
> > > + if (result) { /* Processor is not physically present or unavailable */
> > > + result = 0;
> >
> > As per my previous message (just sent) this should be an error code,
> > as returning 0 from acpi_processor_add() is generally problematic.
> Ok. I'll switch to that, but as a separate precusor patch. Independent of
> the memory leak fixes.
Sure, thank you!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: Add cache information to the SoC dtsi for H6
From: Andre Przywara @ 2024-04-30 10:46 UTC (permalink / raw)
To: Dragan Simic
Cc: linux-sunxi, wens, jernej.skrabec, samuel, linux-arm-kernel,
devicetree, robh, krzk+dt, conor+dt, linux-kernel
In-Reply-To: <6fdeb49d57ccccca62e4f43dbe9475e3@manjaro.org>
On Tue, 30 Apr 2024 02:01:42 +0200
Dragan Simic <dsimic@manjaro.org> wrote:
Hi Dragan,
> Hello Andre,
>
> On 2024-04-30 01:10, Andre Przywara wrote:
> > On Sun, 28 Apr 2024 13:40:36 +0200
> > Dragan Simic <dsimic@manjaro.org> wrote:
> >
> >> Add missing cache information to the Allwinner H6 SoC dtsi, to allow
> >> the userspace, which includes lscpu(1) that uses the virtual files
> >> provided
> >> by the kernel under the /sys/devices/system/cpu directory, to display
> >> the
> >> proper H6 cache information.
> >>
> >> Adding the cache information to the H6 SoC dtsi also makes the
> >> following
> >> warning message in the kernel log go away:
> >>
> >> cacheinfo: Unable to detect cache hierarchy for CPU 0
> >>
> >> The cache parameters for the H6 dtsi were obtained and partially
> >> derived
> >> by hand from the cache size and layout specifications found in the
> >> following
> >> datasheets and technical reference manuals:
> >>
> >> - Allwinner H6 V200 datasheet, version 1.1
> >> - ARM Cortex-A53 revision r0p3 TRM, version E
> >>
> >> For future reference, here's a brief summary of the documentation:
> >>
> >> - All caches employ the 64-byte cache line length
> >> - Each Cortex-A53 core has 32 KB of L1 2-way, set-associative
> >> instruction
> >> cache and 32 KB of L1 4-way, set-associative data cache
> >> - The entire SoC has 512 KB of unified L2 16-way, set-associative
> >> cache
> >>
> >> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
> >
> > I can confirm that the data below matches the manuals, but also the
> > decoding of the architectural cache type registers (CCSIDR_EL1):
> > L1D: 32 KB: 128 sets, 4 way associative, 64 bytes/line
> > L1I: 32 KB: 256 sets, 2 way associative, 64 bytes/line
> > L2: 512 KB: 512 sets, 16 way associative, 64 bytes/line
>
> Thank you very much for reviewing my patch in such a detailed way!
> It's good to know that the values in the Allwinner datasheets match
> with the observed reality, so to speak. :)
YW, and yes, I like to double check things when it comes to Allwinner
documentation ;-) And it was comparably easy for this problem.
Out of curiosity: what triggered that patch? Trying to get rid of false
warning/error messages?
And do you plan to address the H616 as well? It's a bit more tricky there,
since there are two die revisions out: one with 256(?)KB of L2, one with
1MB(!). We know how to tell them apart, so I could provide some TF-A code
to patch that up in the DT. The kernel DT copy could go with 256KB then.
Cheers,
Andre.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 04/16] ACPI: processor: Move checks and availability of acpi_processor earlier
From: Jonathan Cameron @ 2024-04-30 10:45 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Gavin Shan, Thomas Gleixner, Peter Zijlstra, linux-pm, loongarch,
linux-acpi, linux-arch, linux-kernel, linux-arm-kernel, kvmarm,
x86, Russell King, Miguel Luis, James Morse, Salil Mehta,
Jean-Philippe Brucker, Catalin Marinas, Will Deacon, Marc Zyngier,
Hanjun Guo, Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm,
justin.he, jianyong.wu, Lorenzo Pieralisi, Sudeep Holla
In-Reply-To: <CAJZ5v0i5jpJswD7KV5RPm_HvzB+B=Rt3gY0s_Z3fn5wbJz0ebw@mail.gmail.com>
On Tue, 30 Apr 2024 12:17:38 +0200
"Rafael J. Wysocki" <rafael@kernel.org> wrote:
> On Tue, Apr 30, 2024 at 12:13 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Tue, 30 Apr 2024 10:28:38 +0100
> > Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> >
> > > On Tue, 30 Apr 2024 14:17:24 +1000
> > > Gavin Shan <gshan@redhat.com> wrote:
> > >
> > > > On 4/26/24 23:51, Jonathan Cameron wrote:
> > > > > Make the per_cpu(processors, cpu) entries available earlier so that
> > > > > they are available in arch_register_cpu() as ARM64 will need access
> > > > > to the acpi_handle to distinguish between acpi_processor_add()
> > > > > and earlier registration attempts (which will fail as _STA cannot
> > > > > be checked).
> > > > >
> > > > > Reorder the remove flow to clear this per_cpu() after
> > > > > arch_unregister_cpu() has completed, allowing it to be used in
> > > > > there as well.
> > > > >
> > > > > Note that on x86 for the CPU hotplug case, the pr->id prior to
> > > > > acpi_map_cpu() may be invalid. Thus the per_cpu() structures
> > > > > must be initialized after that call or after checking the ID
> > > > > is valid (not hotplug path).
> > > > >
> > > > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > >
> > > > > ---
> > > > > v8: On buggy bios detection when setting per_cpu structures
> > > > > do not carry on.
> > > > > Fix up the clearing of per cpu structures to remove unwanted
> > > > > side effects and ensure an error code isn't use to reference them.
> > > > > ---
> > > > > drivers/acpi/acpi_processor.c | 79 +++++++++++++++++++++--------------
> > > > > 1 file changed, 48 insertions(+), 31 deletions(-)
> > > > >
> > > > > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > > > > index ba0a6f0ac841..3b180e21f325 100644
> > > > > --- a/drivers/acpi/acpi_processor.c
> > > > > +++ b/drivers/acpi/acpi_processor.c
> > > > > @@ -183,8 +183,38 @@ static void __init acpi_pcc_cpufreq_init(void) {}
> > > > > #endif /* CONFIG_X86 */
> > > > >
> > > > > /* Initialization */
> > > > > +static DEFINE_PER_CPU(void *, processor_device_array);
> > > > > +
> > > > > +static bool acpi_processor_set_per_cpu(struct acpi_processor *pr,
> > > > > + struct acpi_device *device)
> > > > > +{
> > > > > + BUG_ON(pr->id >= nr_cpu_ids);
> > > >
> > > > One blank line after BUG_ON() if we need to follow original implementation.
> > >
> > > Sure unintentional - I'll put that back.
> > >
> > > >
> > > > > + /*
> > > > > + * Buggy BIOS check.
> > > > > + * ACPI id of processors can be reported wrongly by the BIOS.
> > > > > + * Don't trust it blindly
> > > > > + */
> > > > > + if (per_cpu(processor_device_array, pr->id) != NULL &&
> > > > > + per_cpu(processor_device_array, pr->id) != device) {
> > > > > + dev_warn(&device->dev,
> > > > > + "BIOS reported wrong ACPI id %d for the processor\n",
> > > > > + pr->id);
> > > > > + /* Give up, but do not abort the namespace scan. */
> > > >
> > > > It depends on how the return value is handled by the caller if the namespace
> > > > is continued to be scanned. The caller can be acpi_processor_hotadd_init()
> > > > and acpi_processor_get_info() after this patch is applied. So I think this
> > > > specific comment need to be moved to the caller.
> > >
> > > Good point. This gets messy and was an unintended change.
> > >
> > > Previously the options were:
> > > 1) acpi_processor_get_info() failed for other reasons - this code was never called.
> > > 2) acpi_processor_get_info() succeeded without acpi_processor_hotadd_init (non hotplug)
> > > this code then ran and would paper over the problem doing a bunch of cleanup under err.
> > > 3) acpi_processor_get_info() succeeded with acpi_processor_hotadd_init called.
> > > This code then ran and would paper over the problem doing a bunch of cleanup under err.
> > >
> > > We should maintain that or argue cleanly against it.
> > >
> > > This isn't helped the the fact I have no idea which cases we care about for that bios
> > > bug handling. Do any of those bios's ever do hotplug? Guess we have to try and maintain
> > > whatever protection this was offering.
> > >
> > > Also, the original code leaks data in some paths and I have limited idea
> > > of whether it is intentional or not. So to tidy the issue up that you've identified
> > > I'll need to try and make that code consistent first.
> > >
> > > I suspect the only way to do that is going to be to duplicate the allocations we
> > > 'want' to leak to deal with the bios bug detection.
> > >
> > > For example acpi_processor_get_info() failing leaks pr and pr->throttling.shared_cpu_map
> > > before this series. After this series we need pr to leak because it's used for the detection
> > > via processor_device_array.
> > >
> > > I'll work through this but it's going to be tricky to tell if we get right.
> > > Step 1 will be closing the existing leaks and then we will have something
> > > consistent to build on.
> > >
> > I 'think' that fixing the original leaks makes this all much more straight forward.
> > That return 0 for acpi_processor_get_info() never made sense as far as I can tell.
> > The pr isn't used after this point.
> >
> > What about something along lines of.
> >
> > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > index 161c95c9d60a..97cff4492304 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -392,8 +392,10 @@ static int acpi_processor_add(struct acpi_device *device,
> > device->driver_data = pr;
> >
> > result = acpi_processor_get_info(device);
> > - if (result) /* Processor is not physically present or unavailable */
> > - return 0;
> > + if (result) { /* Processor is not physically present or unavailable */
> > + result = 0;
>
> As per my previous message (just sent) this should be an error code,
> as returning 0 from acpi_processor_add() is generally problematic.
Ok. I'll switch to that, but as a separate precusor patch. Independent of
the memory leak fixes.
Jonathan
>
> > + goto err_free_throttling_mask;
> > + }
> >
> > BUG_ON(pr->id >= nr_cpu_ids);
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] pmdomain/cpuidle-psci: Support s2idle/s2ram on PREEMPT_RT
From: Ulf Hansson @ 2024-04-30 10:42 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Rafael J . Wysocki, Sudeep Holla, linux-pm, Lorenzo Pieralisi,
Nikunj Kela, Prasad Sodagudi, Maulik Shah, Daniel Lezcano,
Krzysztof Kozlowski, linux-rt-users, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240430094411.HyS2Gecw@linutronix.de>
On Tue, 30 Apr 2024 at 11:44, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> On 2024-04-29 16:05:25 [+0200], Ulf Hansson wrote:
> > The hierarchical PM domain topology and the corresponding domain-idle-states
> > are currently disabled on a PREEMPT_RT based configuration. The main reason is
> > because spinlocks are turned into sleepable locks on PREEMPT_RT, which means
> > genpd and runtime PM can't be use in the atomic idle-path when
> > selecting/entering an idle-state.
> >
> > For s2idle/s2ram this is an unnecessary limitation that this series intends to
> > address. Note that, the support for cpuhotplug is left to future improvements.
> > More information about this are available in the commit messages.
> >
> > I have tested this on a Dragonboard 410c.
>
> Have you tested this with PREEMPT_RT enabled and if so, which kernel?
Yes, of course. :-) I should have mentioned this in the cover-letter, sorry.
I have used the linux-rt-devel.git, which had a branch based upon
v6.8-rc7 a while ago, that I used when I did my tests.
The series needed a small rebase on top of my linux-pm tree [1],
before I could post it though. I also tested the rebased series, but
then of course then not with PREEMPT_RT, but to make sure there are no
regressions.
Kind regards
Uffe
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: rockchip: add Radxa ROCK 3C
From: Chukun Pan @ 2024-04-30 10:36 UTC (permalink / raw)
To: krzk
Cc: amadeus, conor+dt, devicetree, heiko, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, robh
In-Reply-To: <d6004beb-2e7d-4f26-a202-0c5baabd4023@kernel.org>
>> The Radxa ROCK 3C is a similar board to the
>> Radxa ROCK 3A with the Rockchip RK3566 SoC.
>> Add devicetree binding documentation for it.
> For future:
>
> Please wrap commit message according to Linux coding style / submission
> process (neither too early nor over the limit)
Should I compress these three lines into two?
> There was some big renaming of these boards. I assume you are using
> correct naming?
According to the link below, the model name is now correct:
https://lore.kernel.org/lkml/B26C732A4DCEA9B3+282b8775-601b-4d4a-a513-4924b7940076@radxa.com/
Thanks,
Chukun
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Properly clean up iommu-dma remnants
From: Dmitry Baryshkov @ 2024-04-30 10:32 UTC (permalink / raw)
To: Robin Murphy; +Cc: joro, will, catalin.marinas, linux-arm-kernel, iommu
In-Reply-To: <d4cc20cbb0c45175e98dd76bf187e2ad6421296d.1714472573.git.robin.murphy@arm.com>
On Tue, 30 Apr 2024 at 13:23, Robin Murphy <robin.murphy@arm.com> wrote:
>
> Thanks to the somewhat asymmetrical nature, while removing
> iommu_setup_dma_ops() from the arch_setup_dma_ops() flow, I managed to
> forget that arm64's teardown path was also specific to iommu-dma. Clean
> that up to match, otherwise probe deferral will lead to the arch code
> erroneously removing DMA ops set elsewhere.
>
> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Link: https://lore.kernel.org/linux-iommu/Zi_LV28TR-P-PzXi@eriador.lumag.spb.ru/
> Fixes: b67483b3c44e ("iommu/dma: Centralise iommu_setup_dma_ops()")
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> arch/arm64/Kconfig | 1 -
> arch/arm64/mm/dma-mapping.c | 8 --------
> 2 files changed, 9 deletions(-)
Thanks!
Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
--
With best wishes
Dmitry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] iommu/of: Support ats-supported device-tree property
From: Liviu Dudau @ 2024-04-30 10:23 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: will, lpieralisi, kw, robh, bhelgaas, krzk+dt, conor+dt,
sudeep.holla, joro, robin.murphy, nicolinc, ketanp, linux-pci,
linux-arm-kernel, iommu, devicetree
In-Reply-To: <20240429113938.192706-4-jean-philippe@linaro.org>
On Mon, Apr 29, 2024 at 12:39:38PM +0100, Jean-Philippe Brucker wrote:
> Device-tree declares whether a PCI root-complex supports ATS by setting
> the "ats-supported" property. Copy this flag into device fwspec to let
> IOMMU drivers quickly check if they can enable ATS for a device.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Tested-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
> ---
> drivers/iommu/of_iommu.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 3afe0b48a48db..082b94c2b3291 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -105,6 +105,14 @@ static int of_iommu_configure_device(struct device_node *master_np,
> of_iommu_configure_dev(master_np, dev);
> }
>
> +static void of_pci_check_device_ats(struct device *dev, struct device_node *np)
> +{
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> +
> + if (fwspec && of_property_read_bool(np, "ats-supported"))
> + fwspec->flags |= IOMMU_FWSPEC_PCI_RC_ATS;
> +}
> +
> /*
> * Returns:
> * 0 on success, an iommu was configured
> @@ -147,6 +155,7 @@ int of_iommu_configure(struct device *dev, struct device_node *master_np,
> pci_request_acs();
> err = pci_for_each_dma_alias(to_pci_dev(dev),
> of_pci_iommu_init, &info);
> + of_pci_check_device_ats(dev, master_np);
> } else {
> err = of_iommu_configure_device(master_np, dev, id);
> }
> --
> 2.44.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: Properly clean up iommu-dma remnants
From: Robin Murphy @ 2024-04-30 10:22 UTC (permalink / raw)
To: joro; +Cc: will, catalin.marinas, linux-arm-kernel, iommu, Dmitry Baryshkov
Thanks to the somewhat asymmetrical nature, while removing
iommu_setup_dma_ops() from the arch_setup_dma_ops() flow, I managed to
forget that arm64's teardown path was also specific to iommu-dma. Clean
that up to match, otherwise probe deferral will lead to the arch code
erroneously removing DMA ops set elsewhere.
Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/linux-iommu/Zi_LV28TR-P-PzXi@eriador.lumag.spb.ru/
Fixes: b67483b3c44e ("iommu/dma: Centralise iommu_setup_dma_ops()")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm64/Kconfig | 1 -
arch/arm64/mm/dma-mapping.c | 8 --------
2 files changed, 9 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b11c98b3e84..8fe59fb9cb35 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -46,7 +46,6 @@ config ARM64
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYSCALL_WRAPPER
- select ARCH_HAS_TEARDOWN_DMA_OPS if IOMMU_SUPPORT
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_ZONE_DMA_SET if EXPERT
select ARCH_HAVE_ELF_PROT
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 0b320a25a471..b2b5792b2caa 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -7,7 +7,6 @@
#include <linux/gfp.h>
#include <linux/cache.h>
#include <linux/dma-map-ops.h>
-#include <linux/iommu.h>
#include <xen/xen.h>
#include <asm/cacheflush.h>
@@ -39,13 +38,6 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
dcache_clean_poc(start, start + size);
}
-#ifdef CONFIG_IOMMU_DMA
-void arch_teardown_dma_ops(struct device *dev)
-{
- dev->dma_ops = NULL;
-}
-#endif
-
void arch_setup_dma_ops(struct device *dev, bool coherent)
{
int cls = cache_line_size_of_cpu();
--
2.39.2.101.g768bb238c484.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: PCI: generic: Add ats-supported property
From: Liviu Dudau @ 2024-04-30 10:22 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: will, lpieralisi, kw, robh, bhelgaas, krzk+dt, conor+dt,
sudeep.holla, joro, robin.murphy, nicolinc, ketanp, linux-pci,
linux-arm-kernel, iommu, devicetree
In-Reply-To: <20240429113938.192706-3-jean-philippe@linaro.org>
On Mon, Apr 29, 2024 at 12:39:37PM +0100, Jean-Philippe Brucker wrote:
> Add a way for firmware to tell the OS that ATS is supported by the PCI
> root complex. An endpoint with ATS enabled may send Translation Requests
> and Translated Memory Requests, which look just like Normal Memory
> Requests with a non-zero AT field. So a root controller that ignores the
> AT field may simply forward the request to the IOMMU as a Normal Memory
> Request, which could end badly. In any case, the endpoint will be
> unusable.
>
> The ats-supported property allows the OS to only enable ATS in endpoints
> if the root controller can handle ATS requests. Only add the property to
> pcie-host-ecam-generic for the moment. For non-generic root controllers,
> availability of ATS can be inferred from the compatible string.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
> ---
> From a while ago: https://lore.kernel.org/all/20200219222454.GA16221@bogus/
> ---
> Documentation/devicetree/bindings/pci/host-generic-pci.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
> index d25423aa71674..94d4a4914a483 100644
> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
> @@ -110,6 +110,12 @@ properties:
> iommu-map-mask: true
> msi-parent: true
>
> + ats-supported:
> + description:
> + Indicates that a PCIe host controller supports ATS, and can handle Memory
> + Requests with Address Type (AT).
> + type: boolean
> +
> required:
> - compatible
> - reg
> --
> 2.44.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:soc/dt] BUILD SUCCESS cc5dc7e7f93009390baa8587837741bde45c3993
From: kernel test robot @ 2024-04-30 10:22 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/dt
branch HEAD: cc5dc7e7f93009390baa8587837741bde45c3993 Merge tag 'microchip-dt64-6.10' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/dt
elapsed time: 1075m
configs tested: 146
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc haps_hs_defconfig gcc
arc randconfig-001-20240430 gcc
arc randconfig-002-20240430 gcc
arm allmodconfig gcc
arm allnoconfig clang
arm allyesconfig gcc
arm defconfig clang
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 allyesconfig clang
arm64 defconfig gcc
arm64 randconfig-002-20240430 gcc
arm64 randconfig-004-20240430 gcc
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240430 gcc
csky randconfig-002-20240430 gcc
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
i386 allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240430 gcc
i386 buildonly-randconfig-003-20240430 gcc
i386 buildonly-randconfig-006-20240430 gcc
i386 defconfig clang
i386 randconfig-002-20240430 gcc
i386 randconfig-003-20240430 gcc
i386 randconfig-004-20240430 gcc
i386 randconfig-005-20240430 gcc
i386 randconfig-006-20240430 gcc
i386 randconfig-011-20240430 gcc
i386 randconfig-014-20240430 gcc
i386 randconfig-015-20240430 gcc
i386 randconfig-016-20240430 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240430 gcc
loongarch randconfig-002-20240430 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k m5208evb_defconfig gcc
m68k sun3_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig gcc
mips allyesconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240430 gcc
nios2 randconfig-002-20240430 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240430 gcc
parisc randconfig-002-20240430 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc kmeter1_defconfig gcc
powerpc randconfig-001-20240430 gcc
powerpc randconfig-002-20240430 gcc
powerpc sam440ep_defconfig gcc
riscv allmodconfig clang
riscv allnoconfig gcc
riscv allyesconfig clang
riscv defconfig clang
riscv randconfig-001-20240430 gcc
s390 allmodconfig clang
s390 allnoconfig clang
s390 allyesconfig gcc
s390 defconfig clang
s390 randconfig-001-20240430 gcc
s390 randconfig-002-20240430 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh hp6xx_defconfig gcc
sh magicpanelr2_defconfig gcc
sh randconfig-001-20240430 gcc
sh randconfig-002-20240430 gcc
sh se7721_defconfig gcc
sh sh7710voipgw_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240430 gcc
sparc64 randconfig-002-20240430 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig gcc
um defconfig clang
um i386_defconfig gcc
um x86_64_defconfig clang
x86_64 allnoconfig clang
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-002-20240430 clang
x86_64 buildonly-randconfig-003-20240430 clang
x86_64 buildonly-randconfig-004-20240430 clang
x86_64 buildonly-randconfig-005-20240430 clang
x86_64 buildonly-randconfig-006-20240430 clang
x86_64 defconfig gcc
x86_64 randconfig-001-20240430 clang
x86_64 randconfig-002-20240430 clang
x86_64 randconfig-006-20240430 clang
x86_64 randconfig-011-20240430 clang
x86_64 randconfig-012-20240430 clang
x86_64 randconfig-014-20240430 clang
x86_64 randconfig-015-20240430 clang
x86_64 randconfig-016-20240430 clang
x86_64 randconfig-071-20240430 clang
x86_64 randconfig-072-20240430 clang
x86_64 randconfig-073-20240430 clang
x86_64 randconfig-074-20240430 clang
x86_64 randconfig-076-20240430 clang
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa allnoconfig gcc
xtensa randconfig-001-20240430 gcc
xtensa randconfig-002-20240430 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 0/2] modify Signed-off-by field
From: Paul Menzel @ 2024-04-30 10:21 UTC (permalink / raw)
To: Chia Li Hung
Cc: robh+dt, devicetree, conor+dt, linux-aspeed, openbmc,
linux-kernel, Kelly Hung, joel, krzysztof.kozlowski+dt,
Allenyy_Hsu, linux-arm-kernel
In-Reply-To: <CAK=2Bxt=WK4AdktNZDN2iXjk3ga9WRqUm9JQHoNjRnrW8hVt0Q@mail.gmail.com>
Dear Chia,
Thank you for your reply. I am sorry, this causes so much trouble.
Am 30.04.24 um 12:04 schrieb Chia Li Hung:
> Paul Menzel 於 2024年4月30日 週二 下午2:48寫道：
>> Am 30.04.24 um 06:58 schrieb Kelly Hung:
>>> For the warning message:
>>> From: Kelly Hung '<ppighouse@gmail.com>' != 'Signed-off-by: Kelly Hung <Kelly_Hung@asus.com>'
>>>
>>> I replaced Kelly_Hung@asus.com with my private Gmail account.
>>>
>>> Due to a security issue with ASUS's mail server, I am unable to use
>>> ASUS's mail system to send patches out from my build server.
>>> So I executed git send-email using my private gmail account.
>>
>> To put light on ASUS’ upstream work, using your company address would be
>> nice in my opinion. Do you have it configured everything in git
>> (`~/.gitconfig`)?
>>
>> git config --global user.name "Kelly Hung"
>> git config --global user.email Kelly_Hung@asus.com
> Below is my git configuration.
> [user]
> name = Kelly Hung
> email = Kelly_Hung@asus.com
> [sendemail]
> smtpserver = smtp.gmail.com
> smtpEncryption = tls
> smtpUser = ppighouse@gmail.com
> smtpServerPort = 587
>
> I made sure the "From" value after executing git format-patch was my ASUS
> email address.
>
> From: Kelly Hung <Kelly_Hung@asus.com>
> Date: Thu, 29 Feb 2024 16:45:02 +0800
> Subject: [PATCH v7 1/2] dt-bindings: arm: aspeed: add ASUS X4TF board
>
> Since my smtp server is Gmail, when I run send-gmail it replaces my "From"
> value with the Gmail account. I asked ASUS IT for assistance today and
> tried to get an SMTP acount.
*A thing you should know if you are using multiple email accounts with
`git send-email`* [1] says to use
git send-email --from ppighouse@gmail.com 000*.patch
Kind regards,
Paul
[1]: https://sjp38.github.io/post/git_send_email_multiple_email_caution/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 6/7] iommu/dma: Centralise iommu_setup_dma_ops()
From: Robin Murphy @ 2024-04-30 10:20 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Joerg Roedel, Christoph Hellwig, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Huacai Chen, WANG Xuerui,
Thomas Bogendoerfer, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Suravee Suthikulpanit,
David Woodhouse, Lu Baolu, Niklas Schnelle, Matthew Rosato,
Gerald Schaefer, Jean-Philippe Brucker, Rob Herring, Frank Rowand,
Marek Szyprowski, Jason Gunthorpe, linux-kernel, linux-arm-kernel,
linux-acpi, iommu, devicetree, Jason Gunthorpe
In-Reply-To: <CAA8EJprxLvYEP8+ggk8fw--kHaK+_QoYan4st2wWpPicHa6_+w@mail.gmail.com>
On 2024-04-30 1:41 am, Dmitry Baryshkov wrote:
> On Tue, 30 Apr 2024 at 01:26, Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2024-04-29 5:31 pm, Dmitry Baryshkov wrote:
>>> On Fri, Apr 19, 2024 at 05:54:45PM +0100, Robin Murphy wrote:
>>>> It's somewhat hard to see, but arm64's arch_setup_dma_ops() should only
>>>> ever call iommu_setup_dma_ops() after a successful iommu_probe_device(),
>>>> which means there should be no harm in achieving the same order of
>>>> operations by running it off the back of iommu_probe_device() itself.
>>>> This then puts it in line with the x86 and s390 .probe_finalize bodges,
>>>> letting us pull it all into the main flow properly. As a bonus this lets
>>>> us fold in and de-scope the PCI workaround setup as well.
>>>>
>>>> At this point we can also then pull the call up inside the group mutex,
>>>> and avoid having to think about whether iommu_group_store_type() could
>>>> theoretically race and free the domain if iommu_setup_dma_ops() ran just
>>>> *before* iommu_device_use_default_domain() claims it... Furthermore we
>>>> replace one .probe_finalize call completely, since the only remaining
>>>> implementations are now one which only needs to run once for the initial
>>>> boot-time probe, and two which themselves render that path unreachable.
>>>>
>>>> This leaves us a big step closer to realistically being able to unpick
>>>> the variety of different things that iommu_setup_dma_ops() has been
>>>> muddling together, and further streamline iommu-dma into core API flows
>>>> in future.
>>>>
>>>> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> # For Intel IOMMU
>>>> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
>>>> Tested-by: Hanjun Guo <guohanjun@huawei.com>
>>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>>> ---
>>>> v2: Shuffle around to make sure the iommu_group_do_probe_finalize() case
>>>> is covered as well, with bonus side-effects as above.
>>>> v3: *Really* do that, remembering the other two probe_finalize sites too.
>>>> ---
>>>> arch/arm64/mm/dma-mapping.c | 2 --
>>>> drivers/iommu/amd/iommu.c | 8 --------
>>>> drivers/iommu/dma-iommu.c | 18 ++++++------------
>>>> drivers/iommu/dma-iommu.h | 14 ++++++--------
>>>> drivers/iommu/intel/iommu.c | 7 -------
>>>> drivers/iommu/iommu.c | 20 +++++++-------------
>>>> drivers/iommu/s390-iommu.c | 6 ------
>>>> drivers/iommu/virtio-iommu.c | 10 ----------
>>>> include/linux/iommu.h | 7 -------
>>>> 9 files changed, 19 insertions(+), 73 deletions(-)
>>>
>>> This patch breaks UFS on Qualcomm SC8180X Primus platform:
>>>
>>>
>>> [ 3.846856] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x1032db3e0, fsynr=0x130000, cbfrsynra=0x300, cb=4
>>
>> Hmm, a context fault implies that the device did get attached to a DMA
>> domain, thus has successfully been through __iommu_probe_device(), yet
>> somehow still didn't get the right DMA ops (since that "IOVA" looks more
>> like a PA to me). Do you see the "Adding to IOMMU group..." message for
>> this device, and/or any other relevant messages or errors before this
>> point?
>
> No, nothing relevant.
>
> [ 8.372395] ufshcd-qcom 1d84000.ufshc: Adding to iommu group 6
>
> (please ignore the timestamp, it comes before ufshc being probed).
>
>> I'm guessing there's a fair chance probe deferral might be
>> involved as well. I'd like to understand what path(s) this ends up
>> taking through __iommu_probe_device() and of_dma_configure(), or at
>> least the number and order of probe attempts between the UFS and SMMU
>> drivers.
>
> __iommu_probe_device() gets called twice and returns early because ops is NULL.
>
> Then finally of_dma_configure_id() is called. The following branches are taken:
>
> np == dev->of_node
> of_dma_get_range() returned 0
> bus_dma_limit and dma_range_map are set
> __iommu_probe_device() is called, using the `!group->default_domain &&
> !group_lis` case, then group->default_domain() is not NULL,
> In the end, iommu_setup_dma_ops() is called.
>
> Then the ufshc probe defers (most likely the PHY is not present or
> some other device is not there yet).
Ah good, probe deferral. And indeed the half-formed hunch from last
night grew into a pretty definite idea by this morning... patch incoming.
Thanks,
Robin.
> On the next (succeeding) try, of_dma_configure_id() is called again.
> The call trace is more or less the same, except that
> __iommu_probe_device() is not called
>
>> I'll stare at the code in the morning and see if I can spot any
>> overlooked ways in which what I think might be happening could happen,
>> but any more info to help narrow it down would be much appreciated.
>>
>> Thanks,
>> Robin.
>>
>>> [ 3.846880] ufshcd-qcom 1d84000.ufshc: ufshcd_check_errors: saved_err 0x20000 saved_uic_err 0x0
>>> [ 3.846929] host_regs: 00000000: 1587031f 00000000 00000300 00000000
>>> [ 3.846935] host_regs: 00000010: 01000000 00010217 00000000 00000000
>>> [ 3.846941] host_regs: 00000020: 00000000 00070ef5 00000000 00000000
>>> [ 3.846946] host_regs: 00000030: 0000000f 00000001 00000000 00000000
>>> [ 3.846951] host_regs: 00000040: 00000000 00000000 00000000 00000000
>>> [ 3.846956] host_regs: 00000050: 032db000 00000001 00000000 00000000
>>> [ 3.846962] host_regs: 00000060: 00000000 80000000 00000000 00000000
>>> [ 3.846967] host_regs: 00000070: 032dd000 00000001 00000000 00000000
>>> [ 3.846972] host_regs: 00000080: 00000000 00000000 00000000 00000000
>>> [ 3.846977] host_regs: 00000090: 00000016 00000000 00000000 0000000c
>>> [ 3.847074] ufshcd-qcom 1d84000.ufshc: ufshcd_err_handler started; HBA state eh_fatal; powered 1; shutting down 0; saved_err = 131072; saved_uic_err = 0; force_reset = 0
>>> [ 4.406550] ufshcd-qcom 1d84000.ufshc: ufshcd_verify_dev_init: NOP OUT failed -11
>>> [ 4.417953] ufshcd-qcom 1d84000.ufshc: ufshcd_async_scan failed: -11
>>>
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/3] drm/mediatek: Add support for OF graphs
From: Alexandre Mergnat @ 2024-04-30 10:17 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, chunkuang.hu
Cc: robh, 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-1-angelogioacchino.delregno@collabora.com>
Hi Angelo,
On 09/04/2024 14:02, AngeloGioacchino Del Regno wrote:
> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
> NIO-12L with both hardcoded paths, OF graph support and partially
> hardcoded paths (meaning main display through OF graph and external
> display hardcoded, because of OVL_ADAPTOR).
Is that make sense for you to add the DTS changes of these boards into this serie ?
I asked because, IMHO, that could help to understand the serie.
--
Regards,
Alexandre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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