* [PATCH v4 0/6] Xilinx Zynq OCM support @ 2014-11-14 10:52 Michal Simek 2014-11-14 10:52 ` [PATCH v4 5/6] ARM: zynq: Add OCM controller driver Michal Simek 2014-11-14 10:52 ` [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node Michal Simek 0 siblings, 2 replies; 11+ messages in thread From: Michal Simek @ 2014-11-14 10:52 UTC (permalink / raw) To: linux-arm-kernel, Soren Brinkmann, Olof Johansson, Arnd Bergmann Cc: Mark Rutland, Linus Walleij, Steffen Trumtrar, Mauro Carvalho Chehab, Josh Cartwright, Russell King, Jingoo Han, Sandeep Nair, Antti Palosaari, Grant Likely, Thierry Reding, devicetree, Pawel Moll, Ian Campbell, Kumar Gala, Michal Simek, Rob Herring, Peter Crosthwaite, Santosh Shilimkar, Greg Kroah-Hartman, Peter De Schrijver, linux-kernel, Andy Gross <agro> [-- Attachment #1.1: Type: text/plain, Size: 3870 bytes --] Hi, this is the next attepmt to add support for On Chip Memory configuration via On Chip Memory Controller. OCM can be divided into 4 independend blocks and placed to two locations which this driver detects. For everybody on-chip SRAM driver "mmio-sram" is missing parity IRQ handling not sure how to write in generic way and also the memory layout can be changed at run time (not currently supported by this driver) smp-sram trampoline allocation can be used from mmio-sram and size allocated via DT but currently no reason for using it. Creating mmio-sram node with setting at run time based on current setting is possible but it won't look good. One way how to do it is here "ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board" (sha1: 85e618a1be2b2092318178d1d66bdad49cbbeeeb) but creating nodes at run-time or changing compact strings will be just more hacky code. Using device-tree overlays is another option but SMP trampoline code is placed there and it will be used by PM code that's why driver should be there before user-space. Next option is to create driver which just create platform device at run-time. This is doable but I expect sram driver has to be updated. Thanks, Michal Changes in v4: - New patch in this series - New patch in this series - Move only slcr.h and smp.h and keep common.h in platform which is not needed by OCMC driver Based on Arnd request: https://lkml.org/lkml/2014/10/20/268 Not all symbols from slcr.h/smp.h will be used by OCMC driver - no problem to remove them if it is needed - Add record to MAINTAINERS file - slcr.h has moved to soc/include/ folder. Move definition there too. - Use }; instead of } ; in doc - Use memory-controller@... instead of ocmc@... - Create Kconfig entry for OCMC driver - enable GENERIC_ALLOCATOR here - Add entry to MAINTAINERS file - Use memory-controller@... instead of ocmc@... Changes in v3: - Move OCM to drivers/soc - Update year - Extract DTS node to be able to apply it out of driver - Remove generic allocator enabling - Extract SLCR part - Use const in of_device_id - OCM->OCMC - Use ocmc-1.0 compatible string - Extract from OCM driver Changes in v2: - Update pm.c added in 3.17 too - Soren pointed on it - Change compatibility string to be in xilinx format - Fix kernel-doc format Michal Simek (6): ARM: zynq: Extract smp related functions out of common.h ARM: zynq: Extract slcr related functions out of common.h ARM: zynq: Move slcr.h and smp.h to generic location ARM: zynq: Extend SLCR driver to read OCM configuration ARM: zynq: Add OCM controller driver ARM: zynq: DT: Add OCM controller node .../bindings/arm/zynq/xlnx,zynq-ocmc.txt | 17 ++ MAINTAINERS | 2 + arch/arm/boot/dts/zynq-7000.dtsi | 7 + arch/arm/mach-zynq/common.c | 2 + arch/arm/mach-zynq/common.h | 19 -- arch/arm/mach-zynq/platsmp.c | 3 + arch/arm/mach-zynq/slcr.c | 17 ++ drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/zynq/Kconfig | 13 ++ drivers/soc/zynq/Makefile | 1 + drivers/soc/zynq/zynq_ocmc.c | 247 +++++++++++++++++++++ include/soc/zynq/slcr.h | 30 +++ include/soc/zynq/smp.h | 30 +++ 14 files changed, 371 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/zynq/xlnx,zynq-ocmc.txt create mode 100644 drivers/soc/zynq/Kconfig create mode 100644 drivers/soc/zynq/Makefile create mode 100644 drivers/soc/zynq/zynq_ocmc.c create mode 100644 include/soc/zynq/slcr.h create mode 100644 include/soc/zynq/smp.h -- 1.8.2.3 [-- Attachment #1.2: Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v4 5/6] ARM: zynq: Add OCM controller driver 2014-11-14 10:52 [PATCH v4 0/6] Xilinx Zynq OCM support Michal Simek @ 2014-11-14 10:52 ` Michal Simek [not found] ` <6741d995fbec801d795c5db481e39425bd912f8a.1415962281.git.michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> 2014-11-14 10:52 ` [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node Michal Simek 1 sibling, 1 reply; 11+ messages in thread From: Michal Simek @ 2014-11-14 10:52 UTC (permalink / raw) To: linux-arm-kernel, Soren Brinkmann, Olof Johansson, Arnd Bergmann Cc: monstr, Josh Cartwright, Steffen Trumtrar, Rob Herring, Peter Crosthwaite, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Andrew Morton, David S. Miller, Greg Kroah-Hartman, Joe Perches, Mauro Carvalho Chehab, Antti Palosaari, Jingoo Han, Sandeep Nair, Santosh Shilimkar, Andy Gross, Linus Walleij [-- Attachment #1: Type: text/plain, Size: 11339 bytes --] The driver provide memory allocator which can be used by others drivers to allocate memory inside OCM. All location for 64kB blocks are supported and driver is trying to allocate the largest continuous block of memory. Checking mpcore addressing filterring is not done here but could be added in future. Signed-off-by: Michal Simek <michal.simek@xilinx.com> --- Changes in v4: - Use }; instead of } ; in doc - Use memory-controller@... instead of ocmc@... - Create Kconfig entry for OCMC driver - enable GENERIC_ALLOCATOR here - Add entry to MAINTAINERS file Changes in v3: - Move OCM to drivers/soc - Update year - Extract DTS node to be able to apply it out of driver - Remove generic allocator enabling - Extract SLCR part - Use const in of_device_id - OCM->OCMC - Use ocmc-1.0 compatible string Changes in v2: - Change compatibility string to be in xilinx format - Fix kernel-doc format .../bindings/arm/zynq/xlnx,zynq-ocmc.txt | 17 ++ MAINTAINERS | 1 + drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/zynq/Kconfig | 13 ++ drivers/soc/zynq/Makefile | 1 + drivers/soc/zynq/zynq_ocmc.c | 247 +++++++++++++++++++++ 7 files changed, 281 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/zynq/xlnx,zynq-ocmc.txt create mode 100644 drivers/soc/zynq/Kconfig create mode 100644 drivers/soc/zynq/Makefile create mode 100644 drivers/soc/zynq/zynq_ocmc.c diff --git a/Documentation/devicetree/bindings/arm/zynq/xlnx,zynq-ocmc.txt b/Documentation/devicetree/bindings/arm/zynq/xlnx,zynq-ocmc.txt new file mode 100644 index 000000000000..dcf221e8a16e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/zynq/xlnx,zynq-ocmc.txt @@ -0,0 +1,17 @@ +Device tree bindings for Zynq's OCM controller + +The OCM is divided to 4 64kB segments which can be separately configured +to low or high location. Location is controlled via SLCR. + +Required properties: + compatible: Compatibility string. Must be "xlnx,zynq-ocmc-1.0". + reg: Specify the base and size of the OCMC registers in the memory map. + E.g.: reg = <0xf800c000 0x1000>; + +Example: +ocmc: memory-controller@f800c000 { + compatible = "xlnx,zynq-ocmc-1.0"; + interrupt-parent = <&intc>; + interrupts = <0 3 4>; + reg = <0xf800c000 0x1000>; +}; diff --git a/MAINTAINERS b/MAINTAINERS index 279e87eef71c..b1471df44f44 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1551,6 +1551,7 @@ S: Supported F: arch/arm/mach-zynq/ F: drivers/cpuidle/cpuidle-zynq.c F: drivers/block/xsysace.c +F: drivers/soc/zynq/ F: include/soc/zynq/ N: zynq N: xilinx diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 76d6bd4da138..25cc114a982d 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -3,5 +3,6 @@ menu "SOC (System On Chip) specific Drivers" source "drivers/soc/qcom/Kconfig" source "drivers/soc/ti/Kconfig" source "drivers/soc/versatile/Kconfig" +source "drivers/soc/zynq/Kconfig" endmenu diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 063113d0bd38..77a7865a3367 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_ARCH_QCOM) += qcom/ obj-$(CONFIG_ARCH_TEGRA) += tegra/ obj-$(CONFIG_SOC_TI) += ti/ obj-$(CONFIG_PLAT_VERSATILE) += versatile/ +obj-$(CONFIG_ARCH_ZYNQ) += zynq/ diff --git a/drivers/soc/zynq/Kconfig b/drivers/soc/zynq/Kconfig new file mode 100644 index 000000000000..0163c54acbc6 --- /dev/null +++ b/drivers/soc/zynq/Kconfig @@ -0,0 +1,13 @@ +# +# Xilnx Zynq SoC drivers +# + +if ARCH_ZYNQ + +config ZYNQ_OCMC + def_bool y + select GENERIC_ALLOCATOR + help + Xilinx Zynq On Chip Memory Controller driver + +endif diff --git a/drivers/soc/zynq/Makefile b/drivers/soc/zynq/Makefile new file mode 100644 index 000000000000..807c9b83850d --- /dev/null +++ b/drivers/soc/zynq/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_ZYNQ_OCMC) += zynq_ocmc.o diff --git a/drivers/soc/zynq/zynq_ocmc.c b/drivers/soc/zynq/zynq_ocmc.c new file mode 100644 index 000000000000..1e93a33e11ae --- /dev/null +++ b/drivers/soc/zynq/zynq_ocmc.c @@ -0,0 +1,247 @@ +/* + * Copyright (C) 2013 - 2014 Xilinx + * + * Based on "Generic on-chip SRAM allocation driver" + * + * Copyright (C) 2012 Philipp Zabel, Pengutronix + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/kernel.h> +#include <linux/err.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/of_irq.h> +#include <linux/platform_device.h> +#include <linux/genalloc.h> + +#include <soc/zynq/slcr.h> +#include <soc/zynq/smp.h> + +#define ZYNQ_OCMC_HIGHADDR 0xfffc0000 +#define ZYNQ_OCMC_LOWADDR 0x0 +#define ZYNQ_OCMC_BLOCK_SIZE 0x10000 +#define ZYNQ_OCMC_BLOCKS 4 +#define ZYNQ_OCMC_GRANULARITY 32 + +#define ZYNQ_OCMC_PARITY_CTRL 0x0 +#define ZYNQ_OCMC_PARITY_ENABLE 0x1e + +#define ZYNQ_OCMC_PARITY_ERRADDRESS 0x4 + +#define ZYNQ_OCMC_IRQ_STS 0x8 +#define ZYNQ_OCMC_IRQ_STS_ERR_MASK 0x7 + +struct zynq_ocmc_dev { + void __iomem *base; + int irq; + struct gen_pool *pool; + struct resource res[ZYNQ_OCMC_BLOCKS]; +}; + +/** + * zynq_ocmc_irq_handler - Interrupt service routine of the OCM controller + * @irq: IRQ number + * @data: Pointer to the zynq_ocmc_dev structure + * + * Return: IRQ_HANDLED always + */ +static irqreturn_t zynq_ocmc_irq_handler(int irq, void *data) +{ + u32 sts; + u32 err_addr; + struct zynq_ocmc_dev *zynq_ocmc = data; + + /* check status */ + sts = readl(zynq_ocmc->base + ZYNQ_OCMC_IRQ_STS); + if (sts & ZYNQ_OCMC_IRQ_STS_ERR_MASK) { + /* check error address */ + err_addr = readl(zynq_ocmc->base + ZYNQ_OCMC_PARITY_ERRADDRESS); + pr_err("%s: OCM err intr generated at 0x%04x (stat: 0x%08x).", + __func__, err_addr, sts & ZYNQ_OCMC_IRQ_STS_ERR_MASK); + } + pr_warn("%s: Interrupt generated by OCM, but no error is found.", + __func__); + + return IRQ_HANDLED; +} + +/** + * zynq_ocmc_probe - Probe method for the OCM driver + * @pdev: Pointer to the platform_device structure + * + * This function initializes the driver data structures and the hardware. + * + * Return: 0 on success and error value on failure + */ +static int zynq_ocmc_probe(struct platform_device *pdev) +{ + int ret; + struct zynq_ocmc_dev *zynq_ocmc; + u32 i, ocm_config, curr; + struct resource *res; + + ocm_config = zynq_slcr_get_ocm_config(); + + zynq_ocmc = devm_kzalloc(&pdev->dev, sizeof(*zynq_ocmc), GFP_KERNEL); + if (!zynq_ocmc) + return -ENOMEM; + + zynq_ocmc->pool = devm_gen_pool_create(&pdev->dev, + ilog2(ZYNQ_OCMC_GRANULARITY), + -1); + if (!zynq_ocmc->pool) + return -ENOMEM; + + curr = 0; /* For storing current struct resource for OCM */ + for (i = 0; i < ZYNQ_OCMC_BLOCKS; i++) { + u32 base, start, end; + + /* Setup base address for 64kB OCM block */ + if (ocm_config & BIT(i)) + base = ZYNQ_OCMC_HIGHADDR; + else + base = ZYNQ_OCMC_LOWADDR; + + /* Calculate start and end block addresses */ + start = i * ZYNQ_OCMC_BLOCK_SIZE + base; + end = start + (ZYNQ_OCMC_BLOCK_SIZE - 1); + + /* Concatenate OCM blocks together to get bigger pool */ + if (i > 0 && start == (zynq_ocmc->res[curr - 1].end + 1)) { + zynq_ocmc->res[curr - 1].end = end; + } else { +#ifdef CONFIG_SMP + /* + * OCM block if placed at 0x0 has special meaning + * for SMP because jump trampoline is added there. + * Ensure that this address won't be allocated. + */ + if (!base) { + u32 trampoline_code_size = + &zynq_secondary_trampoline_end - + &zynq_secondary_trampoline; + dev_dbg(&pdev->dev, + "Allocate reset vector table %dB\n", + trampoline_code_size); + /* Postpone start offset */ + start += trampoline_code_size; + } +#endif + /* First resource is always initialized */ + zynq_ocmc->res[curr].start = start; + zynq_ocmc->res[curr].end = end; + zynq_ocmc->res[curr].flags = IORESOURCE_MEM; + curr++; /* Increment curr value */ + } + dev_dbg(&pdev->dev, "OCM block %d, start %x, end %x\n", + i, start, end); + } + + /* + * Separate pool allocation from OCM block detection to ensure + * the biggest possible pool. + */ + for (i = 0; i < ZYNQ_OCMC_BLOCKS; i++) { + unsigned long size; + void __iomem *virt_base; + + /* Skip all zero size resources */ + if (zynq_ocmc->res[i].end == 0) + break; + dev_dbg(&pdev->dev, "OCM resources %d, start %x, end %x\n", + i, zynq_ocmc->res[i].start, zynq_ocmc->res[i].end); + size = resource_size(&zynq_ocmc->res[i]); + virt_base = devm_ioremap_resource(&pdev->dev, + &zynq_ocmc->res[i]); + if (IS_ERR(virt_base)) + return PTR_ERR(virt_base); + + ret = gen_pool_add_virt(zynq_ocmc->pool, + (unsigned long)virt_base, + zynq_ocmc->res[i].start, size, -1); + if (ret < 0) { + dev_err(&pdev->dev, "Gen pool failed\n"); + return ret; + } + dev_info(&pdev->dev, "ZYNQ OCM pool: %ld KiB @ 0x%p\n", + size / 1024, virt_base); + } + + /* Get OCM config space */ + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + zynq_ocmc->base = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(zynq_ocmc->base)) + return PTR_ERR(zynq_ocmc->base); + + /* Allocate OCM parity IRQ */ + zynq_ocmc->irq = platform_get_irq(pdev, 0); + if (zynq_ocmc->irq < 0) { + dev_err(&pdev->dev, "irq resource not found\n"); + return zynq_ocmc->irq; + } + ret = devm_request_irq(&pdev->dev, zynq_ocmc->irq, + zynq_ocmc_irq_handler, + 0, pdev->name, zynq_ocmc); + if (ret != 0) { + dev_err(&pdev->dev, "request_irq failed\n"); + return ret; + } + + /* Enable parity errors */ + writel(ZYNQ_OCMC_PARITY_ENABLE, + zynq_ocmc->base + ZYNQ_OCMC_PARITY_CTRL); + + platform_set_drvdata(pdev, zynq_ocmc); + + return 0; +} + +/** + * zynq_ocmc_remove - Remove method for the OCM driver + * @pdev: Pointer to the platform_device structure + * + * Return: 0 on success and error value on failure + * + * This function is called if a device is physically removed from the system or + * if the driver module is being unloaded. It frees all resources allocated to + * the device. + */ +static int zynq_ocmc_remove(struct platform_device *pdev) +{ + struct zynq_ocmc_dev *zynq_ocmc = platform_get_drvdata(pdev); + + if (gen_pool_avail(zynq_ocmc->pool) < gen_pool_size(zynq_ocmc->pool)) + dev_dbg(&pdev->dev, "removed while SRAM allocated\n"); + + return 0; +} + +static const struct of_device_id zynq_ocmc_dt_ids[] = { + { .compatible = "xlnx,zynq-ocmc-1.0" }, + { /* end of table */ } +}; + +static struct platform_driver zynq_ocmc_driver = { + .driver = { + .name = "zynq_ocmc", + .of_match_table = zynq_ocmc_dt_ids, + }, + .probe = zynq_ocmc_probe, + .remove = zynq_ocmc_remove, +}; + +static int __init zynq_ocmc_init(void) +{ + return platform_driver_register(&zynq_ocmc_driver); +} + +arch_initcall(zynq_ocmc_init); -- 1.8.2.3 [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply related [flat|nested] 11+ messages in thread
[parent not found: <6741d995fbec801d795c5db481e39425bd912f8a.1415962281.git.michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v4 5/6] ARM: zynq: Add OCM controller driver [not found] ` <6741d995fbec801d795c5db481e39425bd912f8a.1415962281.git.michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> @ 2014-11-27 13:20 ` Linus Walleij [not found] ` <CACRpkdbZ8Pwy=04dhJq5ONZ1B-SQK1f=eLZjjCDmV7UQ0aHduA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 11+ messages in thread From: Linus Walleij @ 2014-11-27 13:20 UTC (permalink / raw) To: Michal Simek Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Soren Brinkmann, Olof Johansson, Arnd Bergmann, Michal Simek, Josh Cartwright, Steffen Trumtrar, Rob Herring, Peter Crosthwaite, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Andrew Morton, David S. Miller, Greg Kroah-Hartman, Joe Perches, Mauro Carvalho Chehab, Antti Palosaari, Jingoo On Fri, Nov 14, 2014 at 11:52 AM, Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote: > The driver provide memory allocator which can > be used by others drivers to allocate memory inside OCM. > All location for 64kB blocks are supported Allocation? > and driver is trying to allocate the largest continuous > block of memory. Isn't all genalloc allocations continuous? (...) > + zynq_ocmc->pool = devm_gen_pool_create(&pdev->dev, > + ilog2(ZYNQ_OCMC_GRANULARITY), > + -1); Do this: #include <linux/sizes.h> zynq_ocmc->pool = devm_gen_pool_create(&pdev->dev, ilog2(SZ_64K), -1); And get rid of the #define for ZYNQ_OCMC_GRANULARITY Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CACRpkdbZ8Pwy=04dhJq5ONZ1B-SQK1f=eLZjjCDmV7UQ0aHduA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v4 5/6] ARM: zynq: Add OCM controller driver [not found] ` <CACRpkdbZ8Pwy=04dhJq5ONZ1B-SQK1f=eLZjjCDmV7UQ0aHduA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2014-11-27 13:57 ` Michal Simek [not found] ` <857cab03bd6445c59cc345349a00f67c-xjCwUguQ55+P1V7ZRuPZVmYJ4DzVTqeXkX/xN29GLwg@public.gmane.org> 0 siblings, 1 reply; 11+ messages in thread From: Michal Simek @ 2014-11-27 13:57 UTC (permalink / raw) To: Linus Walleij, Michal Simek Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Soren Brinkmann, Olof Johansson, Arnd Bergmann, Michal Simek, Josh Cartwright, Steffen Trumtrar, Rob Herring, Peter Crosthwaite, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Andrew Morton, David S. Miller, Greg Kroah-Hartman, Joe Perches, Mauro Carvalho Chehab, Antti Palosaari, Jingoo On 11/27/2014 02:20 PM, Linus Walleij wrote: > On Fri, Nov 14, 2014 at 11:52 AM, Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote: > >> The driver provide memory allocator which can >> be used by others drivers to allocate memory inside OCM. >> All location for 64kB blocks are supported > > Allocation? > >> and driver is trying to allocate the largest continuous >> block of memory. > > Isn't all genalloc allocations continuous? I hope it is but blocks can be at different locations. Two locations 0 or 0xfffc0000. it means for every 64k block can be at low or high address location first block 0x0 or 0xfffc0000 second block 0x10000 or 0xfffd0000 third block 0x20000 or 0xfffe0000 four block 0x30000 or 0xffff0000 it is worth to allocate to biggest continuous memory. For example 2 blocks low and then 2 blocks high. 2 blocks with 128kB is better then 4 blocks with 64kB > > (...) >> + zynq_ocmc->pool = devm_gen_pool_create(&pdev->dev, >> + ilog2(ZYNQ_OCMC_GRANULARITY), >> + -1); > > Do this: > > #include <linux/sizes.h> > > zynq_ocmc->pool = devm_gen_pool_create(&pdev->dev, > ilog2(SZ_64K), > -1); > > And get rid of the #define for ZYNQ_OCMC_GRANULARITY ilog2 from 32 is different to ilog2 from ilog2 from 0x10000. But I will look at gen pool internals. Do you have any opinion regarding calling zynq_slcr_get_ocm_config()? Is it better to expose slcr this interface to drivers? Or use regmap and read this value directly? Also I do read for CONFIG_SMP case jump trampoline size - maybe you can have better idea how this can be done. Thanks for your input, Michal -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <857cab03bd6445c59cc345349a00f67c-xjCwUguQ55+P1V7ZRuPZVmYJ4DzVTqeXkX/xN29GLwg@public.gmane.org>]
* Re: [PATCH v4 5/6] ARM: zynq: Add OCM controller driver [not found] ` <857cab03bd6445c59cc345349a00f67c-xjCwUguQ55+P1V7ZRuPZVmYJ4DzVTqeXkX/xN29GLwg@public.gmane.org> @ 2014-11-28 15:35 ` Linus Walleij [not found] ` <CACRpkdbL=yOwjC7j=eacg9K2Mb3rwcKy3b0F8y2H9Nz8RsRRcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 11+ messages in thread From: Linus Walleij @ 2014-11-28 15:35 UTC (permalink / raw) To: Michal Simek Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Soren Brinkmann, Olof Johansson, Arnd Bergmann, Michal Simek, Josh Cartwright, Steffen Trumtrar, Rob Herring, Peter Crosthwaite, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Andrew Morton, David S. Miller, Greg Kroah-Hartman, Joe Perches, Mauro Carvalho Chehab, Antti Palosaari, Jingoo On Thu, Nov 27, 2014 at 2:57 PM, Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote: > On 11/27/2014 02:20 PM, Linus Walleij wrote: >> On Fri, Nov 14, 2014 at 11:52 AM, Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote: >> (...) >>> + zynq_ocmc->pool = devm_gen_pool_create(&pdev->dev, >>> + ilog2(ZYNQ_OCMC_GRANULARITY), >>> + -1); >> >> Do this: >> >> #include <linux/sizes.h> >> >> zynq_ocmc->pool = devm_gen_pool_create(&pdev->dev, >> ilog2(SZ_64K), >> -1); >> >> And get rid of the #define for ZYNQ_OCMC_GRANULARITY > > ilog2 from 32 is different to ilog2 from ilog2 from 0x10000. Bah I misread the code, forget this comment. Maybe it's more like I wanted +#define ZYNQ_OCMC_BLOCK_SIZE 0x10000 To be replaced with SZ_64K But it's a petty detail anyway. > Do you have any opinion regarding calling zynq_slcr_get_ocm_config()? > > Is it better to expose slcr this interface to drivers? > Or use regmap and read this value directly? Depends on what provides that call. The pattern I usually follow is to expose the mixed-registers range as a syscon device using drivers/mfd/syscon.c and then use one of the methods from <linux/mfd/syscon.h> to look up a reference to the regmap and use it to access misc registers. > Also I do read for CONFIG_SMP case jump trampoline size - maybe > you can have better idea how this can be done. No I have no clue about that... :( Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CACRpkdbL=yOwjC7j=eacg9K2Mb3rwcKy3b0F8y2H9Nz8RsRRcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v4 5/6] ARM: zynq: Add OCM controller driver [not found] ` <CACRpkdbL=yOwjC7j=eacg9K2Mb3rwcKy3b0F8y2H9Nz8RsRRcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2014-12-01 14:24 ` Michal Simek 0 siblings, 0 replies; 11+ messages in thread From: Michal Simek @ 2014-12-01 14:24 UTC (permalink / raw) To: Linus Walleij, Michal Simek Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Soren Brinkmann, Olof Johansson, Arnd Bergmann, Josh Cartwright, Steffen Trumtrar, Rob Herring, Peter Crosthwaite, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Andrew Morton, David S. Miller, Greg Kroah-Hartman, Joe Perches, Mauro Carvalho Chehab, Antti Palosaari, Jingoo Han, Sandee [-- Attachment #1: Type: text/plain, Size: 2394 bytes --] On 11/28/2014 04:35 PM, Linus Walleij wrote: > On Thu, Nov 27, 2014 at 2:57 PM, Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote: >> On 11/27/2014 02:20 PM, Linus Walleij wrote: >>> On Fri, Nov 14, 2014 at 11:52 AM, Michal Simek <michal.simek@xilinx.com> wrote: > >>> (...) >>>> + zynq_ocmc->pool = devm_gen_pool_create(&pdev->dev, >>>> + ilog2(ZYNQ_OCMC_GRANULARITY), >>>> + -1); >>> >>> Do this: >>> >>> #include <linux/sizes.h> >>> >>> zynq_ocmc->pool = devm_gen_pool_create(&pdev->dev, >>> ilog2(SZ_64K), >>> -1); >>> >>> And get rid of the #define for ZYNQ_OCMC_GRANULARITY >> >> ilog2 from 32 is different to ilog2 from ilog2 from 0x10000. > > Bah I misread the code, forget this comment. > > Maybe it's more like I wanted > > +#define ZYNQ_OCMC_BLOCK_SIZE 0x10000 > > To be replaced with SZ_64K > > But it's a petty detail anyway. I have fixed it. >> Do you have any opinion regarding calling zynq_slcr_get_ocm_config()? >> >> Is it better to expose slcr this interface to drivers? >> Or use regmap and read this value directly? > > Depends on what provides that call. The pattern I usually follow > is to expose the mixed-registers range as a syscon device > using drivers/mfd/syscon.c and then use one of the methods from > <linux/mfd/syscon.h> to look up a reference to the regmap and > use it to access misc registers. I have tried it and I can just use it without any problem. I have sent v5 with origin version but in cover letter there is a code for that. >> Also I do read for CONFIG_SMP case jump trampoline size - maybe >> you can have better idea how this can be done. > > No I have no clue about that... :( ok - fair enough. One option is to keep it as is. The second option is to allocate any hardcoded size or size passed via DT. But run-time detection is the best IMHO. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node 2014-11-14 10:52 [PATCH v4 0/6] Xilinx Zynq OCM support Michal Simek 2014-11-14 10:52 ` [PATCH v4 5/6] ARM: zynq: Add OCM controller driver Michal Simek @ 2014-11-14 10:52 ` Michal Simek 2014-11-16 10:51 ` Andreas Färber 1 sibling, 1 reply; 11+ messages in thread From: Michal Simek @ 2014-11-14 10:52 UTC (permalink / raw) To: linux-arm-kernel, Soren Brinkmann, Olof Johansson, Arnd Bergmann Cc: monstr, Josh Cartwright, Steffen Trumtrar, Rob Herring, Peter Crosthwaite, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King, devicetree, linux-kernel [-- Attachment #1: Type: text/plain, Size: 878 bytes --] Add the on-chip-memory controller node to the Zynq devicetree. Signed-off-by: Michal Simek <michal.simek@xilinx.com> --- Changes in v4: - Use memory-controller@... instead of ocmc@... Changes in v3: - Extract from OCM driver Changes in v2: None arch/arm/boot/dts/zynq-7000.dtsi | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi index ce2ef5bec4f2..e217fb1c1169 100644 --- a/arch/arm/boot/dts/zynq-7000.dtsi +++ b/arch/arm/boot/dts/zynq-7000.dtsi @@ -150,6 +150,13 @@ reg = <0xf8006000 0x1000>; }; + ocmc: memory-controller@f800c000 { + compatible = "xlnx,zynq-ocmc-1.0"; + interrupt-parent = <&intc>; + interrupts = <0 3 4>; + reg = <0xf800c000 0x1000>; + }; + uart0: serial@e0000000 { compatible = "xlnx,xuartps", "cdns,uart-r1p8"; status = "disabled"; -- 1.8.2.3 [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node 2014-11-14 10:52 ` [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node Michal Simek @ 2014-11-16 10:51 ` Andreas Färber 2014-11-16 19:32 ` Sören Brinkmann 0 siblings, 1 reply; 11+ messages in thread From: Andreas Färber @ 2014-11-16 10:51 UTC (permalink / raw) To: Michal Simek Cc: linux-arm-kernel, Soren Brinkmann, Olof Johansson, Arnd Bergmann, Mark Rutland, Josh Cartwright, monstr, Russell King, Pawel Moll, Ian Campbell, Peter Crosthwaite, linux-kernel, devicetree, Rob Herring, Kumar Gala, Steffen Trumtrar [-- Attachment #1: Type: text/plain, Size: 1089 bytes --] Hi Michal, Am 14.11.2014 um 11:52 schrieb Michal Simek: > diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi > index ce2ef5bec4f2..e217fb1c1169 100644 > --- a/arch/arm/boot/dts/zynq-7000.dtsi > +++ b/arch/arm/boot/dts/zynq-7000.dtsi > @@ -150,6 +150,13 @@ > reg = <0xf8006000 0x1000>; > }; > > + ocmc: memory-controller@f800c000 { > + compatible = "xlnx,zynq-ocmc-1.0"; > + interrupt-parent = <&intc>; > + interrupts = <0 3 4>; > + reg = <0xf800c000 0x1000>; > + }; > + > uart0: serial@e0000000 { > compatible = "xlnx,xuartps", "cdns,uart-r1p8"; > status = "disabled"; Not directly related to this patch: As one can see here, the node order is quite a mess... According to Olof, nodes should be ordered by unit address, whereas here some but not all seem ordered by node name. Would you welcome a cleanup patch, or can you fix that yourself? Regards, Andreas -- SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node 2014-11-16 10:51 ` Andreas Färber @ 2014-11-16 19:32 ` Sören Brinkmann 2014-11-16 23:00 ` Peter Crosthwaite 0 siblings, 1 reply; 11+ messages in thread From: Sören Brinkmann @ 2014-11-16 19:32 UTC (permalink / raw) To: Andreas Färber Cc: Michal Simek, linux-arm-kernel, Olof Johansson, Arnd Bergmann, Mark Rutland, Josh Cartwright, monstr, Russell King, Pawel Moll, Ian Campbell, Peter Crosthwaite, linux-kernel, devicetree, Rob Herring, Kumar Gala, Steffen Trumtrar On Sun, 2014-11-16 at 11:51AM +0100, Andreas Färber wrote: > Hi Michal, > > Am 14.11.2014 um 11:52 schrieb Michal Simek: > > diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi > > index ce2ef5bec4f2..e217fb1c1169 100644 > > --- a/arch/arm/boot/dts/zynq-7000.dtsi > > +++ b/arch/arm/boot/dts/zynq-7000.dtsi > > @@ -150,6 +150,13 @@ > > reg = <0xf8006000 0x1000>; > > }; > > > > + ocmc: memory-controller@f800c000 { > > + compatible = "xlnx,zynq-ocmc-1.0"; > > + interrupt-parent = <&intc>; > > + interrupts = <0 3 4>; > > + reg = <0xf800c000 0x1000>; > > + }; > > + > > uart0: serial@e0000000 { > > compatible = "xlnx,xuartps", "cdns,uart-r1p8"; > > status = "disabled"; > > Not directly related to this patch: As one can see here, the node order > is quite a mess... According to Olof, nodes should be ordered by unit > address, whereas here some but not all seem ordered by node name. Would > you welcome a cleanup patch, or can you fix that yourself? I wouldn't say it's a mess, just a different property to sort the nodes by. For humans reading the DT, searching for nodes, alphabetical order helps finding the right node, IMHO. What advantage would sorting by address have? Thanks, Sören ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node 2014-11-16 19:32 ` Sören Brinkmann @ 2014-11-16 23:00 ` Peter Crosthwaite 2014-11-18 7:56 ` Michal Simek 0 siblings, 1 reply; 11+ messages in thread From: Peter Crosthwaite @ 2014-11-16 23:00 UTC (permalink / raw) To: Sören Brinkmann Cc: Andreas Färber, Michal Simek, linux-arm-kernel@lists.infradead.org, Olof Johansson, Arnd Bergmann, Mark Rutland, Josh Cartwright, Michal Simek, Russell King, Pawel Moll, Ian Campbell, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Rob Herring, Kumar Gala, Steffen Trumtrar On Mon, Nov 17, 2014 at 5:32 AM, Sören Brinkmann <soren.brinkmann@xilinx.com> wrote: > On Sun, 2014-11-16 at 11:51AM +0100, Andreas Färber wrote: >> Hi Michal, >> >> Am 14.11.2014 um 11:52 schrieb Michal Simek: >> > diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi >> > index ce2ef5bec4f2..e217fb1c1169 100644 >> > --- a/arch/arm/boot/dts/zynq-7000.dtsi >> > +++ b/arch/arm/boot/dts/zynq-7000.dtsi >> > @@ -150,6 +150,13 @@ >> > reg = <0xf8006000 0x1000>; >> > }; >> > >> > + ocmc: memory-controller@f800c000 { >> > + compatible = "xlnx,zynq-ocmc-1.0"; >> > + interrupt-parent = <&intc>; >> > + interrupts = <0 3 4>; >> > + reg = <0xf800c000 0x1000>; >> > + }; >> > + >> > uart0: serial@e0000000 { >> > compatible = "xlnx,xuartps", "cdns,uart-r1p8"; >> > status = "disabled"; >> >> Not directly related to this patch: As one can see here, the node order >> is quite a mess... According to Olof, nodes should be ordered by unit >> address, whereas here some but not all seem ordered by node name. Would >> you welcome a cleanup patch, or can you fix that yourself? > > I wouldn't say it's a mess, just a different property to sort the nodes > by. For humans reading the DT, searching for nodes, alphabetical order > helps finding the right node, IMHO. I do generally find myself asking "whats that thing at that address" more than I find myself asking the "wheres that piece of hardware" so Andreas' sorting scheme makes more sense to me. Vertically scanning a DT to give yourself an overview of the system level address map is good too. Wheras alphabetic sorting doesn't mean to much. Regards, Peter What advantage would sorting by > address have? > > Thanks, > Sören > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node 2014-11-16 23:00 ` Peter Crosthwaite @ 2014-11-18 7:56 ` Michal Simek 0 siblings, 0 replies; 11+ messages in thread From: Michal Simek @ 2014-11-18 7:56 UTC (permalink / raw) To: Peter Crosthwaite, Sören Brinkmann Cc: Andreas Färber, Michal Simek, linux-arm-kernel@lists.infradead.org, Olof Johansson, Arnd Bergmann, Mark Rutland, Josh Cartwright, Michal Simek, Russell King, Pawel Moll, Ian Campbell, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Rob Herring, Kumar Gala, Steffen Trumtrar On 11/17/2014 12:00 AM, Peter Crosthwaite wrote: > On Mon, Nov 17, 2014 at 5:32 AM, Sören Brinkmann > <soren.brinkmann@xilinx.com> wrote: >> On Sun, 2014-11-16 at 11:51AM +0100, Andreas Färber wrote: >>> Hi Michal, >>> >>> Am 14.11.2014 um 11:52 schrieb Michal Simek: >>>> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi >>>> index ce2ef5bec4f2..e217fb1c1169 100644 >>>> --- a/arch/arm/boot/dts/zynq-7000.dtsi >>>> +++ b/arch/arm/boot/dts/zynq-7000.dtsi >>>> @@ -150,6 +150,13 @@ >>>> reg = <0xf8006000 0x1000>; >>>> }; >>>> >>>> + ocmc: memory-controller@f800c000 { >>>> + compatible = "xlnx,zynq-ocmc-1.0"; >>>> + interrupt-parent = <&intc>; >>>> + interrupts = <0 3 4>; >>>> + reg = <0xf800c000 0x1000>; >>>> + }; >>>> + >>>> uart0: serial@e0000000 { >>>> compatible = "xlnx,xuartps", "cdns,uart-r1p8"; >>>> status = "disabled"; >>> >>> Not directly related to this patch: As one can see here, the node order >>> is quite a mess... According to Olof, nodes should be ordered by unit >>> address, whereas here some but not all seem ordered by node name. Would >>> you welcome a cleanup patch, or can you fix that yourself? >> >> I wouldn't say it's a mess, just a different property to sort the nodes >> by. For humans reading the DT, searching for nodes, alphabetical order >> helps finding the right node, IMHO. > > I do generally find myself asking "whats that thing at that address" > more than I find myself asking the "wheres that piece of hardware" so > Andreas' sorting scheme makes more sense to me. Vertically scanning a > DT to give yourself an overview of the system level address map is > good too. Wheras alphabetic sorting doesn't mean to much. IMHO the reason why we have names in DT is that it is easily to read/understand them that's why name sorting seems to me more reasonable. Something like machine code and assembler - asm is also sorted by names not by opcode. Is this strict rule? Thanks, Michal ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-12-01 14:24 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-14 10:52 [PATCH v4 0/6] Xilinx Zynq OCM support Michal Simek
2014-11-14 10:52 ` [PATCH v4 5/6] ARM: zynq: Add OCM controller driver Michal Simek
[not found] ` <6741d995fbec801d795c5db481e39425bd912f8a.1415962281.git.michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
2014-11-27 13:20 ` Linus Walleij
[not found] ` <CACRpkdbZ8Pwy=04dhJq5ONZ1B-SQK1f=eLZjjCDmV7UQ0aHduA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-27 13:57 ` Michal Simek
[not found] ` <857cab03bd6445c59cc345349a00f67c-xjCwUguQ55+P1V7ZRuPZVmYJ4DzVTqeXkX/xN29GLwg@public.gmane.org>
2014-11-28 15:35 ` Linus Walleij
[not found] ` <CACRpkdbL=yOwjC7j=eacg9K2Mb3rwcKy3b0F8y2H9Nz8RsRRcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-01 14:24 ` Michal Simek
2014-11-14 10:52 ` [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node Michal Simek
2014-11-16 10:51 ` Andreas Färber
2014-11-16 19:32 ` Sören Brinkmann
2014-11-16 23:00 ` Peter Crosthwaite
2014-11-18 7:56 ` Michal Simek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).