* Re: [PATCH 12/12] bus: fsl-mc: Add ACPI support for fsl-mc
From: Laurentiu Tudor @ 2020-05-21 15:03 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-arm-kernel
Cc: Diana Craciun, Makarand Pawagi, iommu, linux-acpi, devicetree,
linux-pci, Rob Herring, Rafael J. Wysocki, Joerg Roedel,
Hanjun Guo, Bjorn Helgaas, Sudeep Holla, Robin Murphy,
Catalin Marinas, Will Deacon, Marc Zyngier
In-Reply-To: <20200521130008.8266-13-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On 5/21/2020 4:00 PM, Lorenzo Pieralisi wrote:
> From: Diana Craciun <diana.craciun@oss.nxp.com>
>
> Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
> extract memory and other resources.
>
> Interrupt (GIC ITS) information is extracted from the MADT table
> by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
>
> IORT table is parsed to configure DMA.
>
> Signed-off-by: Makarand Pawagi <makarand.pawagi@nxp.com>
> Signed-off-by: Diana Craciun <diana.craciun@oss.nxp.com>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
The author of this patch should be Makarand. I think I accidentaly broke
it when we exchanged the patches. Very sorry about it.
---
Best Regards, Laurentiu
> drivers/bus/fsl-mc/fsl-mc-bus.c | 73 +++++++++++++++-----
> drivers/bus/fsl-mc/fsl-mc-msi.c | 37 +++++-----
> drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 75 ++++++++++++++++++++-
> 3 files changed, 150 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 824ff77bbe86..324d49d6df89 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -18,6 +18,8 @@
> #include <linux/bitops.h>
> #include <linux/msi.h>
> #include <linux/dma-mapping.h>
> +#include <linux/acpi.h>
> +#include <linux/iommu.h>
>
> #include "fsl-mc-private.h"
>
> @@ -38,6 +40,7 @@ struct fsl_mc {
> struct fsl_mc_device *root_mc_bus_dev;
> u8 num_translation_ranges;
> struct fsl_mc_addr_translation_range *translation_ranges;
> + void *fsl_mc_regs;
> };
>
> /**
> @@ -56,6 +59,10 @@ struct fsl_mc_addr_translation_range {
> phys_addr_t start_phys_addr;
> };
>
> +#define FSL_MC_FAPR 0x28
> +#define MC_FAPR_PL BIT(18)
> +#define MC_FAPR_BMT BIT(17)
> +
> /**
> * fsl_mc_bus_match - device to driver matching callback
> * @dev: the fsl-mc device to match against
> @@ -124,7 +131,10 @@ static int fsl_mc_dma_configure(struct device *dev)
> while (dev_is_fsl_mc(dma_dev))
> dma_dev = dma_dev->parent;
>
> - return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
> + if (dev_of_node(dma_dev))
> + return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
> +
> + return acpi_dma_configure_id(dev, DEV_DMA_COHERENT, &input_id);
> }
>
> static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> @@ -865,8 +875,11 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
> struct fsl_mc_io *mc_io = NULL;
> int container_id;
> phys_addr_t mc_portal_phys_addr;
> - u32 mc_portal_size;
> - struct resource res;
> + u32 mc_portal_size, mc_stream_id;
> + struct resource *plat_res;
> +
> + if (!iommu_present(&fsl_mc_bus_type))
> + return -EPROBE_DEFER;
>
> mc = devm_kzalloc(&pdev->dev, sizeof(*mc), GFP_KERNEL);
> if (!mc)
> @@ -874,19 +887,33 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, mc);
>
> + plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + mc->fsl_mc_regs = devm_ioremap_resource(&pdev->dev, plat_res);
> + if (IS_ERR(mc->fsl_mc_regs))
> + return PTR_ERR(mc->fsl_mc_regs);
> +
> + if (IS_ENABLED(CONFIG_ACPI) && !dev_of_node(&pdev->dev)) {
> + mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR);
> + /*
> + * HW ORs the PL and BMT bit, places the result in bit 15 of
> + * the StreamID and ORs in the ICID. Calculate it accordingly.
> + */
> + mc_stream_id = (mc_stream_id & 0xffff) |
> + ((mc_stream_id & (MC_FAPR_PL | MC_FAPR_BMT)) ?
> + 0x4000 : 0);
> + error = acpi_dma_configure_id(&pdev->dev, DEV_DMA_COHERENT,
> + &mc_stream_id);
> + if (error)
> + dev_warn(&pdev->dev, "failed to configure dma: %d.\n",
> + error);
> + }
> +
> /*
> * Get physical address of MC portal for the root DPRC:
> */
> - error = of_address_to_resource(pdev->dev.of_node, 0, &res);
> - if (error < 0) {
> - dev_err(&pdev->dev,
> - "of_address_to_resource() failed for %pOF\n",
> - pdev->dev.of_node);
> - return error;
> - }
> -
> - mc_portal_phys_addr = res.start;
> - mc_portal_size = resource_size(&res);
> + plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mc_portal_phys_addr = plat_res->start;
> + mc_portal_size = resource_size(plat_res);
> error = fsl_create_mc_io(&pdev->dev, mc_portal_phys_addr,
> mc_portal_size, NULL,
> FSL_MC_IO_ATOMIC_CONTEXT_PORTAL, &mc_io);
> @@ -903,11 +930,13 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
> dev_info(&pdev->dev, "MC firmware version: %u.%u.%u\n",
> mc_version.major, mc_version.minor, mc_version.revision);
>
> - error = get_mc_addr_translation_ranges(&pdev->dev,
> - &mc->translation_ranges,
> - &mc->num_translation_ranges);
> - if (error < 0)
> - goto error_cleanup_mc_io;
> + if (dev_of_node(&pdev->dev)) {
> + error = get_mc_addr_translation_ranges(&pdev->dev,
> + &mc->translation_ranges,
> + &mc->num_translation_ranges);
> + if (error < 0)
> + goto error_cleanup_mc_io;
> + }
>
> error = dprc_get_container_id(mc_io, 0, &container_id);
> if (error < 0) {
> @@ -934,6 +963,7 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
> goto error_cleanup_mc_io;
>
> mc->root_mc_bus_dev = mc_bus_dev;
> + mc_bus_dev->dev.fwnode = pdev->dev.fwnode;
> return 0;
>
> error_cleanup_mc_io:
> @@ -967,11 +997,18 @@ static const struct of_device_id fsl_mc_bus_match_table[] = {
>
> MODULE_DEVICE_TABLE(of, fsl_mc_bus_match_table);
>
> +static const struct acpi_device_id fsl_mc_bus_acpi_match_table[] = {
> + {"NXP0008", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, fsl_mc_bus_acpi_match_table);
> +
> static struct platform_driver fsl_mc_bus_driver = {
> .driver = {
> .name = "fsl_mc_bus",
> .pm = NULL,
> .of_match_table = fsl_mc_bus_match_table,
> + .acpi_match_table = fsl_mc_bus_acpi_match_table,
> },
> .probe = fsl_mc_bus_probe,
> .remove = fsl_mc_bus_remove,
> diff --git a/drivers/bus/fsl-mc/fsl-mc-msi.c b/drivers/bus/fsl-mc/fsl-mc-msi.c
> index e7bbff445a83..8edadf05cbb7 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-msi.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-msi.c
> @@ -13,6 +13,7 @@
> #include <linux/irq.h>
> #include <linux/irqdomain.h>
> #include <linux/msi.h>
> +#include <linux/acpi_iort.h>
>
> #include "fsl-mc-private.h"
>
> @@ -179,25 +180,31 @@ struct irq_domain *fsl_mc_msi_create_irq_domain(struct fwnode_handle *fwnode,
>
> struct irq_domain *fsl_mc_find_msi_domain(struct device *dev)
> {
> - struct irq_domain *msi_domain = NULL;
> + struct device *root_dprc_dev;
> + struct device *bus_dev;
> + struct irq_domain *msi_domain;
> struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
>
> - msi_domain = of_msi_map_get_device_domain(dev, mc_dev->icid,
> + fsl_mc_get_root_dprc(dev, &root_dprc_dev);
> + bus_dev = root_dprc_dev->parent;
> +
> + if (bus_dev->of_node) {
> + msi_domain = of_msi_map_get_device_domain(dev,
> + mc_dev->icid,
> DOMAIN_BUS_FSL_MC_MSI);
>
> - /*
> - * if the msi-map property is missing assume that all the
> - * child containers inherit the domain from the parent
> - */
> - if (!msi_domain) {
> - struct device *root_dprc_dev;
> - struct device *bus_dev;
> -
> - fsl_mc_get_root_dprc(dev, &root_dprc_dev);
> - bus_dev = root_dprc_dev->parent;
> - msi_domain = of_msi_get_domain(bus_dev,
> - bus_dev->of_node,
> - DOMAIN_BUS_FSL_MC_MSI);
> + /*
> + * if the msi-map property is missing assume that all the
> + * child containers inherit the domain from the parent
> + */
> + if (!msi_domain)
> +
> + msi_domain = of_msi_get_domain(bus_dev,
> + bus_dev->of_node,
> + DOMAIN_BUS_FSL_MC_MSI);
> + } else {
> + msi_domain = iort_get_device_domain(dev, mc_dev->icid,
> + DOMAIN_BUS_FSL_MC_MSI);
> }
>
> return msi_domain;
> diff --git a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> index a5c8d577e424..b8b948fb6b2d 100644
> --- a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> @@ -7,6 +7,8 @@
> *
> */
>
> +#include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
> #include <linux/of_device.h>
> #include <linux/of_address.h>
> #include <linux/irq.h>
> @@ -30,7 +32,8 @@ static u32 fsl_mc_msi_domain_get_msi_id(struct irq_domain *domain,
> u32 out_id;
>
> of_node = irq_domain_get_of_node(domain);
> - out_id = of_msi_map_id(&mc_dev->dev, of_node, mc_dev->icid);
> + out_id = of_node ? of_msi_map_id(&mc_dev->dev, of_node, mc_dev->icid) :
> + iort_msi_map_id(&mc_dev->dev, mc_dev->icid);
>
> return out_id;
> }
> @@ -79,7 +82,67 @@ static const struct of_device_id its_device_id[] = {
> {},
> };
>
> -static int __init its_fsl_mc_msi_init(void)
> +static int __init its_fsl_mc_msi_init_one(struct fwnode_handle *handle,
> + const char *name)
> +{
> + struct irq_domain *parent;
> + struct irq_domain *mc_msi_domain;
> +
> + parent = irq_find_matching_fwnode(handle, DOMAIN_BUS_NEXUS);
> + if (!parent || !msi_get_domain_info(parent)) {
> + pr_err("%s: Unable to locate ITS domain\n", name);
> + return -ENXIO;
> + }
> +
> + mc_msi_domain = fsl_mc_msi_create_irq_domain(handle,
> + &its_fsl_mc_msi_domain_info,
> + parent);
> + if (!mc_msi_domain)
> + pr_err("ACPIF: unable to create fsl-mc domain\n");
> +
> + pr_info("fsl-mc MSI: domain created\n");
> +
> + return 0;
> +}
> +
> +static int __init
> +its_fsl_mc_msi_parse_madt(union acpi_subtable_headers *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_translator *its_entry;
> + struct fwnode_handle *dom_handle;
> + const char *node_name;
> + int err = -ENXIO;
> +
> + its_entry = (struct acpi_madt_generic_translator *)header;
> + node_name = kasprintf(GFP_KERNEL, "ITS@0x%lx",
> + (long)its_entry->base_address);
> +
> + dom_handle = iort_find_domain_token(its_entry->translation_id);
> + if (!dom_handle) {
> + pr_err("%s: Unable to locate ITS domain handle\n", node_name);
> + goto out;
> + }
> +
> + err = its_fsl_mc_msi_init_one(dom_handle, node_name);
> + if (!err)
> + pr_info("fsl-mc MSI: %s domain created\n", node_name);
> +
> +out:
> + kfree(node_name);
> + return err;
> +}
> +
> +
> +static int __init its_fsl_mc_acpi_msi_init(void)
> +{
> + acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> + its_fsl_mc_msi_parse_madt, 0);
> +
> + return 0;
> +}
> +
> +static int __init its_fsl_mc_of_msi_init(void)
> {
> struct device_node *np;
> struct irq_domain *parent;
> @@ -113,4 +176,12 @@ static int __init its_fsl_mc_msi_init(void)
> return 0;
> }
>
> +static int __init its_fsl_mc_msi_init(void)
> +{
> + its_fsl_mc_of_msi_init();
> + its_fsl_mc_acpi_msi_init();
> +
> + return 0;
> +}
> +
> early_initcall(its_fsl_mc_msi_init);
>
^ permalink raw reply
* Re: [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support
From: Srinivas Kandagatla @ 2020-05-21 15:00 UTC (permalink / raw)
To: Doug Anderson
Cc: Ravi Kumar Bokka (Temp), Rob Herring, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rajendra Nayak, Sai Prakash Ranjan, dhavalp, mturney, sparate,
c_rbokka, mkurumel
In-Reply-To: <CAD=FV=UbZPQ74COXJbOikq9Wcx1UvtuMuMA+nqkx44uySoqggg@mail.gmail.com>
On 20/05/2020 23:48, Doug Anderson wrote:
>> Is this only applicable for corrected address space?
> I guess I was proposing a two dts-node / two drive approach here.
>
> dts node #1:just covers the memory range for accessing the FEC-corrected data
> driver #1: read-only and reads the FEC-corrected data
>
> dts node #2: covers the memory range that's_not_ the FEC-corrected
> memory range.
> driver #2: read-write. reading reads uncorrected data
>
> Does that seem sane?
I see your point but it does not make sense to have two node for same thing.
Isn't the raw address space reads used to for blowing and checking the
fuses if they are blown correctly or not and software usage of these
fuses should only be done from correct address space?
the read interface to user should be always from corrected address space
and write interface should be to raw address space.
--srini
>
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: spi: Add Baikal-T1 System Boot SPI Controller binding
From: Rob Herring @ 2020-05-21 14:57 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Mark Brown, Ramil Zaripov, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, John Garry,
Chuanhong Guo, Tomer Maimon, Lee Jones, Miquel Raynal,
Arnd Bergmann, open list:MIPS, linux-spi, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <20200518212703.vju456kd3telctux@mobilestation>
On Mon, May 18, 2020 at 3:27 PM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
>
> On Mon, May 18, 2020 at 09:26:59AM -0600, Rob Herring wrote:
> > On Fri, May 08, 2020 at 12:36:20PM +0300, Serge Semin wrote:
> > > Baikal-T1 Boot SPI is a part of the SoC System Controller and is
> > > responsible for the system bootup from an external SPI flash. It's a DW
> > > APB SSI-based SPI-controller with no interrupts, no DMA, with just one
> > > native chip-select available and a single reference clock. Since Baikal-T1
> > > SoC is normally booted up from an external SPI flash this SPI controller
> > > in most of the cases is supposed to be connected to a single SPI-nor
> > > flash. Additionally in order to provide a transparent from CPU point of
> > > view initial code execution procedure the system designers created an IP
> > > block which physically maps the SPI flash found at CS0 to a memory region.
> > >
> > > Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> > > Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > > Cc: Paul Burton <paulburton@kernel.org>
> > > Cc: Ralf Baechle <ralf@linux-mips.org>
> > > Cc: John Garry <john.garry@huawei.com>
> > > Cc: Chuanhong Guo <gch981213@gmail.com>
> > > Cc: Tomer Maimon <tmaimon77@gmail.com>
> > > Cc: Lee Jones <lee.jones@linaro.org>
> > > Cc: Miquel Raynal <miquel.raynal@bootlin.com>
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Cc: linux-mips@vger.kernel.org
> > > Cc: linux-spi@vger.kernel.org
> > > ---
> > > .../bindings/spi/baikal,bt1-sys-ssi.yaml | 100 ++++++++++++++++++
> > > 1 file changed, 100 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml b/Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml
> > > new file mode 100644
> > > index 000000000000..d9d3257d78f4
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/spi/baikal,bt1-sys-ssi.yaml
> > > @@ -0,0 +1,100 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/spi/baikal,bt1-sys-ssi.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Baikal-T1 System Boot SSI Controller
> > > +
> > > +description: |
> > > + Baikal-T1 System Controller includes a Boot SPI Controller, which is
> > > + responsible for loading chip bootup code from an external SPI flash. In order
> > > + to do this transparently from CPU point of view there is a dedicated IP block
> > > + mapping the 16MB flash to a dedicated MMIO range. The controller is based on
> > > + the DW APB SSI IP-core but equipped with very limited resources: no IRQ,
> > > + no DMA, a single native CS being necessarily connected to a 16MB SPI flash
> > > + (otherwise the system won't bootup from the flash), internal Tx/Rx FIFO of
> > > + just 8 bytes depth. Access to DW APB SSI controller registers is mutually
> > > + exclusive from normal MMIO interface and from physically mapped SPI Flash
> > > + memory. So either one or another way of using the controller functionality
> > > + can be enabled at a time.
> > > +
> > > +maintainers:
> > > + - Serge Semin <fancer.lancer@gmail.com>
> > > +
> > > +allOf:
> > > + - $ref: spi-controller.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + const: baikal,bt1-sys-ssi
> > > +
> > > + reg:
> > > + items:
> > > + - description: Baikal-T1 Boot Controller configuration registers
> > > + - description: Physically mapped SPI flash ROM found at CS0
> > > +
> > > + reg-names:
> > > + items:
> > > + - const: config
> > > + - const: map
> > > +
> > > + clocks:
> > > + description: SPI Controller reference clock source
> >
> > Can drop this.
>
> Ok.
>
> >
> > > + maxItems: 1
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: ssi_clk
> > > +
> > > + num-cs:
> > > + const: 1
> > > +
> > > +patternProperties:
> > > + "^.*@[0-9a-f]+":
> > > + type: object
> > > + properties:
> > > + reg:
> > > + minimum: 0
> > > + maximum: 0
> > > +
> > > + spi-rx-bus-width:
> > > + const: 1
> > > +
> > > + spi-tx-bus-width:
> > > + const: 1
> >
> > What's the point of these 2 properties if they aren't required?
>
> Yes, they are optional, but this is a constraint on the bus-width parameters.
> DW APB SSI provides a single laned Tx and Rx.
Are you just trying to keep someone from saying 'spi-tx-bus-width: 2'
for example?
You could also say 'spi-tx-bus-width: false' here to disallow the
property. I guess the above is fine.
Rob
^ permalink raw reply
* Re: [PATCH v3 01/16] spi: dw: Add Tx/Rx finish wait methods to the MID DMA
From: Feng Tang @ 2020-05-21 14:55 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Mark Brown, Grant Likely, Vinod Koul, Alan Cox,
Linus Walleij, Georgy Vlasov, Ramil Zaripov, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, Arnd Bergmann,
Andy Shevchenko, Rob Herring, linux-mips, devicetree,
Jarkko Nikula, Thomas Gleixner, Wan Ahmad Zainie, Linus Walleij,
Clement Leger, linux-spi, linux-kernel
In-Reply-To: <20200521114736.b2azyfvym372vkdl@mobilestation>
Hi Serge,
On Thu, May 21, 2020 at 02:47:36PM +0300, Serge Semin wrote:
> Hello Feng,
>
> On Thu, May 21, 2020 at 11:09:24AM +0800, Feng Tang wrote:
> > Hi Serge,
> >
> > On Thu, May 21, 2020 at 04:21:51AM +0300, Serge Semin wrote:
>
> [nip]
>
> > > /*
> > > * dws->dma_chan_busy is set before the dma transfer starts, callback for rx
> > > * channel will clear a corresponding bit.
> > > @@ -200,6 +267,8 @@ static void dw_spi_dma_rx_done(void *arg)
> > > {
> > > struct dw_spi *dws = arg;
> > >
> > > + dw_spi_dma_wait_rx_done(dws);
> >
> > I can understand the problem about TX, but I don't see how RX
> > will get hurt, can you elaborate more? thanks
> >
> > - Feng
>
> Your question is correct. You are right with your hypothesis. Ideally upon the
> dw_spi_dma_rx_done() execution Rx FIFO must be already empty. That's why the
> commit log signifies the error being mostly related with Tx FIFO. But
> practically there are many reasons why Rx FIFO might be left with data:
> DMA engine failures, incorrect DMA configuration (if DW SPI or DW DMA driver
> messed something up), controller hanging up, and so on. It's better to catch
> an error at this stage while propagating it up to the SPI device drivers.
> Especially seeing the wait-check implementation doesn't gives us much of the
> execution overhead in normal conditions. So by calling dw_spi_dma_wait_rx_done()
> we make sure that all the data has been fetched and we may freely get the
> buffers back to the client driver.
I see your point about checking RX. But I still don't think checking
RX FIFO level is the right way to detect error. Some data left in
RX FIFO doesn't always mean a error, say for some case if there is
20 words in RX FIFO, and the driver starts a DMA request for 16
words, then after a sucessful DMA transaction, there are 4 words
left without any error.
Thanks,
Feng
>
> -Sergey
^ permalink raw reply
* Re: [PATCH v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Andy Shevchenko @ 2020-05-21 14:53 UTC (permalink / raw)
To: Tali Perry
Cc: Wolfram Sang, Ofer Yehielli, Brendan Higgins, avifishman70,
Tomer Maimon, kfting, Patrick Venture, Nancy Yuen, Benjamin Fair,
Rob Herring, linux-arm-kernel, linux-i2c, OpenBMC Maillist,
devicetree, Linux Kernel Mailing List
In-Reply-To: <CAHb3i=vcVLWHjdiJoNZQrwJCqzszpOL7e9SAjqObsZCRH4ifwg@mail.gmail.com>
On Thu, May 21, 2020 at 05:45:03PM +0300, Tali Perry wrote:
> On Thu, May 21, 2020 at 5:31 PM Wolfram Sang <wsa@the-dreams.de> wrote:
> > On Thu, May 21, 2020 at 05:23:40PM +0300, Andy Shevchenko wrote:
> > > On Thu, May 21, 2020 at 02:09:09PM +0300, Tali Perry wrote:
> > > > Add Nuvoton NPCM BMC I2C controller driver.
> > >
> > > Thanks. My comments below.
> > > After addressing them, FWIW,
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > Thanks, Andy, for all the review!
> >
>
> Highly appreciate your time and patience for a newbie :)
>
> > From a glimpse, this looks good to go. I will have a close look later
> > today.
> >
> > > > +#ifdef CONFIG_DEBUG_FS
> > >
> > > Again, why is this here?
> > >
> > > Have you checked debugfs.h for !CONFIG_DEBUG_FS case?
>
> I compiled both options. I removed the ifdef in most places, except in the
> struct itself. Users that don't use the debugfs don't need this in the struct.
>
> >
> > I wondered also about DEBUG_FS entries. I can see their value when
> > developing the driver. But since this is done now, do they really help a
> > user to debug a difficult case? I am not sure, and then I wonder if we
> > should have that code in upstream. I am open for discussion, though.
>
> The user wanted to have health monitor implemented on top of the driver.
> The user has 16 channels connected the multiple devices. All are operated
> using various daemons in the system. Sometimes the slave devices are power down.
> Therefor the user wanted to track the health status of the devices.
Ah, then there are these options I have in mind (Wolfram, FYI as well!):
1) push with debugfs as a temporary solution and convert to devlink health protocol [1];
2) drop it and develop devlink_health solution;
3) push debugfs and wait if I²C will gain devlink health support
[1]: https://www.kernel.org/doc/html/latest/networking/devlink/devlink-health.html
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Tali Perry @ 2020-05-21 14:45 UTC (permalink / raw)
To: Wolfram Sang
Cc: Andy Shevchenko, Ofer Yehielli, Brendan Higgins, avifishman70,
Tomer Maimon, kfting, Patrick Venture, Nancy Yuen, Benjamin Fair,
Rob Herring, linux-arm-kernel, linux-i2c, OpenBMC Maillist,
devicetree, Linux Kernel Mailing List
In-Reply-To: <20200521143100.GA16812@ninjato>
On Thu, May 21, 2020 at 5:31 PM Wolfram Sang <wsa@the-dreams.de> wrote:
>
> Hi Tali, Andy!
>
> On Thu, May 21, 2020 at 05:23:40PM +0300, Andy Shevchenko wrote:
> > On Thu, May 21, 2020 at 02:09:09PM +0300, Tali Perry wrote:
> > > Add Nuvoton NPCM BMC I2C controller driver.
> >
> > Thanks. My comments below.
> > After addressing them, FWIW,
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Thanks, Andy, for all the review!
>
Highly appreciate your time and patience for a newbie :)
> From a glimpse, this looks good to go. I will have a close look later
> today.
>
> > > +#ifdef CONFIG_DEBUG_FS
> >
> > Again, why is this here?
> >
> > Have you checked debugfs.h for !CONFIG_DEBUG_FS case?
I compiled both options. I removed the ifdef in most places, except in the
struct itself. Users that don't use the debugfs don't need this in the struct.
>
> I wondered also about DEBUG_FS entries. I can see their value when
> developing the driver. But since this is done now, do they really help a
> user to debug a difficult case? I am not sure, and then I wonder if we
> should have that code in upstream. I am open for discussion, though.
The user wanted to have health monitor implemented on top of the driver.
The user has 16 channels connected the multiple devices. All are operated
using various daemons in the system. Sometimes the slave devices are power down.
Therefor the user wanted to track the health status of the devices.
>
> > > +MODULE_VERSION("0.1.3");
> >
> > Module version is defined by kernel commit hash. But it's up to you and
> > subsystem maintainer to decide.
>
> Please drop it. I also think commit id's (or even kernel versions) are a
> more precise description.
will remove.
>
> Regards,
>
> Wolfram
>
BR,
Tali
^ permalink raw reply
* Re: [PATCH v2] arm: dts: am33xx-bone-common: add gpio-line-names
From: Robert Nelson @ 2020-05-21 14:41 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Drew Fustini, Linus Walleij, Benoît Cousson, Tony Lindgren,
Rob Herring, Linux-OMAP, devicetree, linux kernel, Jason Kridner
In-Reply-To: <71dbf4e6-e65b-f001-319c-0b354f675568@ti.com>
> Not sure if it should be in am335x-bone-common.dtsi.
>
> For example:
> am335x-boneblack.dts
> #include "am335x-bone-common.dtsi"
> #include "am335x-boneblack-common.dtsi" <-- hdmi defined only here
Ah crap, yeah that's a good point.. So if we stick it in...
am335x-boneblack-common.dtsi
Then the Black-Wireless now has Ethernet...
am335x-boneblack-wireless.dts
#include "am335x-bone-common.dtsi"
#include "am335x-boneblack-common.dtsi"
It's going to be ugly, copy and paste mess, but i guess we might as
well stick it in the device " am335x-boneblack.dts"?
Regards,
--
Robert Nelson
https://rcn-ee.com/
^ permalink raw reply
* Re: [PATCH 04/16] arm64: dts: arm: Fix node address fields
From: Liviu Dudau @ 2020-05-21 14:40 UTC (permalink / raw)
To: Robin Murphy
Cc: Andre Przywara, Rob Herring, Sudeep Holla, Lorenzo Pieralisi,
Mark Rutland, devicetree, linux-arm-kernel
In-Reply-To: <347cdcba-a1cf-d308-1cc2-6c2194f40d19@arm.com>
On Tue, May 05, 2020 at 06:18:19PM +0100, Robin Murphy wrote:
> On 2020-05-05 5:52 pm, Andre Przywara wrote:
> > The Arm Ltd. boards were using an outdated address convention in the DT
> > node names, by separating the high from the low 32-bits of an address by
> > a comma.
>
> I thought that historically that was deliberate, since the actual thing
> being encoded is <chip select>,<address>, rather than just cosmetically
> splitting a 64-bit address value?
>
> Or maybe I'm thinking too far back and things have already changed in the
> meantime :/
Robin is right, if you look in the "ARM Motherboard Express µATX Technical
Reference Manual", in the RS1 memory map (aka "Cortex-A Series memory map")
the Ethernet for example is at CS2 offset 0x02000000. CS2 area is between
0x18000000 and 0x1c000000. So actual physical address for LAN9118 is
0x1a000000.
You might want to drop this patch or convert to physical addresses.
Best regards,
Liviu
>
> Robin.
>
> > Remove the comma from the node name suffix to be DT spec compliant.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 10 +++++-----
> > arch/arm64/boot/dts/arm/foundation-v8.dtsi | 4 ++--
> > arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 6 +++---
> > arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi | 2 +-
> > arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 6 +++---
> > 5 files changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > index 5c183483ec3b..8010cdcdb37a 100644
> > --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> > @@ -31,7 +31,7 @@
> > #interrupt-cells = <1>;
> > ranges;
> > - nor_flash: flash@0,00000000 {
> > + nor_flash: flash@0 {
> > compatible = "arm,vexpress-flash", "cfi-flash";
> > reg = <0 0x00000000 0x04000000>,
> > <4 0x00000000 0x04000000>;
> > @@ -41,13 +41,13 @@
> > };
> > };
> > - psram@1,00000000 {
> > + psram@100000000 {
> > compatible = "arm,vexpress-psram", "mtd-ram";
> > reg = <1 0x00000000 0x02000000>;
> > bank-width = <4>;
> > };
> > - ethernet@2,02000000 {
> > + ethernet@202000000 {
> > compatible = "smsc,lan9118", "smsc,lan9115";
> > reg = <2 0x02000000 0x10000>;
> > interrupts = <15>;
> > @@ -59,14 +59,14 @@
> > vddvario-supply = <&v2m_fixed_3v3>;
> > };
> > - usb@2,03000000 {
> > + usb@203000000 {
> > compatible = "nxp,usb-isp1761";
> > reg = <2 0x03000000 0x20000>;
> > interrupts = <16>;
> > port1-otg;
> > };
> > - iofpga@3,00000000 {
> > + iofpga@300000000 {
> > compatible = "simple-bus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi b/arch/arm64/boot/dts/arm/foundation-v8.dtsi
> > index 12f039fa3dad..e26b492795c5 100644
> > --- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi
> > +++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi
> > @@ -151,7 +151,7 @@
> > <0 0 41 &gic 0 0 GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
> > <0 0 42 &gic 0 0 GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
> > - ethernet@2,02000000 {
> > + ethernet@202000000 {
> > compatible = "smsc,lan91c111";
> > reg = <2 0x02000000 0x10000>;
> > interrupts = <15>;
> > @@ -178,7 +178,7 @@
> > clock-output-names = "v2m:refclk32khz";
> > };
> > - iofpga@3,00000000 {
> > + iofpga@300000000 {
> > compatible = "simple-bus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> > index e3983ded3c3c..d5cefddde08c 100644
> > --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> > +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> > @@ -103,7 +103,7 @@
> > };
> > };
> > - flash@0,00000000 {
> > + flash@0 {
> > /* 2 * 32MiB NOR Flash memory mounted on CS0 */
> > compatible = "arm,vexpress-flash", "cfi-flash";
> > reg = <0 0x00000000 0x04000000>;
> > @@ -120,7 +120,7 @@
> > };
> > };
> > - ethernet@2,00000000 {
> > + ethernet@200000000 {
> > compatible = "smsc,lan9118", "smsc,lan9115";
> > reg = <2 0x00000000 0x10000>;
> > interrupts = <3>;
> > @@ -133,7 +133,7 @@
> > vddvario-supply = <&mb_fixed_3v3>;
> > };
> > - iofpga@3,00000000 {
> > + iofpga@300000000 {
> > compatible = "simple-bus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi
> > index 60703b5763c6..350cbf17e8b4 100644
> > --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi
> > +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi
> > @@ -9,7 +9,7 @@
> > motherboard {
> > arm,v2m-memory-map = "rs2";
> > - iofpga@3,00000000 {
> > + iofpga@300000000 {
> > virtio-p9@140000 {
> > compatible = "virtio,mmio";
> > reg = <0x140000 0x200>;
> > diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > index e333c8d2d0e4..d1bfa62ca073 100644
> > --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> > @@ -17,14 +17,14 @@
> > #interrupt-cells = <1>;
> > ranges;
> > - flash@0,00000000 {
> > + flash@0 {
> > compatible = "arm,vexpress-flash", "cfi-flash";
> > reg = <0 0x00000000 0x04000000>,
> > <4 0x00000000 0x04000000>;
> > bank-width = <4>;
> > };
> > - ethernet@2,02000000 {
> > + ethernet@202000000 {
> > compatible = "smsc,lan91c111";
> > reg = <2 0x02000000 0x10000>;
> > interrupts = <15>;
> > @@ -51,7 +51,7 @@
> > clock-output-names = "v2m:refclk32khz";
> > };
> > - iofpga@3,00000000 {
> > + iofpga@300000000 {
> > compatible = "simple-bus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: nvmem: mediatek: add support for MediaTek mt8183 SoC
From: Matthias Brugger @ 2020-05-21 14:40 UTC (permalink / raw)
To: michael.mei, orz811017, Srinivas Kandagatla, Rob Herring
Cc: linux-mediatek, srv_heupstream, open list:OPEN FIRMWARE AND...,
linux-kernel@vger.kernel.org
In-Reply-To: <20190416081922.21711-3-michael.mei@mediatek.com>
[adding the corresponding maintainer]
On 16/04/2019 10:19, michael.mei@mediatek.com wrote:
> From: Michael Mei <michael.mei@mediatek.com>
>
> This updates dt-binding documentation for MediaTek mt8183
> For the both SoCs supported all rely on the fallback binding
> of the generic case with "mediatek,efuse".
>
> Signed-off-by: Michael Mei <michael.mei@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> This patch is based on v5.1-rc1 and these patches:
>
> https://patchwork.kernel.org/patch/10856987/
> https://patchwork.kernel.org/patch/10839021/
> https://patchwork.kernel.org/patch/10879015/
> https://patchwork.kernel.org/patch/10878999/
> https://patchwork.kernel.org/patch/10858941/
> https://patchwork.kernel.org/patch/10846685/
> https://patchwork.kernel.org/patch/10893519
> ---
> Documentation/devicetree/bindings/nvmem/mtk-efuse.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> index 0668c45a156d..b4d448bb60ce 100644
> --- a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> +++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> @@ -7,6 +7,7 @@ Required properties:
> "mediatek,mt7622-efuse", "mediatek,efuse": for MT7622
> "mediatek,mt7623-efuse", "mediatek,efuse": for MT7623
> "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173
> + "mediatek,mt8183-efuse" or "mediatek,efuse": for MT8183
> - reg: Should contain registers location and length
>
> = Data cells =
>
^ permalink raw reply
* Re: [PATCH v7 13/24] iommu/arm-smmu-v3: Enable broadcast TLB maintenance
From: Marc Zyngier @ 2020-05-21 14:38 UTC (permalink / raw)
To: Will Deacon
Cc: Jean-Philippe Brucker, iommu, devicetree, linux-arm-kernel,
linux-pci, linux-mm, joro, catalin.marinas, robin.murphy,
kevin.tian, baolu.lu, Jonathan.Cameron, jacob.jun.pan,
christian.koenig, felix.kuehling, zhangfei.gao, jgg, xuzaibo,
fenghua.yu, hch
In-Reply-To: <20200521141730.GJ6608@willie-the-truck>
On 2020-05-21 15:17, Will Deacon wrote:
> [+Marc]
>
> On Tue, May 19, 2020 at 07:54:51PM +0200, Jean-Philippe Brucker wrote:
>> The SMMUv3 can handle invalidation targeted at TLB entries with shared
>> ASIDs. If the implementation supports broadcast TLB maintenance,
>> enable it
>> and keep track of it in a feature bit. The SMMU will then be affected
>> by
>> inner-shareable TLB invalidations from other agents.
>>
>> A major side-effect of this change is that stage-2 translation
>> contexts
>> are now affected by all invalidations by VMID. VMIDs are all shared
>> and
>> the only ways to prevent over-invalidation, since the stage-2 page
>> tables
>> are not shared between CPU and SMMU, are to either disable BTM or
>> allocate
>> different VMIDs. This patch does not address the problem.
>
> This sounds like a potential performance issue, particularly as we
> expose
> stage-2 contexts via VFIO directly. Maybe we could reserve some portion
> of
> VMID space for the SMMU? Marc, what do you reckon?
Certainly doable when we have 16bits VMIDs. With smaller VMID spaces
(like on
v8.0), this is a bit more difficult (we do have pretty large v8.0
systems
around). How many VMID bits are we talking about?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v12 3/3] i2c: npcm7xx: Add support for slave mode for Nuvoton
From: Andy Shevchenko @ 2020-05-21 14:36 UTC (permalink / raw)
To: Tali Perry
Cc: ofery, brendanhiggins, avifishman70, tmaimon77, kfting, venture,
yuenn, benjaminfair, robh+dt, wsa, linux-arm-kernel, linux-i2c,
openbmc, devicetree, linux-kernel
In-Reply-To: <20200521110910.45518-4-tali.perry1@gmail.com>
On Thu, May 21, 2020 at 02:09:10PM +0300, Tali Perry wrote:
> Add support for slave mode for Nuvoton
> NPCM BMC I2C controller driver.
...
> +#if IS_ENABLED(CONFIG_I2C_SLAVE)
> +/*
> + * npcm_i2caddr array:
> + * The module supports having multiple own slave addresses.
> + * Since the addr regs are sprinkled all over the address space,
> + * use this array to get the address or each register.
> + */
> +#define I2C_NUM_OWN_ADDR 10
> +const int npcm_i2caddr[I2C_NUM_OWN_ADDR] = {NPCM_I2CADDR1, NPCM_I2CADDR2,
Extra spaces.
On top. please start assignment from the new line.
> + NPCM_I2CADDR3, NPCM_I2CADDR4,
> + NPCM_I2CADDR5, NPCM_I2CADDR6,
> + NPCM_I2CADDR7, NPCM_I2CADDR8,
> + NPCM_I2CADDR9, NPCM_I2CADDR10};
Split }; to new line and leave comma with the last member.
> +#endif
...
> +static int npcm_i2c_slave_enable(struct npcm_i2c *bus, enum i2c_addr addr_type,
> + u8 addr, bool enable)
Extra spaces. Check entire patch for that and fix accordingly.
> +#if IS_ENABLED(CONFIG_I2C_SLAVE)
> + if (bus->slave)
> + npcm_i2c_slave_enable(bus, I2C_SLAVE_ADDR1, bus->slave->addr,
> + true);
I would leave this on one line.
> +#endif
...
> +static void npcm_i2c_write_fifo_slave(struct npcm_i2c *bus, u16 max_bytes)
> +{
> + u8 size_free_fifo;
+ blank line.
> + /*
> + * Fill the FIFO, while the FIFO is not full and there are more bytes
> + * to write
> + */
> + npcm_i2c_clear_fifo_int(bus);
> + npcm_i2c_clear_tx_fifo(bus);
> + iowrite8(0, bus->reg + NPCM_I2CTXF_CTL);
> + size_free_fifo = I2C_HW_FIFO_SIZE - npcm_i2c_fifo_usage(bus);
Dup, move into loop.
> + while (max_bytes-- && size_free_fifo) {
> + if (bus->slv_wr_size > 0) {
> + bus->slv_wr_ind = bus->slv_wr_ind % I2C_HW_FIFO_SIZE;
> + npcm_i2c_wr_byte(bus, bus->slv_wr_buf[bus->slv_wr_ind]);
> + bus->slv_wr_ind++;
> + bus->slv_wr_ind = bus->slv_wr_ind % I2C_HW_FIFO_SIZE;
> + bus->slv_wr_size--;
> + size_free_fifo = I2C_HW_FIFO_SIZE -
> + npcm_i2c_fifo_usage(bus);
> + } else {
> + break;
> + }
> + }
while (...) {
if (...)
break;
...
}
> +}
...
> +static int npcm_i2c_slave_get_wr_buf(struct npcm_i2c *bus)
> +{
> + int i;
> + u8 value = 0;
Redundant assignment.
> + int ind;
> + int ret = bus->slv_wr_ind;
> +
> + /* fill a cyclic buffer */
> + for (i = 0; i < I2C_HW_FIFO_SIZE; i++) {
> + if (bus->slv_wr_size >= I2C_HW_FIFO_SIZE)
> + break;
> + i2c_slave_event(bus->slave, I2C_SLAVE_READ_REQUESTED, &value);
> + ind = (bus->slv_wr_ind + bus->slv_wr_size) % I2C_HW_FIFO_SIZE;
> + bus->slv_wr_buf[ind] = value;
> + bus->slv_wr_size++;
> + i2c_slave_event(bus->slave, I2C_SLAVE_READ_PROCESSED, &value);
> + }
> + return I2C_HW_FIFO_SIZE - ret;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] arm: dts: am33xx-bone-common: add gpio-line-names
From: Grygorii Strashko @ 2020-05-21 14:34 UTC (permalink / raw)
To: Drew Fustini, Linus Walleij, Benoît Cousson, Tony Lindgren,
Rob Herring, Linux-OMAP, devicetree, linux-kernel, Jason Kridner,
Robert Nelson
In-Reply-To: <20200520214757.GA362547@x1>
On 21/05/2020 00:47, Drew Fustini wrote:
> Add gpio-line-names properties to the GPIO controller nodes.
>
> BeagleBone boards have P8 and P9 headers [0] which expose many of the
> AM3358 ZCZ SoC balls to stacking expansion boards called "capes", or to
> other external connections like jumper wires connected to a breadboard.
> BeagleBone users will often refer to the "Cape Exanpsion Headers" pin
> diagram [1] as it is in the "Bone101" getting started tutorial. [2]
>
> Most of the P8 and P9 header pins can muxed to a GPIO line. The
> gpio-line-names describe which P8 or P9 pin that line goes to and the
> default mux for that P8 or P9 pin if it is not GPIO.
>
> For example, gpiochip 1 line 0 is connected to P8 header pin 25 (P8_25)
> however the default device tree has the corresponding BGA ball (ZCZ U7)
> muxed to mmc1_dat0 as it is used for the on-board eMMC chip. For that
> GPIO line to be used, one would need to modify the device tree to
> disable the eMMC and change the pin mux for that ball to GPIO mode.
>
> Some of the AM3358 ZCZ balls corresponding to GPIO lines are not routed
> to a P8 or P9 header, but are instead wired to some peripheral device
> like on-board eMMC, HDMI framer IC, or status LEDs. Those names are in
> brackets to denote those GPIO lines can not be used.
>
> Some GPIO lines are named "[NC]" as the corresponding balls are not
> routed to anything on the PCB.
>
> The goal for these names is to make it easier for a user viewing the
> output of gpioinfo to determine which P8 or P9 pin is connected to a
> GPIO line. The output of gpioinfo on a BeagleBone Black would be:
>
> debian@beaglebone:~$ gpioinfo
> gpiochip0 - 32 lines:
> line 0: "[ethernet]" unused input active-high
> line 1: "[ethernet]" unused input active-high
> line 2: "P9_22 [spi0_sclk]" unused input active-high
> line 3: "P9_21 [spi0_d0]" unused input active-high
> line 4: "P9_18 [spi0_d1]" unused input active-high
> line 5: "P9_17 [spi0_cs0]" unused input active-high
> line 6: "[sd card]" "cd" input active-low [used]
> line 7: "P9_42A [ecappwm0]" unused input active-high
> line 8: "P8_35 [hdmi]" unused input active-high
> line 9: "P8_33 [hdmi]" unused input active-high
> line 10: "P8_31 [hdmi]" unused input active-high
> line 11: "P8_32 [hdmi]" unused input active-high
[...]
>
> [0] https://git.io/JfgOd
> [1] https://beagleboard.org/capes
> [1] https://beagleboard.org/Support/bone101
> [2] https://beagleboard.org/static/images/cape-headers.png
>
> Reviewed-by: Jason Kridner <jason@beagleboard.org>
> Reviewed-by: Robert Nelson <robertcnelson@gmail.com>
> Signed-off-by: Drew Fustini <drew@beagleboard.org>
> ---
> arch/arm/boot/dts/am335x-bone-common.dtsi | 144 ++++++++++++++++++++++
Not sure if it should be in am335x-bone-common.dtsi.
For example:
am335x-boneblack.dts
#include "am335x-bone-common.dtsi"
#include "am335x-boneblack-common.dtsi" <-- hdmi defined only here
am335x-bonegreen.dts
#include "am335x-bone-common.dtsi"
#include "am335x-bonegreen-common.dtsi"
> 1 file changed, 144 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 6c9187bc0f17..d86e67b0e852 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -397,3 +397,147 @@ &rtc {
> clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
> clock-names = "ext-clk", "int-clk";
> };
> +
> +&gpio0 {
> + gpio-line-names =
> + "[ethernet]",
> + "[ethernet]",
> + "P9_22 [spi0_sclk]",
> + "P9_21 [spi0_d0]",
> + "P9_18 [spi0_d1]",
> + "P9_17 [spi0_cs0]",
> + "[sd card]",
> + "P9_42A [ecappwm0]",
> + "P8_35 [hdmi]",
> + "P8_33 [hdmi]",
> + "P8_31 [hdmi]",
> + "P8_32 [hdmi]",
[...]
--
Best regards,
grygorii
^ permalink raw reply
* Re: [PATCH v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Wolfram Sang @ 2020-05-21 14:31 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Tali Perry, ofery, brendanhiggins, avifishman70, tmaimon77,
kfting, venture, yuenn, benjaminfair, robh+dt, linux-arm-kernel,
linux-i2c, openbmc, devicetree, linux-kernel
In-Reply-To: <20200521142340.GM1634618@smile.fi.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
Hi Tali, Andy!
On Thu, May 21, 2020 at 05:23:40PM +0300, Andy Shevchenko wrote:
> On Thu, May 21, 2020 at 02:09:09PM +0300, Tali Perry wrote:
> > Add Nuvoton NPCM BMC I2C controller driver.
>
> Thanks. My comments below.
> After addressing them, FWIW,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Thanks, Andy, for all the review!
From a glimpse, this looks good to go. I will have a close look later
today.
> > +#ifdef CONFIG_DEBUG_FS
>
> Again, why is this here?
>
> Have you checked debugfs.h for !CONFIG_DEBUG_FS case?
I wondered also about DEBUG_FS entries. I can see their value when
developing the driver. But since this is done now, do they really help a
user to debug a difficult case? I am not sure, and then I wonder if we
should have that code in upstream. I am open for discussion, though.
> > +MODULE_VERSION("0.1.3");
>
> Module version is defined by kernel commit hash. But it's up to you and
> subsystem maintainer to decide.
Please drop it. I also think commit id's (or even kernel versions) are a
more precise description.
Regards,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Andy Shevchenko @ 2020-05-21 14:23 UTC (permalink / raw)
To: Tali Perry
Cc: ofery, brendanhiggins, avifishman70, tmaimon77, kfting, venture,
yuenn, benjaminfair, robh+dt, wsa, linux-arm-kernel, linux-i2c,
openbmc, devicetree, linux-kernel
In-Reply-To: <20200521110910.45518-3-tali.perry1@gmail.com>
On Thu, May 21, 2020 at 02:09:09PM +0300, Tali Perry wrote:
> Add Nuvoton NPCM BMC I2C controller driver.
Thanks. My comments below.
After addressing them, FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
...
> + /* Frequency larger than 1 MHZ is not supported */
1 MHZ -> 1MHz
...
> +#ifdef CONFIG_DEBUG_FS
Again, why is this here?
Have you checked debugfs.h for !CONFIG_DEBUG_FS case?
> +/* i2c debugfs directory: used to keep health monitor of i2c devices */
> +static struct dentry *npcm_i2c_debugfs_dir;
> +
> +static void i2c_init_debugfs(struct platform_device *pdev, struct npcm_i2c *bus)
> +{
> + struct dentry *d;
> +
> + if (!npcm_i2c_debugfs_dir)
> + return;
> +
> + d = debugfs_create_dir(dev_name(&pdev->dev), npcm_i2c_debugfs_dir);
> + if (IS_ERR_OR_NULL(d))
> + return;
> +
> + debugfs_create_u64("ber_cnt", 0444, d, &bus->ber_cnt);
> + debugfs_create_u64("nack_cnt", 0444, d, &bus->nack_cnt);
> + debugfs_create_u64("rec_succ_cnt", 0444, d, &bus->rec_succ_cnt);
> + debugfs_create_u64("rec_fail_cnt", 0444, d, &bus->rec_fail_cnt);
> + debugfs_create_u64("timeout_cnt", 0444, d, &bus->timeout_cnt);
> +
> + bus->debugfs = d;
> +}
> +#else
> +static void i2c_init_debugfs(struct platform_device *pdev, struct npcm_i2c *bus)
> +{
> +}
This is completely redundant.
> +#endif
...
> +#ifdef CONFIG_DEBUG_FS
Ditto.
> +static int __init npcm_i2c_init(void)
> +{
> + struct dentry *dir;
> +
> + dir = debugfs_create_dir("i2c", NULL);
> + if (IS_ERR_OR_NULL(dir))
> + return 0;
> +
> + npcm_i2c_debugfs_dir = dir;
> + return 0;
> +}
> +
> +static void __exit npcm_i2c_exit(void)
> +{
> + debugfs_remove_recursive(npcm_i2c_debugfs_dir);
> +}
> +
> +module_init(npcm_i2c_init);
> +module_exit(npcm_i2c_exit);
> +#endif
...
> +MODULE_VERSION("0.1.3");
Module version is defined by kernel commit hash. But it's up to you and
subsystem maintainer to decide.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 7/7] clocksource: mips-gic-timer: Mark GIC timer as unstable if ref clock changes
From: Serge Semin @ 2020-05-21 14:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Serge Semin, Thomas Gleixner, Thomas Bogendoerfer, Daniel Lezcano,
Alexey Malahov, Paul Burton, Ralf Baechle, Alessandro Zummo,
Alexandre Belloni, Arnd Bergmann, Rob Herring,
open list:BROADCOM NVRAM DRIVER, linux-rtc,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Paul Cercueil, Krzysztof Kozlowski, Geert Uytterhoeven,
Randy Dunlap, Claudiu Beznea, Maarten ter Huurne,
Vincenzo Frascino, Linux Kernel Mailing List
In-Reply-To: <CAMuHMdW5TqfDTZZCscXCK-Fkd7Gq1Ciyu1_sDzzR0B+_W-2hfg@mail.gmail.com>
On Thu, May 21, 2020 at 11:09:50AM +0200, Geert Uytterhoeven wrote:
> Hi Serge,
>
> On Thu, May 21, 2020 at 2:54 AM Serge Semin
> <Sergey.Semin@baikalelectronics.ru> wrote:
> > Currently clocksource framework doesn't support the clocks with variable
> > frequency. Since MIPS GIC timer ticks rate might be unstable on some
> > platforms, we must make sure that it justifies the clocksource
> > requirements. MIPS GIC timer is incremented with the CPU cluster reference
> > clocks rate. So in case if CPU frequency changes, the MIPS GIC tick rate
> > changes synchronously. Due to this the clocksource subsystem can't rely on
> > the timer to measure system clocks anymore. This commit marks the MIPS GIC
> > based clocksource as unstable if reference clock (normally it's a CPU
> > reference clocks) rate changes. The clocksource will execute a watchdog
> > thread, which lowers the MIPS GIC timer rating to zero and fallbacks to a
> > new stable one.
> >
> > Note we don't need to set the CLOCK_SOURCE_MUST_VERIFY flag to the MIPS
> > GIC clocksource since normally the timer is stable. The only reason why
> > it gets unstable is due to the ref clock rate change, which event we
> > detect here in the driver by means of the clocks event notifier.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> Thanks for your patch!
>
> > --- a/drivers/clocksource/mips-gic-timer.c
> > +++ b/drivers/clocksource/mips-gic-timer.c
> > @@ -24,6 +24,9 @@
> > static DEFINE_PER_CPU(struct clock_event_device, gic_clockevent_device);
> > static int gic_timer_irq;
> > static unsigned int gic_frequency;
> > +static bool __read_mostly gic_clock_unstable;
> > +
> > +static void git_clocksource_unstable(char *reason);
>
> gic_clocksource_unstable? (everywhere)
This is the most used word lately. So my hands write git everywhere by itself.)
Thanks for noticing this.
-Sergey
>
> 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
* Re: [PATCH v7 13/24] iommu/arm-smmu-v3: Enable broadcast TLB maintenance
From: Will Deacon @ 2020-05-21 14:17 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: iommu, devicetree, linux-arm-kernel, linux-pci, linux-mm, joro,
catalin.marinas, robin.murphy, kevin.tian, baolu.lu,
Jonathan.Cameron, jacob.jun.pan, christian.koenig, felix.kuehling,
zhangfei.gao, jgg, xuzaibo, fenghua.yu, hch, maz
In-Reply-To: <20200519175502.2504091-14-jean-philippe@linaro.org>
[+Marc]
On Tue, May 19, 2020 at 07:54:51PM +0200, Jean-Philippe Brucker wrote:
> The SMMUv3 can handle invalidation targeted at TLB entries with shared
> ASIDs. If the implementation supports broadcast TLB maintenance, enable it
> and keep track of it in a feature bit. The SMMU will then be affected by
> inner-shareable TLB invalidations from other agents.
>
> A major side-effect of this change is that stage-2 translation contexts
> are now affected by all invalidations by VMID. VMIDs are all shared and
> the only ways to prevent over-invalidation, since the stage-2 page tables
> are not shared between CPU and SMMU, are to either disable BTM or allocate
> different VMIDs. This patch does not address the problem.
This sounds like a potential performance issue, particularly as we expose
stage-2 contexts via VFIO directly. Maybe we could reserve some portion of
VMID space for the SMMU? Marc, what do you reckon?
Will
^ permalink raw reply
* Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: John Garry @ 2020-05-21 14:16 UTC (permalink / raw)
To: Mark Rutland, Will Deacon
Cc: Rob Herring, Joakim Zhang, shawnguo, linux-imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20200521132641.GB47848@C02TD0UTHF1T.local>
On 21/05/2020 14:26, Mark Rutland wrote:
> On Wed, May 20, 2020 at 08:33:04AM +0100, Will Deacon wrote:
>> On Tue, May 19, 2020 at 12:51:25PM -0600, Rob Herring wrote:
>>> On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
>>>> +static ssize_t ddr_perf_identifier_show(struct device *dev,
>>>> + struct device_attribute *attr,
>>>> + char *page)
>>>> +{
>>>> + struct ddr_pmu *pmu = dev_get_drvdata(dev);
>>>> +
>>>> + return sprintf(page, "%s\n", pmu->devtype_data->identifier);
>>>
>>> Why do we need yet another way to identify the SoC from userspace?
>>
>> I also really dislike this. What's the preferred way to identify the SoC
>> from userspace? It's needed so that the perf userspace tool can describe
>> perf events that are supported for the PMU, as this isn't probe-able
>> directly from the hardware. We have the same issue with the SMMUv3 PMCG [1],
>> and so we need to solve the problem for both DT and ACPI.
>
> Worth noting that while in this case it happens to identify the SoC,
> in general you can have distinct instances of system IP in a single
> system, so I do think that we need *something* instance-specific, even
> if that's combined with SoC info.
>
Hi Mark,
> Where IP gets reused across SoCs, it makes sense for that to not depend
> on top-level SoC info.
This would be quite an uncommon case. Generally most instances of a
given PMU in a SoC would be identical implementations.
And anyway, we should be able to solve that problem in perf tool, as
long as the PMU device name is fixed. Like what we have for the SMMUv3
PMU, where the device name contains the device bus address, i.e don't
use idr for perf drivers device naming....
Thanks,
John
^ permalink raw reply
* Re: [PATCH v7 00/24] iommu: Shared Virtual Addressing for SMMUv3
From: Will Deacon @ 2020-05-21 14:17 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: devicetree, kevin.tian, jacob.jun.pan, jgg, linux-pci, joro,
Jonathan.Cameron, fenghua.yu, hch, linux-mm, iommu, zhangfei.gao,
catalin.marinas, felix.kuehling, xuzaibo, robin.murphy,
christian.koenig, linux-arm-kernel, baolu.lu
In-Reply-To: <20200521103513.GE5360@willie-the-truck>
On Thu, May 21, 2020 at 11:35:14AM +0100, Will Deacon wrote:
> On Tue, May 19, 2020 at 07:54:38PM +0200, Jean-Philippe Brucker wrote:
> > Shared Virtual Addressing (SVA) allows to share process page tables with
> > devices using the IOMMU, PASIDs and I/O page faults. Add SVA support to
> > the Arm SMMUv3 driver.
> >
> > Since v6 [1]:
> > * Rename ioasid_free() to ioasid_put() in patch 02, requiring changes to
> > the Intel drivers.
> > * Use mmu_notifier_register() in patch 16 to avoid copying the ops and
> > simplify the invalidate() notifier in patch 17.
> > * As a result, replace context spinlock with a mutex. Simplified locking in
> > patch 11 (That patch still looks awful, but I think the series is more
> > readable overall). And I've finally been able to remove the GFP_ATOMIC
> > allocations.
> > * Use a single patch (04) for io-pgfault.c, since the code was simplified
> > in v6. Fixed partial list in patch 04.
>
> There's an awful lot here and it stretches across quite a few subsystems,
> with different git trees. What's the plan for merging it?
>
> I'm happy to take some of the arm64 and smmu changes for 5.8, then perhaps
> we can review what's left and target 5.9? It would also be helpful to split
> that up into separate series where there aren't strong dependencies, I
> think.
Hmm, so the way the series is structured makes it quite difficult to apply
much of this at all :(
I've taken patch 5 into the arm64 tree and patch 8 into the smmu tree. I'll
leave a couple of Acks on some of the simpler patches, but I think this
really needs splitting up a bit to make it more manageable.
I also notice a bunch of TODOs that get introduced and then removed. Given
that the series needs to be bisectable, these shouldn't be needed and can
just be removed.
Thanks,
Will
^ permalink raw reply
* Re: [PATCH v7 14/24] iommu/arm-smmu-v3: Add SVA feature checking
From: Will Deacon @ 2020-05-21 14:17 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: iommu, devicetree, linux-arm-kernel, linux-pci, linux-mm, joro,
catalin.marinas, robin.murphy, kevin.tian, baolu.lu,
Jonathan.Cameron, jacob.jun.pan, christian.koenig, felix.kuehling,
zhangfei.gao, jgg, xuzaibo, fenghua.yu, hch, Suzuki K Poulose
In-Reply-To: <20200519175502.2504091-15-jean-philippe@linaro.org>
On Tue, May 19, 2020 at 07:54:52PM +0200, Jean-Philippe Brucker wrote:
> Aggregate all sanity-checks for sharing CPU page tables with the SMMU
> under a single ARM_SMMU_FEAT_SVA bit. For PCIe SVA, users also need to
> check FEAT_ATS and FEAT_PRI. For platform SVA, they will most likely have
> to check FEAT_STALLS.
>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 72 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 9332253e3608..a9f6f1d7014e 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -660,6 +660,7 @@ struct arm_smmu_device {
> #define ARM_SMMU_FEAT_RANGE_INV (1 << 15)
> #define ARM_SMMU_FEAT_E2H (1 << 16)
> #define ARM_SMMU_FEAT_BTM (1 << 17)
> +#define ARM_SMMU_FEAT_SVA (1 << 18)
> u32 features;
>
> #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
> @@ -3935,6 +3936,74 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass)
> return 0;
> }
>
> +static bool arm_smmu_supports_sva(struct arm_smmu_device *smmu)
> +{
> + unsigned long reg, fld;
> + unsigned long oas;
> + unsigned long asid_bits;
> +
> + u32 feat_mask = ARM_SMMU_FEAT_BTM | ARM_SMMU_FEAT_COHERENCY;
Aha -- here's the coherency check I missed!
> +
> + if ((smmu->features & feat_mask) != feat_mask)
> + return false;
> +
> + if (!(smmu->pgsize_bitmap & PAGE_SIZE))
> + return false;
> +
> + /*
> + * Get the smallest PA size of all CPUs (sanitized by cpufeature). We're
> + * not even pretending to support AArch32 here.
> + */
> + reg = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
> + fld = cpuid_feature_extract_unsigned_field(reg, ID_AA64MMFR0_PARANGE_SHIFT);
> + switch (fld) {
> + case 0x0:
> + oas = 32;
> + break;
> + case 0x1:
> + oas = 36;
> + break;
> + case 0x2:
> + oas = 40;
> + break;
> + case 0x3:
> + oas = 42;
> + break;
> + case 0x4:
> + oas = 44;
> + break;
> + case 0x5:
> + oas = 48;
> + break;
> + case 0x6:
We can use ID_AA64MMFR0_PARANGE_xx constants instead of the hardcoded hex
numbers here.
With that:
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* Re: [PATCH v7 12/24] iommu/arm-smmu-v3: Add support for VHE
From: Will Deacon @ 2020-05-21 14:16 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: iommu, devicetree, linux-arm-kernel, linux-pci, linux-mm, joro,
catalin.marinas, robin.murphy, kevin.tian, baolu.lu,
Jonathan.Cameron, jacob.jun.pan, christian.koenig, felix.kuehling,
zhangfei.gao, jgg, xuzaibo, fenghua.yu, hch
In-Reply-To: <20200519175502.2504091-13-jean-philippe@linaro.org>
On Tue, May 19, 2020 at 07:54:50PM +0200, Jean-Philippe Brucker wrote:
> ARMv8.1 extensions added Virtualization Host Extensions (VHE), which allow
> to run a host kernel at EL2. When using normal DMA, Device and CPU address
> spaces are dissociated, and do not need to implement the same
> capabilities, so VHE hasn't been used in the SMMU until now.
>
> With shared address spaces however, ASIDs are shared between MMU and SMMU,
> and broadcast TLB invalidations issued by a CPU are taken into account by
> the SMMU. TLB entries on both sides need to have identical exception level
> in order to be cleared with a single invalidation.
>
> When the CPU is using VHE, enable VHE in the SMMU for all STEs. Normal DMA
> mappings will need to use TLBI_EL2 commands instead of TLBI_NH, but
> shouldn't be otherwise affected by this change.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 31 ++++++++++++++++++++++++++-----
> 1 file changed, 26 insertions(+), 5 deletions(-)
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* Re: [PATCH v7 07/24] iommu/io-pgtable-arm: Move some definitions to a header
From: Will Deacon @ 2020-05-21 14:16 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: iommu, devicetree, linux-arm-kernel, linux-pci, linux-mm, joro,
catalin.marinas, robin.murphy, kevin.tian, baolu.lu,
Jonathan.Cameron, jacob.jun.pan, christian.koenig, felix.kuehling,
zhangfei.gao, jgg, xuzaibo, fenghua.yu, hch
In-Reply-To: <20200519175502.2504091-8-jean-philippe@linaro.org>
On Tue, May 19, 2020 at 07:54:45PM +0200, Jean-Philippe Brucker wrote:
> Extract some of the most generic TCR defines, so they can be reused by
> the page table sharing code.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/iommu/io-pgtable-arm.h | 30 ++++++++++++++++++++++++++++++
> drivers/iommu/io-pgtable-arm.c | 27 ++-------------------------
> MAINTAINERS | 3 +--
> 3 files changed, 33 insertions(+), 27 deletions(-)
> create mode 100644 drivers/iommu/io-pgtable-arm.h
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* Re: [PATCH v1 2/4] arm: dts: mt7623: add display subsystem related device nodes
From: Matthias Brugger @ 2020-05-21 14:09 UTC (permalink / raw)
To: Frank Wunderlich, CK Hu, Philipp Zabel, David Airlie,
Daniel Vetter, dri-devel, linux-arm-kernel, linux-mediatek,
linux-kernel, Rob Herring, Mark Rutland, devicetree, chunhui dai,
Ryder Lee, Bibby Hsieh
In-Reply-To: <20190416145848.11932-3-frank-w@public-files.de>
Hi Frank,
On 16/04/2019 16:58, Frank Wunderlich wrote:
> From: Ryder Lee <ryder.lee@mediatek.com>
>
> Add display subsystem related device nodes for MT7623.
>
> Cc: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: chunhui dai <chunhui.dai@mediatek.com>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>
> additional fixes:
>
> [hdmi,dts] fixed dts-warnings
> author: Bibby Hsieh <bibby.hsieh@mediatek.com>
>
> [dtsi] fix dpi0-node
> author: Ryder Lee <ryder.lee@mediatek.com>
>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> Tested-by: Frank Wunderlich <frank-w@public-files.de>
> =2D--
> arch/arm/boot/dts/mt7623.dtsi | 177 ++++++++++++++++++
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 85 +++++++++
> arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 85 +++++++++
> 3 files changed, 347 insertions(+)
>
[...]
>
> + display_components: dispsys@14000000 {
> + compatible =3D "mediatek,mt7623-mmsys",
> + "mediatek,mt2701-mmsys";
> + reg =3D <0 0x14000000 0 0x1000>;
> + power-domains =3D <&scpsys MT2701_POWER_DOMAIN_DISP>;
> + };
> +
mmsys problem is fixed now, so feel free to rebase your patches on linux-next or
my for-next branch and resend.
Would love to see graphics being supported on the bananapi-r2.
Regards,
Matthias
^ permalink raw reply
* [PATCH v4 04/13] mips: Add MIPS Warrior P5600 support
From: Serge Semin @ 2020-05-21 14:07 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Serge Semin, Serge Semin, Alexey Malahov, Paul Burton,
Ralf Baechle, Arnd Bergmann, Rob Herring, devicetree, Jiaxun Yang,
Huacai Chen, Alexander Lobakin, Fangrui Song, Ard Biesheuvel,
Nathan Chancellor, Cedric Hombourger, linux-mips, linux-kernel
In-Reply-To: <20200521140725.29571-1-Sergey.Semin@baikalelectronics.ru>
This is a MIPS32 Release 5 based IP core with XPA, EVA, dual/quad issue
exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features
and system level features like up to six P5600 calculation cores, CM2
with L2 cache, IOCU/IOMMU (though might be unused depending on the
system-specific IP core configuration), GIC, CPC, virtualisation module,
eJTAG and PDtrace.
As being MIPS32 Release 5 based core it provides all the features
available by the CPU_MIPS32_R5 config, while adding a few more like
UCA attribute support, availability of CPU-freq (by means of L2/CM
clock ratio setting), EI/VI GIC modes detection at runtime.
In addition to this if P5600 architecture is enabled modern GNU GCC
provides a specific tuning for P5600 processors with respect to the
classic MIPS32 Release 5. First of all branch-likely avoidance is
activated only when the code is compiled with the speed optimization
(avoidance is always enabled for the pure MIPS32 Release 5
architecture). Secondly the madd/msub avoidance is enabled since
madd/msub utilization isn't profitable due to overhead of getting the
result out of the HI/LO registers. Multiply-accumulate instructions are
activated and utilized together with the necessary code reorder when
multiply-add/multiply-subtract statements are met. Finally load/store
bonding is activated by default. All of these optimizations may make
the code relatively faster than if just MIP32 release 5 architecture
was requested.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
---
arch/mips/Kconfig | 37 +++++++++++++++++++++++++++++-----
arch/mips/Makefile | 1 +
arch/mips/include/asm/module.h | 2 ++
3 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 9dc173ff7293..2747b1b2d435 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1618,6 +1618,28 @@ config CPU_MIPS64_R6
family, are based on a MIPS64r6 processor. If you own an older
processor, you probably need to select MIPS64r1 or MIPS64r2 instead.
+config CPU_P5600
+ bool "MIPS Warrior P5600"
+ depends on SYS_HAS_CPU_P5600
+ select CPU_HAS_PREFETCH
+ select CPU_SUPPORTS_32BIT_KERNEL
+ select CPU_SUPPORTS_HIGHMEM
+ select CPU_SUPPORTS_MSA
+ select CPU_SUPPORTS_UNCACHED_ACCELERATED
+ select CPU_SUPPORTS_CPUFREQ
+ select CPU_MIPSR2_IRQ_VI
+ select CPU_MIPSR2_IRQ_EI
+ select HAVE_KVM
+ select MIPS_O32_FP64_SUPPORT
+ help
+ Choose this option to build a kernel for MIPS Warrior P5600 CPU.
+ It's based on MIPS32r5 ISA with XPA, EVA, dual/quad issue exec pipes,
+ MMU with two-levels TLB, UCA, MSA, MDU core level features and system
+ level features like up to six P5600 calculation cores, CM2 with L2
+ cache, IOCU/IOMMU (though might be unused depending on the system-
+ specific IP core configuration), GIC, CPC, virtualisation module,
+ eJTAG and PDtrace.
+
config CPU_R3000
bool "R3000"
depends on SYS_HAS_CPU_R3000
@@ -1794,7 +1816,8 @@ endchoice
config CPU_MIPS32_3_5_FEATURES
bool "MIPS32 Release 3.5 Features"
depends on SYS_HAS_CPU_MIPS32_R3_5
- depends on CPU_MIPS32_R2 || CPU_MIPS32_R5 || CPU_MIPS32_R6
+ depends on CPU_MIPS32_R2 || CPU_MIPS32_R5 || CPU_MIPS32_R6 || \
+ CPU_P5600
help
Choose this option to build a kernel for release 2 or later of the
MIPS32 architecture including features from the 3.5 release such as
@@ -1814,7 +1837,7 @@ config CPU_MIPS32_3_5_EVA
config CPU_MIPS32_R5_FEATURES
bool "MIPS32 Release 5 Features"
depends on SYS_HAS_CPU_MIPS32_R5
- depends on CPU_MIPS32_R2 || CPU_MIPS32_R5
+ depends on CPU_MIPS32_R2 || CPU_MIPS32_R5 || CPU_P5600
help
Choose this option to build a kernel for release 2 or later of the
MIPS32 architecture including features from release 5 such as
@@ -1969,6 +1992,10 @@ config SYS_HAS_CPU_MIPS64_R6
bool
select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
+config SYS_HAS_CPU_P5600
+ bool
+ select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
+
config SYS_HAS_CPU_R3000
bool
@@ -2053,7 +2080,7 @@ endmenu
config CPU_MIPS32
bool
default y if CPU_MIPS32_R1 || CPU_MIPS32_R2 || CPU_MIPS32_R5 || \
- CPU_MIPS32_R6
+ CPU_MIPS32_R6 || CPU_P5600
config CPU_MIPS64
bool
@@ -2076,7 +2103,7 @@ config CPU_MIPSR2
config CPU_MIPSR5
bool
- default y if CPU_MIPS32_R5 || CPU_MIPS64_R5
+ default y if CPU_MIPS32_R5 || CPU_MIPS64_R5 || CPU_P5600
select CPU_HAS_RIXI
select CPU_HAS_DIEI if !CPU_DIEI_BROKEN
select MIPS_SPRAM
@@ -2689,7 +2716,7 @@ config RELOCATABLE
depends on CPU_MIPS32_R2 || CPU_MIPS64_R2 || \
CPU_MIPS32_R5 || CPU_MIPS64_R5 || \
CPU_MIPS32_R6 || CPU_MIPS64_R6 || \
- CAVIUM_OCTEON_SOC
+ CPU_P5600 || CAVIUM_OCTEON_SOC
help
This builds a kernel image that retains relocation information
so it can be loaded someplace besides the default 1MB.
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 5d7a33ae86a4..0d0f29d662c9 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -152,6 +152,7 @@ cflags-$(CONFIG_CPU_MIPS64_R1) += -march=mips64 -Wa,--trap
cflags-$(CONFIG_CPU_MIPS64_R2) += -march=mips64r2 -Wa,--trap
cflags-$(CONFIG_CPU_MIPS64_R5) += -march=mips64r5 -Wa,--trap
cflags-$(CONFIG_CPU_MIPS64_R6) += -march=mips64r6 -Wa,--trap
+cflags-$(CONFIG_CPU_P5600) += -march=p5600 -Wa,--trap -modd-spreg
cflags-$(CONFIG_CPU_R5000) += -march=r5000 -Wa,--trap
cflags-$(CONFIG_CPU_R5500) += $(call cc-option,-march=r5500,-march=r5000) \
-Wa,--trap
diff --git a/arch/mips/include/asm/module.h b/arch/mips/include/asm/module.h
index 84776e1ec8e5..7be4c68081a8 100644
--- a/arch/mips/include/asm/module.h
+++ b/arch/mips/include/asm/module.h
@@ -131,6 +131,8 @@ search_module_dbetables(unsigned long addr)
#define MODULE_PROC_FAMILY "LOONGSON64 "
#elif defined CONFIG_CPU_CAVIUM_OCTEON
#define MODULE_PROC_FAMILY "OCTEON "
+#elif defined CONFIG_CPU_P5600
+#define MODULE_PROC_FAMILY "P5600 "
#elif defined CONFIG_CPU_XLR
#define MODULE_PROC_FAMILY "XLR "
#elif defined CONFIG_CPU_XLP
--
2.25.1
^ permalink raw reply related
* [PATCH v4 03/13] mips: Add MIPS Release 5 support
From: Serge Semin @ 2020-05-21 14:07 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Serge Semin, Serge Semin, Alexey Malahov, Paul Burton,
Ralf Baechle, Arnd Bergmann, Rob Herring, devicetree, Jiaxun Yang,
Alexander Lobakin, Huacai Chen, Nathan Chancellor, Ard Biesheuvel,
Cedric Hombourger, Thomas Gleixner, Ingo Molnar,
Sebastian Andrzej Siewior, Philippe Mathieu-Daudé,
Guenter Roeck, Paul Cercueil, Zhou Yanjie, Masahiro Yamada,
Greg Kroah-Hartman, Allison Randal, Liangliang Huang,
周琰杰 (Zhou Yanjie), YunQiang Su, Zou Wei,
Oleksij Rempel, Kamal Dasu, linux-mips, linux-kernel, kvm
In-Reply-To: <20200521140725.29571-1-Sergey.Semin@baikalelectronics.ru>
There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA level updates. The rest of the MIPS architecture releases are
minor.
Even though they don't have as much ISA/system/core level changes
as the major ones with respect to the previous releases, they still
provide a set of updates (I'd say they were intended to be the
intermediate releases before a major one) that might be useful for the
kernel and user-level code, when activated by the kernel or compiler.
In particular the following features were introduced or ended up being
available at/after MIPS32/64 Release 5 architecture:
+ the last release of the misaligned memory access instructions,
+ virtualisation - VZ ASE - is optional component of the arch,
+ SIMD - MSA ASE - is optional component of the arch,
+ DSP ASE is optional component of the arch,
+ CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
must be available if FPU is implemented,
+ CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
are available.
+ UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
+ CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
accidentally clearing LL-bit when returning from an interrupt,
exception, or error trap,
+ XPA feature together with extended versions of CPx registers is
introduced, which needs to have mfhc0/mthc0 instructions available.
So due to these changes GNU GCC provides an extended instructions set
support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
though the architecture alteration isn't that big, it still worth to be
taken into account by the kernel software. Finally we can't deny that
some optimization/limitations might be found in future and implemented
on some level in kernel or compiler. In this case having even
intermediate MIPS architecture releases support would be more than
useful.
So the most of the changes provided by this commit can be split into
either compile- or runtime configs related. The compile-time related
changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
configs and concern the code activating MIPSR2 or MIPSR6 already
implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
concerns the features which are handled with respect to the MIPS ISA
revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
these fields can be used to detect either r1 or r2 or r6 releases.
But since we know which CPUs in fact support the R5 arch, we can manually
set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.
Since XPA/EVA provide too complex alterationss and to have them used with
MIPS32 Release 2 charged kernels (for compatibility with current platform
configs) they are left to be setup as a separate kernel configs.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
---
arch/mips/Kconfig | 56 +++++++++++++++++++++++++---
arch/mips/Makefile | 2 +
arch/mips/include/asm/asmmacro.h | 18 +++++----
arch/mips/include/asm/compiler.h | 5 +++
arch/mips/include/asm/cpu-features.h | 27 ++++++++++----
arch/mips/include/asm/cpu-info.h | 2 +-
arch/mips/include/asm/cpu-type.h | 7 +++-
arch/mips/include/asm/cpu.h | 10 +++--
arch/mips/include/asm/fpu.h | 4 +-
arch/mips/include/asm/hazards.h | 8 ++--
arch/mips/include/asm/module.h | 4 ++
arch/mips/include/asm/stackframe.h | 2 +-
arch/mips/include/asm/switch_to.h | 8 ++--
arch/mips/kernel/cpu-probe.c | 17 +++++++++
arch/mips/kernel/entry.S | 6 +--
arch/mips/kernel/proc.c | 4 ++
arch/mips/kernel/r4k_fpu.S | 14 +++----
arch/mips/kvm/vz.c | 6 +--
arch/mips/lib/csum_partial.S | 6 ++-
arch/mips/mm/c-r4k.c | 7 ++--
arch/mips/mm/sc-mips.c | 7 ++--
21 files changed, 163 insertions(+), 57 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index b2ff77f8366f..9dc173ff7293 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1516,6 +1516,21 @@ config CPU_MIPS32_R2
specific type of processor in your system, choose those that one
otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system.
+config CPU_MIPS32_R5
+ bool "MIPS32 Release 5"
+ depends on SYS_HAS_CPU_MIPS32_R5
+ select CPU_HAS_PREFETCH
+ select CPU_SUPPORTS_32BIT_KERNEL
+ select CPU_SUPPORTS_HIGHMEM
+ select CPU_SUPPORTS_MSA
+ select HAVE_KVM
+ select MIPS_O32_FP64_SUPPORT
+ help
+ Choose this option to build a kernel for release 5 or later of the
+ MIPS32 architecture. New MIPS processors, starting with the Warrior
+ family, are based on a MIPS32r5 processor. If you own an older
+ processor, you probably need to select MIPS32r1 or MIPS32r2 instead.
+
config CPU_MIPS32_R6
bool "MIPS32 Release 6"
depends on SYS_HAS_CPU_MIPS32_R6
@@ -1568,6 +1583,23 @@ config CPU_MIPS64_R2
specific type of processor in your system, choose those that one
otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system.
+config CPU_MIPS64_R5
+ bool "MIPS64 Release 5"
+ depends on SYS_HAS_CPU_MIPS64_R5
+ select CPU_HAS_PREFETCH
+ select CPU_SUPPORTS_32BIT_KERNEL
+ select CPU_SUPPORTS_64BIT_KERNEL
+ select CPU_SUPPORTS_HIGHMEM
+ select CPU_SUPPORTS_HUGEPAGES
+ select CPU_SUPPORTS_MSA
+ select MIPS_O32_FP64_SUPPORT if 32BIT || MIPS32_O32
+ select HAVE_KVM
+ help
+ Choose this option to build a kernel for release 5 or later of the
+ MIPS64 architecture. This is a intermediate MIPS architecture
+ release partly implementing release 6 features. Though there is no
+ any hardware known to be based on this release.
+
config CPU_MIPS64_R6
bool "MIPS64 Release 6"
depends on SYS_HAS_CPU_MIPS64_R6
@@ -1762,7 +1794,7 @@ endchoice
config CPU_MIPS32_3_5_FEATURES
bool "MIPS32 Release 3.5 Features"
depends on SYS_HAS_CPU_MIPS32_R3_5
- depends on CPU_MIPS32_R2 || CPU_MIPS32_R6
+ depends on CPU_MIPS32_R2 || CPU_MIPS32_R5 || CPU_MIPS32_R6
help
Choose this option to build a kernel for release 2 or later of the
MIPS32 architecture including features from the 3.5 release such as
@@ -1782,7 +1814,7 @@ config CPU_MIPS32_3_5_EVA
config CPU_MIPS32_R5_FEATURES
bool "MIPS32 Release 5 Features"
depends on SYS_HAS_CPU_MIPS32_R5
- depends on CPU_MIPS32_R2
+ depends on CPU_MIPS32_R2 || CPU_MIPS32_R5
help
Choose this option to build a kernel for release 2 or later of the
MIPS32 architecture including features from release 5 such as
@@ -2020,11 +2052,13 @@ endmenu
#
config CPU_MIPS32
bool
- default y if CPU_MIPS32_R1 || CPU_MIPS32_R2 || CPU_MIPS32_R6
+ default y if CPU_MIPS32_R1 || CPU_MIPS32_R2 || CPU_MIPS32_R5 || \
+ CPU_MIPS32_R6
config CPU_MIPS64
bool
- default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R6
+ default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R5 || \
+ CPU_MIPS64_R6
#
# These indicate the revision of the architecture
@@ -2040,6 +2074,13 @@ config CPU_MIPSR2
select CPU_HAS_DIEI if !CPU_DIEI_BROKEN
select MIPS_SPRAM
+config CPU_MIPSR5
+ bool
+ default y if CPU_MIPS32_R5 || CPU_MIPS64_R5
+ select CPU_HAS_RIXI
+ select CPU_HAS_DIEI if !CPU_DIEI_BROKEN
+ select MIPS_SPRAM
+
config CPU_MIPSR6
bool
default y if CPU_MIPS32_R6 || CPU_MIPS64_R6
@@ -2054,6 +2095,7 @@ config TARGET_ISA_REV
int
default 1 if CPU_MIPSR1
default 2 if CPU_MIPSR2
+ default 5 if CPU_MIPSR5
default 6 if CPU_MIPSR6
default 0
help
@@ -2643,7 +2685,11 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
config RELOCATABLE
bool "Relocatable kernel"
- depends on SYS_SUPPORTS_RELOCATABLE && (CPU_MIPS32_R2 || CPU_MIPS64_R2 || CPU_MIPS32_R6 || CPU_MIPS64_R6 || CAVIUM_OCTEON_SOC)
+ depends on SYS_SUPPORTS_RELOCATABLE
+ depends on CPU_MIPS32_R2 || CPU_MIPS64_R2 || \
+ CPU_MIPS32_R5 || CPU_MIPS64_R5 || \
+ CPU_MIPS32_R6 || CPU_MIPS64_R6 || \
+ CAVIUM_OCTEON_SOC
help
This builds a kernel image that retains relocation information
so it can be loaded someplace besides the default 1MB.
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index b50377ec3ab5..5d7a33ae86a4 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -146,9 +146,11 @@ cflags-$(CONFIG_CPU_R4X00) += -march=r4600 -Wa,--trap
cflags-$(CONFIG_CPU_TX49XX) += -march=r4600 -Wa,--trap
cflags-$(CONFIG_CPU_MIPS32_R1) += -march=mips32 -Wa,--trap
cflags-$(CONFIG_CPU_MIPS32_R2) += -march=mips32r2 -Wa,--trap
+cflags-$(CONFIG_CPU_MIPS32_R5) += -march=mips32r5 -Wa,--trap -modd-spreg
cflags-$(CONFIG_CPU_MIPS32_R6) += -march=mips32r6 -Wa,--trap -modd-spreg
cflags-$(CONFIG_CPU_MIPS64_R1) += -march=mips64 -Wa,--trap
cflags-$(CONFIG_CPU_MIPS64_R2) += -march=mips64r2 -Wa,--trap
+cflags-$(CONFIG_CPU_MIPS64_R5) += -march=mips64r5 -Wa,--trap
cflags-$(CONFIG_CPU_MIPS64_R6) += -march=mips64r6 -Wa,--trap
cflags-$(CONFIG_CPU_R5000) += -march=r5000 -Wa,--trap
cflags-$(CONFIG_CPU_R5500) += $(call cc-option,-march=r5500,-march=r5000) \
diff --git a/arch/mips/include/asm/asmmacro.h b/arch/mips/include/asm/asmmacro.h
index 655f40ddb6d1..86f2323ebe6b 100644
--- a/arch/mips/include/asm/asmmacro.h
+++ b/arch/mips/include/asm/asmmacro.h
@@ -44,7 +44,8 @@
.endm
#endif
-#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR6)
+#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR5) || \
+ defined(CONFIG_CPU_MIPSR6)
.macro local_irq_enable reg=t0
ei
irq_enable_hazard
@@ -54,7 +55,7 @@
di
irq_disable_hazard
.endm
-#else
+#else /* !CONFIG_CPU_MIPSR2 && !CONFIG_CPU_MIPSR5 && !CONFIG_CPU_MIPSR6 */
.macro local_irq_enable reg=t0
mfc0 \reg, CP0_STATUS
ori \reg, \reg, 1
@@ -79,7 +80,7 @@
sw \reg, TI_PRE_COUNT($28)
#endif
.endm
-#endif /* CONFIG_CPU_MIPSR2 */
+#endif /* !CONFIG_CPU_MIPSR2 && !CONFIG_CPU_MIPSR5 && !CONFIG_CPU_MIPSR6 */
.macro fpu_save_16even thread tmp=t0
.set push
@@ -131,7 +132,7 @@
.macro fpu_save_double thread status tmp
#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
- defined(CONFIG_CPU_MIPSR6)
+ defined(CONFIG_CPU_MIPSR5) || defined(CONFIG_CPU_MIPSR6)
sll \tmp, \status, 5
bgez \tmp, 10f
fpu_save_16odd \thread
@@ -190,7 +191,7 @@
.macro fpu_restore_double thread status tmp
#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
- defined(CONFIG_CPU_MIPSR6)
+ defined(CONFIG_CPU_MIPSR5) || defined(CONFIG_CPU_MIPSR6)
sll \tmp, \status, 5
bgez \tmp, 10f # 16 register mode?
@@ -200,16 +201,17 @@
fpu_restore_16even \thread \tmp
.endm
-#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR6)
+#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR5) || \
+ defined(CONFIG_CPU_MIPSR6)
.macro _EXT rd, rs, p, s
ext \rd, \rs, \p, \s
.endm
-#else /* !CONFIG_CPU_MIPSR2 || !CONFIG_CPU_MIPSR6 */
+#else /* !CONFIG_CPU_MIPSR2 && !CONFIG_CPU_MIPSR5 && !CONFIG_CPU_MIPSR6 */
.macro _EXT rd, rs, p, s
srl \rd, \rs, \p
andi \rd, \rd, (1 << \s) - 1
.endm
-#endif /* !CONFIG_CPU_MIPSR2 || !CONFIG_CPU_MIPSR6 */
+#endif /* !CONFIG_CPU_MIPSR2 && !CONFIG_CPU_MIPSR5 && !CONFIG_CPU_MIPSR6 */
/*
* Temporary until all gas have MT ASE support
diff --git a/arch/mips/include/asm/compiler.h b/arch/mips/include/asm/compiler.h
index f77e99f1722e..a2cb2d2b1c07 100644
--- a/arch/mips/include/asm/compiler.h
+++ b/arch/mips/include/asm/compiler.h
@@ -57,6 +57,11 @@
#define MIPS_ISA_ARCH_LEVEL MIPS_ISA_LEVEL
#define MIPS_ISA_LEVEL_RAW mips64r6
#define MIPS_ISA_ARCH_LEVEL_RAW MIPS_ISA_LEVEL_RAW
+#elif defined(CONFIG_CPU_MIPSR5)
+#define MIPS_ISA_LEVEL "mips64r5"
+#define MIPS_ISA_ARCH_LEVEL MIPS_ISA_LEVEL
+#define MIPS_ISA_LEVEL_RAW mips64r5
+#define MIPS_ISA_ARCH_LEVEL_RAW MIPS_ISA_LEVEL_RAW
#else
/* MIPS64 is a superset of MIPS32 */
#define MIPS_ISA_LEVEL "mips64r2"
diff --git a/arch/mips/include/asm/cpu-features.h b/arch/mips/include/asm/cpu-features.h
index 400b123cb6da..227d7416591c 100644
--- a/arch/mips/include/asm/cpu-features.h
+++ b/arch/mips/include/asm/cpu-features.h
@@ -284,6 +284,9 @@
#ifndef cpu_has_mips32r2
# define cpu_has_mips32r2 __isa_range_or_flag(2, 6, MIPS_CPU_ISA_M32R2)
#endif
+#ifndef cpu_has_mips32r5
+# define cpu_has_mips32r5 __isa_range_or_flag(5, 6, MIPS_CPU_ISA_M32R5)
+#endif
#ifndef cpu_has_mips32r6
# define cpu_has_mips32r6 __isa_ge_or_flag(6, MIPS_CPU_ISA_M32R6)
#endif
@@ -293,6 +296,10 @@
#ifndef cpu_has_mips64r2
# define cpu_has_mips64r2 __isa_range_or_flag(2, 6, MIPS_CPU_ISA_M64R2)
#endif
+#ifndef cpu_has_mips64r5
+# define cpu_has_mips64r5 (cpu_has_64bits && \
+ __isa_range_or_flag(5, 6, MIPS_CPU_ISA_M64R5))
+#endif
#ifndef cpu_has_mips64r6
# define cpu_has_mips64r6 __isa_ge_and_flag(6, MIPS_CPU_ISA_M64R6)
#endif
@@ -313,19 +320,25 @@
(cpu_has_mips_3 | cpu_has_mips_4_5_64_r2_r6)
#define cpu_has_mips_4_5_64_r2_r6 \
(cpu_has_mips_4_5 | cpu_has_mips64r1 | \
- cpu_has_mips_r2 | cpu_has_mips_r6)
+ cpu_has_mips_r2 | cpu_has_mips_r5 | \
+ cpu_has_mips_r6)
-#define cpu_has_mips32 (cpu_has_mips32r1 | cpu_has_mips32r2 | cpu_has_mips32r6)
-#define cpu_has_mips64 (cpu_has_mips64r1 | cpu_has_mips64r2 | cpu_has_mips64r6)
+#define cpu_has_mips32 (cpu_has_mips32r1 | cpu_has_mips32r2 | \
+ cpu_has_mips32r5 | cpu_has_mips32r6)
+#define cpu_has_mips64 (cpu_has_mips64r1 | cpu_has_mips64r2 | \
+ cpu_has_mips64r5 | cpu_has_mips64r6)
#define cpu_has_mips_r1 (cpu_has_mips32r1 | cpu_has_mips64r1)
#define cpu_has_mips_r2 (cpu_has_mips32r2 | cpu_has_mips64r2)
+#define cpu_has_mips_r5 (cpu_has_mips32r5 | cpu_has_mips64r5)
#define cpu_has_mips_r6 (cpu_has_mips32r6 | cpu_has_mips64r6)
#define cpu_has_mips_r (cpu_has_mips32r1 | cpu_has_mips32r2 | \
- cpu_has_mips32r6 | cpu_has_mips64r1 | \
- cpu_has_mips64r2 | cpu_has_mips64r6)
+ cpu_has_mips32r5 | cpu_has_mips32r6 | \
+ cpu_has_mips64r1 | cpu_has_mips64r2 | \
+ cpu_has_mips64r5 | cpu_has_mips64r6)
-/* MIPSR2 and MIPSR6 have a lot of similarities */
-#define cpu_has_mips_r2_r6 (cpu_has_mips_r2 | cpu_has_mips_r6)
+/* MIPSR2 - MIPSR6 have a lot of similarities */
+#define cpu_has_mips_r2_r6 (cpu_has_mips_r2 | cpu_has_mips_r5 | \
+ cpu_has_mips_r6)
/*
* cpu_has_mips_r2_exec_hazard - return if IHB is required on current processor
diff --git a/arch/mips/include/asm/cpu-info.h b/arch/mips/include/asm/cpu-info.h
index ed7ffe4e63a3..bce3ea7fff7c 100644
--- a/arch/mips/include/asm/cpu-info.h
+++ b/arch/mips/include/asm/cpu-info.h
@@ -142,7 +142,7 @@ struct proc_cpuinfo_notifier_args {
static inline unsigned int cpu_cluster(struct cpuinfo_mips *cpuinfo)
{
/* Optimisation for systems where multiple clusters aren't used */
- if (!IS_ENABLED(CONFIG_CPU_MIPSR6))
+ if (!IS_ENABLED(CONFIG_CPU_MIPSR5) && !IS_ENABLED(CONFIG_CPU_MIPSR6))
return 0;
return (cpuinfo->globalnumber & MIPS_GLOBALNUMBER_CLUSTER) >>
diff --git a/arch/mips/include/asm/cpu-type.h b/arch/mips/include/asm/cpu-type.h
index 49f0061a6051..75a7a382da09 100644
--- a/arch/mips/include/asm/cpu-type.h
+++ b/arch/mips/include/asm/cpu-type.h
@@ -51,13 +51,18 @@ static inline int __pure __get_cpu_type(const int cpu_type)
case CPU_M14KEC:
case CPU_INTERAPTIV:
case CPU_PROAPTIV:
- case CPU_P5600:
+#endif
+
+#ifdef CONFIG_SYS_HAS_CPU_MIPS32_R5
case CPU_M5150:
+ case CPU_P5600:
#endif
#if defined(CONFIG_SYS_HAS_CPU_MIPS32_R2) || \
+ defined(CONFIG_SYS_HAS_CPU_MIPS32_R5) || \
defined(CONFIG_SYS_HAS_CPU_MIPS32_R6) || \
defined(CONFIG_SYS_HAS_CPU_MIPS64_R2) || \
+ defined(CONFIG_SYS_HAS_CPU_MIPS64_R5) || \
defined(CONFIG_SYS_HAS_CPU_MIPS64_R6)
case CPU_QEMU_GENERIC:
#endif
diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index 46c190e78acf..4b84fd1df0c7 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -347,14 +347,16 @@ enum cpu_type_enum {
#define MIPS_CPU_ISA_M32R2 0x00000020
#define MIPS_CPU_ISA_M64R1 0x00000040
#define MIPS_CPU_ISA_M64R2 0x00000080
-#define MIPS_CPU_ISA_M32R6 0x00000100
-#define MIPS_CPU_ISA_M64R6 0x00000200
+#define MIPS_CPU_ISA_M32R5 0x00000100
+#define MIPS_CPU_ISA_M64R5 0x00000200
+#define MIPS_CPU_ISA_M32R6 0x00000400
+#define MIPS_CPU_ISA_M64R6 0x00000800
#define MIPS_CPU_ISA_32BIT (MIPS_CPU_ISA_II | MIPS_CPU_ISA_M32R1 | \
- MIPS_CPU_ISA_M32R2 | MIPS_CPU_ISA_M32R6)
+ MIPS_CPU_ISA_M32R2 | MIPS_CPU_ISA_M32R5 | MIPS_CPU_ISA_M32R6)
#define MIPS_CPU_ISA_64BIT (MIPS_CPU_ISA_III | MIPS_CPU_ISA_IV | \
MIPS_CPU_ISA_V | MIPS_CPU_ISA_M64R1 | MIPS_CPU_ISA_M64R2 | \
- MIPS_CPU_ISA_M64R6)
+ MIPS_CPU_ISA_M64R5 | MIPS_CPU_ISA_M64R6)
/*
* CPU Option encodings
diff --git a/arch/mips/include/asm/fpu.h b/arch/mips/include/asm/fpu.h
index a9d5123e2a2a..08f9dd6903b7 100644
--- a/arch/mips/include/asm/fpu.h
+++ b/arch/mips/include/asm/fpu.h
@@ -71,8 +71,8 @@ static inline int __enable_fpu(enum fpu_mode mode)
goto fr_common;
case FPU_64BIT:
-#if !(defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR6) \
- || defined(CONFIG_64BIT))
+#if !(defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR5) || \
+ defined(CONFIG_CPU_MIPSR6) || defined(CONFIG_64BIT))
/* we only have a 32-bit FPU */
return SIGFPE;
#endif
diff --git a/arch/mips/include/asm/hazards.h b/arch/mips/include/asm/hazards.h
index a0b92205f933..f855478d12fa 100644
--- a/arch/mips/include/asm/hazards.h
+++ b/arch/mips/include/asm/hazards.h
@@ -22,8 +22,9 @@
/*
* TLB hazards
*/
-#if (defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR6)) && \
- !defined(CONFIG_CPU_CAVIUM_OCTEON) && !defined(CONFIG_CPU_LOONGSON64)
+#if (defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR5) || \
+ defined(CONFIG_CPU_MIPSR6)) && \
+ !defined(CONFIG_CPU_CAVIUM_OCTEON) && !defined(CONFIG_CPU_LOONGSON64)
/*
* MIPSR2 defines ehb for hazard avoidance
@@ -278,7 +279,8 @@ do { \
#define __disable_fpu_hazard
-#elif defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR6)
+#elif defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR5) || \
+ defined(CONFIG_CPU_MIPSR6)
#define __enable_fpu_hazard \
___ehb
diff --git a/arch/mips/include/asm/module.h b/arch/mips/include/asm/module.h
index 9846047b3d3d..84776e1ec8e5 100644
--- a/arch/mips/include/asm/module.h
+++ b/arch/mips/include/asm/module.h
@@ -89,12 +89,16 @@ search_module_dbetables(unsigned long addr)
#define MODULE_PROC_FAMILY "MIPS32_R1 "
#elif defined CONFIG_CPU_MIPS32_R2
#define MODULE_PROC_FAMILY "MIPS32_R2 "
+#elif defined CONFIG_CPU_MIPS32_R5
+#define MODULE_PROC_FAMILY "MIPS32_R5 "
#elif defined CONFIG_CPU_MIPS32_R6
#define MODULE_PROC_FAMILY "MIPS32_R6 "
#elif defined CONFIG_CPU_MIPS64_R1
#define MODULE_PROC_FAMILY "MIPS64_R1 "
#elif defined CONFIG_CPU_MIPS64_R2
#define MODULE_PROC_FAMILY "MIPS64_R2 "
+#elif defined CONFIG_CPU_MIPS64_R5
+#define MODULE_PROC_FAMILY "MIPS64_R5 "
#elif defined CONFIG_CPU_MIPS64_R6
#define MODULE_PROC_FAMILY "MIPS64_R6 "
#elif defined CONFIG_CPU_R3000
diff --git a/arch/mips/include/asm/stackframe.h b/arch/mips/include/asm/stackframe.h
index 4d6ad907ae54..3e8d2aaf96af 100644
--- a/arch/mips/include/asm/stackframe.h
+++ b/arch/mips/include/asm/stackframe.h
@@ -424,7 +424,7 @@
.macro RESTORE_SP_AND_RET docfi=0
RESTORE_SP \docfi
-#ifdef CONFIG_CPU_MIPSR6
+#if defined(CONFIG_CPU_MIPSR5) || defined(CONFIG_CPU_MIPSR6)
eretnc
#else
.set push
diff --git a/arch/mips/include/asm/switch_to.h b/arch/mips/include/asm/switch_to.h
index 09cbe9042828..0b0a93bf83cd 100644
--- a/arch/mips/include/asm/switch_to.h
+++ b/arch/mips/include/asm/switch_to.h
@@ -67,11 +67,11 @@ do { \
#endif
/*
- * Clear LLBit during context switches on MIPSr6 such that eretnc can be used
+ * Clear LLBit during context switches on MIPSr5+ such that eretnc can be used
* unconditionally when returning to userland in entry.S.
*/
-#define __clear_r6_hw_ll_bit() do { \
- if (cpu_has_mips_r6) \
+#define __clear_r5_hw_ll_bit() do { \
+ if (cpu_has_mips_r5 || cpu_has_mips_r6) \
write_c0_lladdr(0); \
} while (0)
@@ -129,7 +129,7 @@ do { \
} \
clear_c0_status(ST0_CU2); \
} \
- __clear_r6_hw_ll_bit(); \
+ __clear_r5_hw_ll_bit(); \
__clear_software_ll_bit(); \
if (cpu_has_userlocal) \
write_c0_userlocal(task_thread_info(next)->tp_value); \
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index a0ef21b2d8b3..33600287daf7 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -92,6 +92,7 @@ static void cpu_set_fpu_2008(struct cpuinfo_mips *c)
{
if (c->isa_level & (MIPS_CPU_ISA_M32R1 | MIPS_CPU_ISA_M64R1 |
MIPS_CPU_ISA_M32R2 | MIPS_CPU_ISA_M64R2 |
+ MIPS_CPU_ISA_M32R5 | MIPS_CPU_ISA_M64R5 |
MIPS_CPU_ISA_M32R6 | MIPS_CPU_ISA_M64R6)) {
unsigned long sr, fir, fcsr, fcsr0, fcsr1;
@@ -172,6 +173,7 @@ static void cpu_set_nofpu_2008(struct cpuinfo_mips *c)
case STRICT:
if (c->isa_level & (MIPS_CPU_ISA_M32R1 | MIPS_CPU_ISA_M64R1 |
MIPS_CPU_ISA_M32R2 | MIPS_CPU_ISA_M64R2 |
+ MIPS_CPU_ISA_M32R5 | MIPS_CPU_ISA_M64R5 |
MIPS_CPU_ISA_M32R6 | MIPS_CPU_ISA_M64R6)) {
c->options |= MIPS_CPU_NAN_2008 | MIPS_CPU_NAN_LEGACY;
} else {
@@ -263,9 +265,11 @@ static void cpu_set_nofpu_id(struct cpuinfo_mips *c)
value = 0;
if (c->isa_level & (MIPS_CPU_ISA_M32R1 | MIPS_CPU_ISA_M64R1 |
MIPS_CPU_ISA_M32R2 | MIPS_CPU_ISA_M64R2 |
+ MIPS_CPU_ISA_M32R5 | MIPS_CPU_ISA_M64R5 |
MIPS_CPU_ISA_M32R6 | MIPS_CPU_ISA_M64R6))
value |= MIPS_FPIR_D | MIPS_FPIR_S;
if (c->isa_level & (MIPS_CPU_ISA_M32R2 | MIPS_CPU_ISA_M64R2 |
+ MIPS_CPU_ISA_M32R5 | MIPS_CPU_ISA_M64R5 |
MIPS_CPU_ISA_M32R6 | MIPS_CPU_ISA_M64R6))
value |= MIPS_FPIR_F64 | MIPS_FPIR_L | MIPS_FPIR_W;
if (c->options & MIPS_CPU_NAN_2008)
@@ -286,6 +290,7 @@ static void cpu_set_fpu_opts(struct cpuinfo_mips *c)
if (c->isa_level & (MIPS_CPU_ISA_M32R1 | MIPS_CPU_ISA_M64R1 |
MIPS_CPU_ISA_M32R2 | MIPS_CPU_ISA_M64R2 |
+ MIPS_CPU_ISA_M32R5 | MIPS_CPU_ISA_M64R5 |
MIPS_CPU_ISA_M32R6 | MIPS_CPU_ISA_M64R6)) {
if (c->fpu_id & MIPS_FPIR_3D)
c->ases |= MIPS_ASE_MIPS3D;
@@ -532,6 +537,10 @@ static inline void cpu_probe_vmbits(struct cpuinfo_mips *c)
static void set_isa(struct cpuinfo_mips *c, unsigned int isa)
{
switch (isa) {
+ case MIPS_CPU_ISA_M64R5:
+ c->isa_level |= MIPS_CPU_ISA_M32R5 | MIPS_CPU_ISA_M64R5;
+ set_elf_base_platform("mips64r5");
+ /* fall through */
case MIPS_CPU_ISA_M64R2:
c->isa_level |= MIPS_CPU_ISA_M32R2 | MIPS_CPU_ISA_M64R2;
set_elf_base_platform("mips64r2");
@@ -563,6 +572,10 @@ static void set_isa(struct cpuinfo_mips *c, unsigned int isa)
set_elf_base_platform("mips32r6");
/* Break here so we don't add incompatible ISAs */
break;
+ case MIPS_CPU_ISA_M32R5:
+ c->isa_level |= MIPS_CPU_ISA_M32R5;
+ set_elf_base_platform("mips32r5");
+ /* fall through */
case MIPS_CPU_ISA_M32R2:
c->isa_level |= MIPS_CPU_ISA_M32R2;
set_elf_base_platform("mips32r2");
@@ -1751,6 +1764,10 @@ static inline void cpu_probe_mips(struct cpuinfo_mips *c, unsigned int cpu)
spram_config();
switch (__get_cpu_type(c->cputype)) {
+ case CPU_M5150:
+ case CPU_P5600:
+ set_isa(c, MIPS_CPU_ISA_M32R5);
+ break;
case CPU_I6500:
c->options |= MIPS_CPU_SHARED_FTLB_ENTRIES;
fallthrough;
diff --git a/arch/mips/kernel/entry.S b/arch/mips/kernel/entry.S
index 4849a48afc0f..4b896f5023ff 100644
--- a/arch/mips/kernel/entry.S
+++ b/arch/mips/kernel/entry.S
@@ -169,8 +169,8 @@ syscall_exit_work:
jal syscall_trace_leave
b resume_userspace
-#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR6) || \
- defined(CONFIG_MIPS_MT)
+#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR5) || \
+ defined(CONFIG_CPU_MIPSR6) || defined(CONFIG_MIPS_MT)
/*
* MIPS32R2 Instruction Hazard Barrier - must be called
@@ -183,4 +183,4 @@ LEAF(mips_ihb)
nop
END(mips_ihb)
-#endif /* CONFIG_CPU_MIPSR2 or CONFIG_CPU_MIPSR6 or CONFIG_MIPS_MT */
+#endif /* CONFIG_CPU_MIPSR2 - CONFIG_CPU_MIPSR6 or CONFIG_MIPS_MT */
diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c
index f8d36710cd58..4184d641f05e 100644
--- a/arch/mips/kernel/proc.c
+++ b/arch/mips/kernel/proc.c
@@ -98,12 +98,16 @@ static int show_cpuinfo(struct seq_file *m, void *v)
seq_printf(m, "%s", " mips32r1");
if (cpu_has_mips32r2)
seq_printf(m, "%s", " mips32r2");
+ if (cpu_has_mips32r5)
+ seq_printf(m, "%s", " mips32r5");
if (cpu_has_mips32r6)
seq_printf(m, "%s", " mips32r6");
if (cpu_has_mips64r1)
seq_printf(m, "%s", " mips64r1");
if (cpu_has_mips64r2)
seq_printf(m, "%s", " mips64r2");
+ if (cpu_has_mips64r5)
+ seq_printf(m, "%s", " mips64r5");
if (cpu_has_mips64r6)
seq_printf(m, "%s", " mips64r6");
seq_printf(m, "\n");
diff --git a/arch/mips/kernel/r4k_fpu.S b/arch/mips/kernel/r4k_fpu.S
index 59be5c812aa2..b91e91106475 100644
--- a/arch/mips/kernel/r4k_fpu.S
+++ b/arch/mips/kernel/r4k_fpu.S
@@ -41,7 +41,7 @@
LEAF(_save_fp)
EXPORT_SYMBOL(_save_fp)
#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
- defined(CONFIG_CPU_MIPSR6)
+ defined(CONFIG_CPU_MIPSR5) || defined(CONFIG_CPU_MIPSR6)
mfc0 t0, CP0_STATUS
#endif
fpu_save_double a0 t0 t1 # clobbers t1
@@ -53,7 +53,7 @@ EXPORT_SYMBOL(_save_fp)
*/
LEAF(_restore_fp)
#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
- defined(CONFIG_CPU_MIPSR6)
+ defined(CONFIG_CPU_MIPSR5) || defined(CONFIG_CPU_MIPSR6)
mfc0 t0, CP0_STATUS
#endif
fpu_restore_double a0 t0 t1 # clobbers t1
@@ -103,10 +103,10 @@ LEAF(_save_fp_context)
.set pop
#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
- defined(CONFIG_CPU_MIPSR6)
+ defined(CONFIG_CPU_MIPSR5) || defined(CONFIG_CPU_MIPSR6)
.set push
SET_HARDFLOAT
-#ifdef CONFIG_CPU_MIPSR2
+#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR5)
.set mips32r2
.set fp=64
mfc0 t0, CP0_STATUS
@@ -170,11 +170,11 @@ LEAF(_save_fp_context)
LEAF(_restore_fp_context)
EX lw t1, 0(a1)
-#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
- defined(CONFIG_CPU_MIPSR6)
+#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
+ defined(CONFIG_CPU_MIPSR5) || defined(CONFIG_CPU_MIPSR6)
.set push
SET_HARDFLOAT
-#ifdef CONFIG_CPU_MIPSR2
+#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR5)
.set mips32r2
.set fp=64
mfc0 t0, CP0_STATUS
diff --git a/arch/mips/kvm/vz.c b/arch/mips/kvm/vz.c
index 389dd0fbd051..51f51009a53f 100644
--- a/arch/mips/kvm/vz.c
+++ b/arch/mips/kvm/vz.c
@@ -2980,7 +2980,7 @@ static int kvm_vz_vcpu_setup(struct kvm_vcpu *vcpu)
*/
/* PageGrain */
- if (cpu_has_mips_r6)
+ if (cpu_has_mips_r5 || cpu_has_mips_r6)
kvm_write_sw_gc0_pagegrain(cop0, PG_RIE | PG_XIE | PG_IEC);
/* Wired */
if (cpu_has_mips_r6)
@@ -2988,7 +2988,7 @@ static int kvm_vz_vcpu_setup(struct kvm_vcpu *vcpu)
read_gc0_wired() & MIPSR6_WIRED_LIMIT);
/* Status */
kvm_write_sw_gc0_status(cop0, ST0_BEV | ST0_ERL);
- if (cpu_has_mips_r6)
+ if (cpu_has_mips_r5 || cpu_has_mips_r6)
kvm_change_sw_gc0_status(cop0, ST0_FR, read_gc0_status());
/* IntCtl */
kvm_write_sw_gc0_intctl(cop0, read_gc0_intctl() &
@@ -3086,7 +3086,7 @@ static int kvm_vz_vcpu_setup(struct kvm_vcpu *vcpu)
}
/* reset HTW registers */
- if (cpu_guest_has_htw && cpu_has_mips_r6) {
+ if (cpu_guest_has_htw && (cpu_has_mips_r5 || cpu_has_mips_r6)) {
/* PWField */
kvm_write_sw_gc0_pwfield(cop0, 0x0c30c302);
/* PWSize */
diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S
index fda7b57b826e..87fda0713b84 100644
--- a/arch/mips/lib/csum_partial.S
+++ b/arch/mips/lib/csum_partial.S
@@ -279,7 +279,8 @@ EXPORT_SYMBOL(csum_partial)
#endif
/* odd buffer alignment? */
-#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_LOONGSON64)
+#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR5) || \
+ defined(CONFIG_CPU_LOONGSON64)
.set push
.set arch=mips32r2
wsbh v1, sum
@@ -732,7 +733,8 @@ EXPORT_SYMBOL(csum_partial)
addu sum, v1
#endif
-#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_LOONGSON64)
+#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR5) || \
+ defined(CONFIG_CPU_LOONGSON64)
.set push
.set arch=mips32r2
wsbh v1, sum
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 54c18b8a2406..a9f55bf90967 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1709,9 +1709,10 @@ static void setup_scache(void)
return;
default:
- if (c->isa_level & (MIPS_CPU_ISA_M32R1 | MIPS_CPU_ISA_M32R2 |
- MIPS_CPU_ISA_M32R6 | MIPS_CPU_ISA_M64R1 |
- MIPS_CPU_ISA_M64R2 | MIPS_CPU_ISA_M64R6)) {
+ if (c->isa_level & (MIPS_CPU_ISA_M32R1 | MIPS_CPU_ISA_M64R1 |
+ MIPS_CPU_ISA_M32R2 | MIPS_CPU_ISA_M64R2 |
+ MIPS_CPU_ISA_M32R5 | MIPS_CPU_ISA_M64R5 |
+ MIPS_CPU_ISA_M32R6 | MIPS_CPU_ISA_M64R6)) {
#ifdef CONFIG_MIPS_CPU_SCACHE
if (mips_sc_init ()) {
scache_size = c->scache.ways * c->scache.sets * c->scache.linesz;
diff --git a/arch/mips/mm/sc-mips.c b/arch/mips/mm/sc-mips.c
index dbdbfe5d8408..eedad47df24f 100644
--- a/arch/mips/mm/sc-mips.c
+++ b/arch/mips/mm/sc-mips.c
@@ -194,9 +194,10 @@ static inline int __init mips_sc_probe(void)
return mips_sc_probe_cm3();
/* Ignore anything but MIPSxx processors */
- if (!(c->isa_level & (MIPS_CPU_ISA_M32R1 | MIPS_CPU_ISA_M32R2 |
- MIPS_CPU_ISA_M32R6 | MIPS_CPU_ISA_M64R1 |
- MIPS_CPU_ISA_M64R2 | MIPS_CPU_ISA_M64R6)))
+ if (!(c->isa_level & (MIPS_CPU_ISA_M32R1 | MIPS_CPU_ISA_M64R1 |
+ MIPS_CPU_ISA_M32R2 | MIPS_CPU_ISA_M64R2 |
+ MIPS_CPU_ISA_M32R5 | MIPS_CPU_ISA_M64R5 |
+ MIPS_CPU_ISA_M32R6 | MIPS_CPU_ISA_M64R6)))
return 0;
/* Does this MIPS32/MIPS64 CPU have a config2 register? */
--
2.25.1
^ permalink raw reply related
* [PATCH v4 10/13] bus: cdmm: Add MIPS R5 arch support
From: Serge Semin @ 2020-05-21 14:07 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Serge Semin, Serge Semin, Alexey Malahov, Paul Burton,
Ralf Baechle, Greg Kroah-Hartman, Arnd Bergmann, Olof Johansson,
Rob Herring, linux-mips, devicetree, David Lechner,
Jonathan Cameron, Linus Walleij, Sameer Pujar, Marek Behún,
John Garry, Manivannan Sadhasivam, linux-kernel
In-Reply-To: <20200521140725.29571-1-Sergey.Semin@baikalelectronics.ru>
CDMM may be available not only on MIPS R2 architectures, but also on
newer MIPS R5 chips. For instance our P5600 chip has one. Let's mark
the CDMM bus being supported for that MIPS arch too.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
drivers/bus/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 6d4e4497b59b..971c07bc92d4 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -58,7 +58,7 @@ config IMX_WEIM
config MIPS_CDMM
bool "MIPS Common Device Memory Map (CDMM) Driver"
- depends on CPU_MIPSR2
+ depends on CPU_MIPSR2 || CPU_MIPSR5
help
Driver needed for the MIPS Common Device Memory Map bus in MIPS
cores. This bus is for per-CPU tightly coupled devices such as the
--
2.25.1
^ permalink raw reply related
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