| Message ID | 20211215220538.4180616-1-Mr.Bossman075@gmail.com |
|---|---|
| Headers | show |
| Series | Add initial support for the i.MXRTxxxx SoC family starting from i.IMXRT1050 SoC. | expand |
On Wed, Dec 15, 2021 at 11:05 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > > This patchset contains: > - i.MXRT10xx family infrastructure > - i.MXRT1050 pinctrl driver adaption > - i.MXRT1050 clock driver adaption > - i.MXRT1050 sd-card driver adaption > - i.MXRT1050 uart driver adaption > - i.MXRT1050-evk basic support > > The i.MXRTxxxx family that could have support by Linux actually spreads > from i.MXRT1020 to i.MXRT1170 with the first one supporting 1 USB OTG & > 100M ethernet with a cortex-M7@500Mhz up to the latter with i.MXRT1170 > with cortex-M7@1Ghz and cortex-M4@400Mhz, 2MB of internal SRAM, 2D GPU, > 2x 1Gb and 1x 100Mb ENET. The i.MXRT family is NXP's answer to > STM32F7XX, as it uses only simple SDRAM, it gives the chance of a 4 or > less layer PCBs. Seeing that these chips are comparable to the > STM32F7XXs which have linux ported to them it seems reasonable to add > support for them. > > Giving Linux support to this family should ease the development process, > instead of using a RTOS they could use Embedded Linux allowing for more > portability, ease of design and will broaden the scope of people using > embedded linux. > > The EVK has very little SDRAM, generally 32MB starting from > i.MXRT1020(the lowest P/N), although the i.MXRT1160/70 provide instead > 64MB of SDRAM for more functionality. > > At the moment we do not support XIP for either u-boot or Linux but it > should be done in the future. XIP will also save SDRAM. > > Another interesting fact is the amount of internal SRAM, as the P/N > increases the SRAM will reach up to 2MB(some could be for cache and > some would be for video). > > Also, some parts have embed flash of 4MB that can be used for > u-boot/Linux, if both correctly sized it will leave the SDRAM free. > > External flash can be Quad SPI and HyperFlash, so throughput would be > decent. > > The i.MXRT11xx series supports MIPI interface too. > > The family in general provide CAN bus, audio I/O, 1 or more > USB(otg/host), 1 or more 100Mb/1Gb ethernet, camera interface, sd-card. > > All this can be used for simple GUIs, web-servers, point-of-sale > stations, etc. This looks all good to me now, but the drivers need to be reviewed by the respective subsystem maintainers before we can merge it into the soc tree. As with other new SoCs, I'm happy to merge the support as a combined pull request that includes the drivers provided that the driver subsystem maintainers have reviewed them. Ideally the i.MX maintainers would pick up your series into a separate branch and send that to soc@kernel.org the same way as the other topic branches that are usually split out between DT, drivers, soc code etc. With the Christmas break coming up, the timing may not be sufficient before I'm off next week, so it may end up too late for 5.17 but should be fine for 5.18. As a more general comment, it's always nice to see newly added SoC platforms, especially when they are this well implemented and done by hobbyists. However, I do think you are being overly optimistic as to how useful this is going to be to other people: interest in NOMMU ARM platforms has dropped a lot over the past 5 years, and as far as I can tell, it is only being kept alive for existing stm32 customers as the economics do not favor Linux on Cortex-M for new products compare to Linux on Cortex-A or some RTOS on Cortex-M. The existing users will inevitably stop updating their kernels at some point, and then it's most likely just you and Vladimir Murzin that care. Arnd
On Wed, Dec 15, 2021 at 05:05:33PM -0500, Jesse Taube wrote: > From: Jesse Taube <mr.bossman075@gmail.com> > > Add DT binding documentation for i.MXRT1050 clock driver. > > Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> > --- > V1->V2: > * Replace macros with values > V2->V3: > * Remove anatop > * Use lpuart not gpt > * include imxrt1050-clock.h > * 2 space tabs to 4 > * Remove oneOf enum > * Change maxItems to 2 > V3->V4: > * Nothing done > V4->V5: > * Remove extra newline > * Rename ccm to clock-controller > * Change minItems to const > * Change minItems to description > * Rename file to add 1050 > * Change commit description to just 1050 > --- > .../bindings/clock/imxrt1050-clock.yaml | 66 +++++++++++++++++++ > 1 file changed, 66 insertions(+) > create mode 100644 Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml > > diff --git a/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml b/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml > new file mode 100644 > index 000000000000..8caf0572733b > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml > @@ -0,0 +1,66 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/clock/imxrt1050-clock.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Clock bindings for Freescale i.MXRT > + > +maintainers: > + - Giulio Benetti <giulio.benetti@benettiengineering.com> > + - Jesse Taube <Mr.Bossman075@gmail.com> > + > +description: | > + The clock consumer should specify the desired clock by having the clock > + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imxrt*-clock.h > + for the full list of i.MXRT clock IDs. > + > +properties: > + compatible: > + const: fsl,imxrt1050-ccm > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 2 > + > + clocks: > + description: 24m osc maxItems: 1 With that, Reviewed-by: Rob Herring <robh@kernel.org> > + > + clock-names: > + const: osc > + > + '#clock-cells': > + const: 1 > + > +required: > + - compatible > + - reg > + - interrupts > + - clocks > + - clock-names > + - '#clock-cells' > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/clock/imxrt1050-clock.h> > + > + clks: clock-controller@400fc000 { > + compatible = "fsl,imxrt1050-ccm"; > + reg = <0x400fc000 0x4000>; > + interrupts = <95>, <96>; > + clocks = <&osc>; > + clock-names = "osc"; > + #clock-cells = <1>; > + }; > + > + lpuart1: serial@40184000 { > + compatible = "fsl,imxrt1050-lpuart"; > + reg = <0x40184000 0x4000>; > + interrupts = <20>; > + clocks = <&clks IMXRT1050_CLK_LPUART1>; > + clock-names = "ipg"; > + }; > -- > 2.34.1 > >
On 21-12-15 17:05:34, Jesse Taube wrote: > Add clock driver support for i.MXRT1050. > > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> > Suggested-by: Giulio Benetti <giulio.benetti@benettiengineering.com> > --- > V1->V2: > * Kconfig: Add new line > * clk-imxrt.c: Remove unused const > * clk-imxrt.c: Remove set parents > * clk-imxrt.c: Use fsl,imxrt-anatop for anatop base address > V2->V3: > * Remove unused ANATOP_BASE_ADDR > * Move to hw API > * Add GPT's own clock > * Add SEMC clocks to set muxing to CRITICAL > V3->V4: > * Rename clk-imxrt.c to clk-imxrt1050.c > * Rename CONFIG_CLK_IMXRT to CONFIG_CLK_IMXRT1050 > * Make CONFIG_CLK_IMXRT1050 selectable > V4->V5: > * Move to platform driver > --- > drivers/clk/imx/Kconfig | 5 + > drivers/clk/imx/Makefile | 1 + > drivers/clk/imx/clk-imxrt1050.c | 181 ++++++++++++++++++++++++++++++++ > 3 files changed, 187 insertions(+) > create mode 100644 drivers/clk/imx/clk-imxrt1050.c > > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig > index c08edbd04d22..f697652ab19c 100644 > --- a/drivers/clk/imx/Kconfig > +++ b/drivers/clk/imx/Kconfig > @@ -105,3 +105,8 @@ config CLK_IMX8ULP > select MXC_CLK > help > Build the driver for i.MX8ULP CCM Clock Driver > + > +config CLK_IMXRT1050 > + bool "IMXRT1050 CCM Clock Driver" > + depends on SOC_IMXRT > + select MXC_CLK > diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile > index b5e040026dfb..3d9a1e3b5fc6 100644 > --- a/drivers/clk/imx/Makefile > +++ b/drivers/clk/imx/Makefile > @@ -47,3 +47,4 @@ obj-$(CONFIG_CLK_IMX6UL) += clk-imx6ul.o > obj-$(CONFIG_CLK_IMX7D) += clk-imx7d.o > obj-$(CONFIG_CLK_IMX7ULP) += clk-imx7ulp.o > obj-$(CONFIG_CLK_VF610) += clk-vf610.o > +obj-$(CONFIG_CLK_IMXRT1050) += clk-imxrt1050.o > diff --git a/drivers/clk/imx/clk-imxrt1050.c b/drivers/clk/imx/clk-imxrt1050.c > new file mode 100644 > index 000000000000..0132ff45e716 > --- /dev/null > +++ b/drivers/clk/imx/clk-imxrt1050.c > @@ -0,0 +1,181 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > +/* > + * Copyright (C) 2021 > + * Author(s): > + * Jesse Taube <Mr.Bossman075@gmail.com> > + * Giulio Benetti <giulio.benetti@benettiengineering.com> > + */ > +#include <linux/mm.h> > +#include <linux/delay.h> > +#include <linux/clk.h> > +#include <linux/io.h> > +#include <linux/clkdev.h> > +#include <linux/clk-provider.h> > +#include <linux/err.h> > +#include <linux/of.h> > +#include <linux/of_address.h> > +#include <linux/of_irq.h> > +#include <linux/sizes.h> > +#include <soc/imx/revision.h> > +#include <dt-bindings/clock/imxrt1050-clock.h> > + > +#include "clk.h" > + > +static const char * const pll_ref_sels[] = {"osc", "dummy", }; > +static const char * const per_sels[] = {"ipg_pdof", "osc", }; > +static const char * const pll1_bypass_sels[] = {"pll1_arm", "pll1_arm_ref_sel", }; > +static const char * const pll2_bypass_sels[] = {"pll2_sys", "pll2_sys_ref_sel", }; > +static const char * const pll3_bypass_sels[] = {"pll3_usb_otg", "pll3_usb_otg_ref_sel", }; > +static const char * const pll5_bypass_sels[] = {"pll5_video", "pll5_video_ref_sel", }; > +static const char *const pre_periph_sels[] = { > + "pll2_sys", "pll2_pfd2_396m", "pll2_pfd0_352m", "arm_podf", }; > +static const char *const periph_sels[] = { "pre_periph_sel", "todo", }; > +static const char *const usdhc_sels[] = { "pll2_pfd2_396m", "pll2_pfd0_352m", }; > +static const char *const lpuart_sels[] = { "pll3_80m", "osc", }; > +static const char *const lcdif_sels[] = { > + "pll2_sys", "pll3_pfd3_454_74m", "pll5_video", "pll2_pfd0_352m", > + "pll2_pfd1_594m", "pll3_pfd1_664_62m", }; > +static const char *const semc_alt_sels[] = { "pll2_pfd2_396m", "pll3_pfd1_664_62m", }; > +static const char *const semc_sels[] = { "periph_sel", "semc_alt_sel", }; > + > +static struct clk_hw **hws; > +static struct clk_hw_onecell_data *clk_hw_data; > + > +static void __init imxrt_clocks_common_init(void __iomem *base) > +{ > + /* Anatop clocks */ > + hws[IMXRT1050_CLK_DUMMY] = imx_clk_hw_fixed("dummy", 0UL); > + > + hws[IMXRT1050_CLK_PLL1_REF_SEL] = imx_clk_hw_mux("pll1_arm_ref_sel", > + base + 0x0, 14, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels)); > + hws[IMXRT1050_CLK_PLL2_REF_SEL] = imx_clk_hw_mux("pll2_sys_ref_sel", > + base + 0x30, 14, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels)); > + hws[IMXRT1050_CLK_PLL3_REF_SEL] = imx_clk_hw_mux("pll3_usb_otg_ref_sel", > + base + 0x10, 14, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels)); > + hws[IMXRT1050_CLK_PLL5_REF_SEL] = imx_clk_hw_mux("pll5_video_ref_sel", > + base + 0xa0, 14, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels)); > + > + hws[IMXRT1050_CLK_PLL1_ARM] = imx_clk_hw_pllv3(IMX_PLLV3_SYS, "pll1_arm", > + "pll1_arm_ref_sel", base + 0x0, 0x7f); > + hws[IMXRT1050_CLK_PLL2_SYS] = imx_clk_hw_pllv3(IMX_PLLV3_GENERIC, "pll2_sys", > + "pll2_sys_ref_sel", base + 0x30, 0x1); > + hws[IMXRT1050_CLK_PLL3_USB_OTG] = imx_clk_hw_pllv3(IMX_PLLV3_USB, "pll3_usb_otg", > + "pll3_usb_otg_ref_sel", base + 0x10, 0x1); > + hws[IMXRT1050_CLK_PLL5_VIDEO] = imx_clk_hw_pllv3(IMX_PLLV3_AV, "pll5_video", > + "pll5_video_ref_sel", base + 0xa0, 0x7f); > + > + /* PLL bypass out */ > + hws[IMXRT1050_CLK_PLL1_BYPASS] = imx_clk_hw_mux_flags("pll1_bypass", base + 0x0, 16, 1, > + pll1_bypass_sels, ARRAY_SIZE(pll1_bypass_sels), CLK_SET_RATE_PARENT); > + hws[IMXRT1050_CLK_PLL2_BYPASS] = imx_clk_hw_mux_flags("pll2_bypass", base + 0x30, 16, 1, > + pll2_bypass_sels, ARRAY_SIZE(pll2_bypass_sels), CLK_SET_RATE_PARENT); > + hws[IMXRT1050_CLK_PLL3_BYPASS] = imx_clk_hw_mux_flags("pll3_bypass", base + 0x10, 16, 1, > + pll3_bypass_sels, ARRAY_SIZE(pll3_bypass_sels), CLK_SET_RATE_PARENT); > + hws[IMXRT1050_CLK_PLL5_BYPASS] = imx_clk_hw_mux_flags("pll5_bypass", base + 0xa0, 16, 1, > + pll5_bypass_sels, ARRAY_SIZE(pll5_bypass_sels), CLK_SET_RATE_PARENT); > + > + hws[IMXRT1050_CLK_VIDEO_POST_DIV_SEL] = imx_clk_hw_divider("video_post_div_sel", > + "pll5_video", base + 0xa0, 19, 2); > + hws[IMXRT1050_CLK_VIDEO_DIV] = imx_clk_hw_divider("video_div", > + "video_post_div_sel", base + 0x170, 30, 2); > + > + hws[IMXRT1050_CLK_PLL3_80M] = imx_clk_hw_fixed_factor("pll3_80m", "pll3_usb_otg", 1, 6); > + > + hws[IMXRT1050_CLK_PLL2_PFD0_352M] = imx_clk_hw_pfd("pll2_pfd0_352m", "pll2_sys", base + 0x100, 0); > + hws[IMXRT1050_CLK_PLL2_PFD1_594M] = imx_clk_hw_pfd("pll2_pfd1_594m", "pll2_sys", base + 0x100, 1); > + hws[IMXRT1050_CLK_PLL2_PFD2_396M] = imx_clk_hw_pfd("pll2_pfd2_396m", "pll2_sys", base + 0x100, 2); > + hws[IMXRT1050_CLK_PLL3_PFD1_664_62M] = imx_clk_hw_pfd("pll3_pfd1_664_62m", "pll3_usb_otg", base + 0xf0, 1); > + hws[IMXRT1050_CLK_PLL3_PFD3_454_74M] = imx_clk_hw_pfd("pll3_pfd3_454_74m", "pll3_usb_otg", base + 0xf0, 3); > +} > + > +static int imxrt1050_clocks_probe(struct platform_device *pdev) > +{ > + void __iomem *ccm_base; > + void __iomem *pll_base; > + struct device *dev = &pdev->dev; > + struct device_node *np = dev->of_node; > + struct device_node *anp; > + int ret; > + > + clk_hw_data = kzalloc(struct_size(clk_hw_data, hws, > + IMXRT1050_CLK_END), GFP_KERNEL); > + if (WARN_ON(!clk_hw_data)) > + return -ENOMEM; > + > + clk_hw_data->num = IMXRT1050_CLK_END; > + hws = clk_hw_data->hws; > + > + hws[IMXRT1050_CLK_OSC] = __clk_get_hw(of_clk_get_by_name(np, "osc")); > + > + anp = of_find_compatible_node(NULL, NULL, "fsl,imxrt-anatop"); > + pll_base = of_iomap(anp, 0); > + of_node_put(anp) > + if (WARN_ON(!pll_base)) > + return -ENOMEM; > + imxrt_clocks_common_init(pll_base); > + /* CCM clocks */ > + ccm_base = devm_platform_ioremap_resource(pdev, 0); > + if (WARN_ON(IS_ERR(ccm_base))) > + return PTR_ERR(ccm_base); > + > + hws[IMXRT1050_CLK_ARM_PODF] = imx_clk_hw_divider("arm_podf", "pll1_arm", ccm_base + 0x10, 0, 3); > + hws[IMXRT1050_CLK_PRE_PERIPH_SEL] = imx_clk_hw_mux("pre_periph_sel", ccm_base + 0x18, 18, 2, > + pre_periph_sels, ARRAY_SIZE(pre_periph_sels)); > + hws[IMXRT1050_CLK_PERIPH_SEL] = imx_clk_hw_mux("periph_sel", ccm_base + 0x14, 25, 1, > + periph_sels, ARRAY_SIZE(periph_sels)); > + hws[IMXRT1050_CLK_USDHC1_SEL] = imx_clk_hw_mux("usdhc1_sel", ccm_base + 0x1c, 16, 1, > + usdhc_sels, ARRAY_SIZE(usdhc_sels)); > + hws[IMXRT1050_CLK_USDHC2_SEL] = imx_clk_hw_mux("usdhc2_sel", ccm_base + 0x1c, 17, 1, > + usdhc_sels, ARRAY_SIZE(usdhc_sels)); > + hws[IMXRT1050_CLK_LPUART_SEL] = imx_clk_hw_mux("lpuart_sel", ccm_base + 0x24, 6, 1, > + lpuart_sels, ARRAY_SIZE(lpuart_sels)); > + hws[IMXRT1050_CLK_LCDIF_SEL] = imx_clk_hw_mux("lcdif_sel", ccm_base + 0x38, 15, 3, > + lcdif_sels, ARRAY_SIZE(lcdif_sels)); > + hws[IMXRT1050_CLK_PER_CLK_SEL] = imx_clk_hw_mux("per_sel", ccm_base + 0x1C, 6, 1, > + per_sels, ARRAY_SIZE(per_sels)); > + hws[IMXRT1050_CLK_SEMC_ALT_SEL] = imx_clk_hw_mux("semc_alt_sel", ccm_base + 0x14, 7, 1, > + semc_alt_sels, ARRAY_SIZE(semc_alt_sels)); > + hws[IMXRT1050_CLK_SEMC_SEL] = imx_clk_hw_mux_flags("semc_sel", ccm_base + 0x14, 6, 1, > + semc_sels, ARRAY_SIZE(semc_sels), CLK_IS_CRITICAL); > + > + hws[IMXRT1050_CLK_AHB_PODF] = imx_clk_hw_divider("ahb", "periph_sel", ccm_base + 0x14, 10, 3); > + hws[IMXRT1050_CLK_IPG_PDOF] = imx_clk_hw_divider("ipg", "ahb", ccm_base + 0x14, 8, 2); > + hws[IMXRT1050_CLK_PER_PDOF] = imx_clk_hw_divider("per", "per_sel", ccm_base + 0x1C, 0, 5); > + > + hws[IMXRT1050_CLK_USDHC1_PODF] = imx_clk_hw_divider("usdhc1_podf", "usdhc1_sel", ccm_base + 0x24, 11, 3); > + hws[IMXRT1050_CLK_USDHC2_PODF] = imx_clk_hw_divider("usdhc2_podf", "usdhc2_sel", ccm_base + 0x24, 16, 3); > + hws[IMXRT1050_CLK_LPUART_PODF] = imx_clk_hw_divider("lpuart_podf", "lpuart_sel", ccm_base + 0x24, 0, 6); > + hws[IMXRT1050_CLK_LCDIF_PRED] = imx_clk_hw_divider("lcdif_pred", "lcdif_sel", ccm_base + 0x38, 12, 3); > + hws[IMXRT1050_CLK_LCDIF_PODF] = imx_clk_hw_divider("lcdif_podf", "lcdif_pred", ccm_base + 0x18, 23, 3); > + > + hws[IMXRT1050_CLK_USDHC1] = imx_clk_hw_gate2("usdhc1", "usdhc1_podf", ccm_base + 0x80, 2); > + hws[IMXRT1050_CLK_USDHC2] = imx_clk_hw_gate2("usdhc2", "usdhc2_podf", ccm_base + 0x80, 4); > + hws[IMXRT1050_CLK_LPUART1] = imx_clk_hw_gate2("lpuart1", "lpuart_podf", ccm_base + 0x7c, 24); > + hws[IMXRT1050_CLK_LCDIF_APB] = imx_clk_hw_gate2("lcdif", "lcdif_podf", ccm_base + 0x74, 10); > + hws[IMXRT1050_CLK_DMA] = imx_clk_hw_gate("dma", "ipg", ccm_base + 0x7C, 6); > + hws[IMXRT1050_CLK_DMA_MUX] = imx_clk_hw_gate("dmamux0", "ipg", ccm_base + 0x7C, 7); > + hws[IMXRT1050_CLK_GPT] = imx_clk_hw_fixed_factor("gpt", "osc", 1, 8); > + imx_check_clk_hws(hws, IMXRT1050_CLK_END); > + > + ret = of_clk_add_hw_provider(np, of_clk_hw_onecell_get, clk_hw_data); > + if (ret < 0) { > + dev_err(dev, "Failed to register clks for i.MXRT1050.\n"); > + imx_unregister_hw_clocks(hws, IMXRT1050_CLK_END); > + return ret; > + } > + return 0; > +} > +static const struct of_device_id imxrt1050_clk_of_match[] = { > + { .compatible = "fsl,imxrt1050-ccm" }, > + { /* Sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(of, imxrt1050_clk_of_match); > + > +static struct platform_driver imxrt1050_clk_driver = { > + .probe = imxrt1050_clocks_probe, > + .driver = { > + .name = "fsl,imxrt1050-ccm", Name here should be: "imxrt1050-ccm". Drop the "fsl,". Look at the other imx clock drivers:: $ git grep "\.name = \"" drivers/clk/imx/clk-imx* drivers/clk/imx/clk-imx8mm.c: .name = "imx8mm-ccm", drivers/clk/imx/clk-imx8mn.c: .name = "imx8mn-ccm", drivers/clk/imx/clk-imx8mp.c: .name = "imx8mp-ccm", drivers/clk/imx/clk-imx8mq.c: .name = "imx8mq-ccm", drivers/clk/imx/clk-imx8qxp-lpcg.c: .name = "imx8qxp-lpcg-clk", drivers/clk/imx/clk-imx8qxp.c: .name = "imx8qxp-clk", $ > + .of_match_table = of_match_ptr(imxrt1050_clk_of_match), > + }, > +}; > +module_platform_driver(imxrt1050_clk_driver); > -- > 2.34.1 >
Hi Arnd, Jesse, All, sorry for previous HTML e-mail(I was on mobile phone), On 16/12/21 09:26, Arnd Bergmann wrote: > On Wed, Dec 15, 2021 at 11:05 PM Jesse Taube <mr.bossman075@gmail.com> wrote: >> >> This patchset contains: >> - i.MXRT10xx family infrastructure >> - i.MXRT1050 pinctrl driver adaption >> - i.MXRT1050 clock driver adaption >> - i.MXRT1050 sd-card driver adaption >> - i.MXRT1050 uart driver adaption >> - i.MXRT1050-evk basic support >> >> The i.MXRTxxxx family that could have support by Linux actually spreads >> from i.MXRT1020 to i.MXRT1170 with the first one supporting 1 USB OTG & >> 100M ethernet with a cortex-M7@500Mhz up to the latter with i.MXRT1170 >> with cortex-M7@1Ghz and cortex-M4@400Mhz, 2MB of internal SRAM, 2D GPU, >> 2x 1Gb and 1x 100Mb ENET. The i.MXRT family is NXP's answer to >> STM32F7XX, as it uses only simple SDRAM, it gives the chance of a 4 or >> less layer PCBs. Seeing that these chips are comparable to the >> STM32F7XXs which have linux ported to them it seems reasonable to add >> support for them. >> >> Giving Linux support to this family should ease the development process, >> instead of using a RTOS they could use Embedded Linux allowing for more >> portability, ease of design and will broaden the scope of people using >> embedded linux. >> >> The EVK has very little SDRAM, generally 32MB starting from >> i.MXRT1020(the lowest P/N), although the i.MXRT1160/70 provide instead >> 64MB of SDRAM for more functionality. >> >> At the moment we do not support XIP for either u-boot or Linux but it >> should be done in the future. XIP will also save SDRAM. >> >> Another interesting fact is the amount of internal SRAM, as the P/N >> increases the SRAM will reach up to 2MB(some could be for cache and >> some would be for video). >> >> Also, some parts have embed flash of 4MB that can be used for >> u-boot/Linux, if both correctly sized it will leave the SDRAM free. >> >> External flash can be Quad SPI and HyperFlash, so throughput would be >> decent. >> >> The i.MXRT11xx series supports MIPI interface too. >> >> The family in general provide CAN bus, audio I/O, 1 or more >> USB(otg/host), 1 or more 100Mb/1Gb ethernet, camera interface, sd-card. >> >> All this can be used for simple GUIs, web-servers, point-of-sale >> stations, etc. > > This looks all good to me now, but the drivers need to be reviewed by the > respective subsystem maintainers before we can merge it into the soc > tree. As with other new SoCs, I'm happy to merge the support as a combined > pull request that includes the drivers provided that the driver subsystem > maintainers have reviewed them. > > Ideally the i.MX maintainers would pick up your series into a separate > branch and send that to soc@kernel.org the same way as the other topic > branches that are usually split out between DT, drivers, soc code etc. > > With the Christmas break coming up, the timing may not be sufficient > before I'm off next week, so it may end up too late for 5.17 but should > be fine for 5.18. > > As a more general comment, it's always nice to see newly added SoC > platforms, especially when they are this well implemented and done > by hobbyists. However, I do think you are being overly optimistic > as to how useful this is going to be to other people: interest in NOMMU > ARM platforms has dropped a lot over the past 5 years, and as far as I > can tell, it is only being kept alive for existing stm32 customers > as the economics do not favor Linux on Cortex-M for new products > compare to Linux on Cortex-A or some RTOS on Cortex-M. > > The existing users will inevitably stop updating their kernels at some > point, and then it's most likely just you and Vladimir Murzin that care. About this will you accept support for the other SoCs in the family? We would like to add in the near future: - i.MXRT1020(uboot support is already upstreamed) - i.MXRT1024(almost equal to 1020) - i.MXRT1060(almost equal to 1050) - i.MXRT1064(almost equal to 1060) And - i.MXRT1160/70 new family with faster core clock(1Ghz) and a cortex M4 We need to add missing lcd(uboot upstreamed), usb(uboot upstreamed), ethernet(wip) supports for i.MXRT10xx family. This is to organize with Jesse also about buying evaluation boards and timing. We’ve meant this porting also as an exercise to deal with Linux deeper for us and for the other newbies. We’ve been also asked about a possible support for s32s(quad cortex-R52) on initial emails but it has no mmu too. While I’m seeing that some cortex-R is landing inside Linux. Would it be interesting anyway? Best regards —- Giulio Benetti Benetti Engineering sas
On Wed, 15 Dec 2021 17:05:35 -0500, Jesse Taube wrote: > From: Jesse Taube <mr.bossman075@gmail.com> > > Add i.MXRT1050 documentation for compatible string. > > Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> > --- > V1->V2: > * Nothing done > V2->V3: > * Rename imxrt to imxrt1050 > V3->V4: > * Nothing done > V4->V5: > * Change commit description to just 1050 > --- > Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring <robh@kernel.org>
On Thu, Dec 16, 2021 at 6:33 PM Giulio Benetti <giulio.benetti@benettiengineering.com> wrote: > On 16/12/21 09:26, Arnd Bergmann wrote: > > On Wed, Dec 15, 2021 at 11:05 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > > As a more general comment, it's always nice to see newly added SoC > > platforms, especially when they are this well implemented and done > > by hobbyists. However, I do think you are being overly optimistic > > as to how useful this is going to be to other people: interest in NOMMU > > ARM platforms has dropped a lot over the past 5 years, and as far as I > > can tell, it is only being kept alive for existing stm32 customers > > as the economics do not favor Linux on Cortex-M for new products > > compare to Linux on Cortex-A or some RTOS on Cortex-M. > > > > The existing users will inevitably stop updating their kernels at some > > point, and then it's most likely just you and Vladimir Murzin that care. > > > About this will you accept support for the other SoCs in the family? > We would like to add in the near future: > - i.MXRT1020(uboot support is already upstreamed) > - i.MXRT1024(almost equal to 1020) > - i.MXRT1060(almost equal to 1050) > - i.MXRT1064(almost equal to 1060) > And > - i.MXRT1160/70 new family with faster core clock(1Ghz) and a cortex M4 > > We need to add missing lcd(uboot upstreamed), usb(uboot upstreamed), > ethernet(wip) supports for i.MXRT10xx family. Sure, anything you want to work on supporting can be added to the kernel, the important bit is that it's well written and can be maintained going forward. My best guess is that we'll end up ripping out all NOMMU support in a few years, when we get to a point when both of these things happen: - the number of actual users that still update their kernels becomes really low - There is some treewide refactoring that isn't easily supportable without an MMU unless someone puts extra work into it. At the moment, we still support NOMMU kernels on a bunch of architectures (Arm, riscv/k210, sh/j2, m68k/coldfire, xtensa and h8300). Out of these, Arm is by far the most active, and if Arm NOMMU support was to go away for some reason, the others would likely follow. > This is to organize with Jesse also about buying evaluation boards and > timing. > > We’ve meant this porting also as an exercise to deal with Linux deeper > for us and for the other newbies. > > We’ve been also asked about a possible support for s32s(quad cortex-R52) > on initial emails but it has no mmu too. > While I’m seeing that some cortex-R is landing inside Linux. > Would it be interesting anyway? I brought that up during the initial review, but I think this is even less interesting than Cortex-M support from the perspective of potential use cases. While Cortex-M MCUs have some advantages over larger SoCs in terms of power consumption and cost, this is generally not true for running Linux on Cortex-R. The Cortex-R and Cortex-A cores are closely related, so they tend have similar power/performance/area characteristics, but the lack of an MMU makes the Cortex-R much less useful. If there was an advantage to running with the MMU disabled, you could actually do that on a Cortex-A as well, but clearly nobody does that either. Vladimir has put some work into making Cortex-R work in the kernel, and he may have some other thoughts on this question. Arnd
Hi Arnd, On 16/12/21 22:13, Arnd Bergmann wrote: > On Thu, Dec 16, 2021 at 6:33 PM Giulio Benetti > <giulio.benetti@benettiengineering.com> wrote: >> On 16/12/21 09:26, Arnd Bergmann wrote: >>> On Wed, Dec 15, 2021 at 11:05 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > >>> As a more general comment, it's always nice to see newly added SoC >>> platforms, especially when they are this well implemented and done >>> by hobbyists. However, I do think you are being overly optimistic >>> as to how useful this is going to be to other people: interest in NOMMU >>> ARM platforms has dropped a lot over the past 5 years, and as far as I >>> can tell, it is only being kept alive for existing stm32 customers >>> as the economics do not favor Linux on Cortex-M for new products >>> compare to Linux on Cortex-A or some RTOS on Cortex-M. >>> >>> The existing users will inevitably stop updating their kernels at some >>> point, and then it's most likely just you and Vladimir Murzin that care. >> >> >> About this will you accept support for the other SoCs in the family? >> We would like to add in the near future: >> - i.MXRT1020(uboot support is already upstreamed) >> - i.MXRT1024(almost equal to 1020) >> - i.MXRT1060(almost equal to 1050) >> - i.MXRT1064(almost equal to 1060) >> And >> - i.MXRT1160/70 new family with faster core clock(1Ghz) and a cortex M4 >> >> We need to add missing lcd(uboot upstreamed), usb(uboot upstreamed), >> ethernet(wip) supports for i.MXRT10xx family. > > Sure, anything you want to work on supporting can be added to the kernel, > the important bit is that it's well written and can be maintained going forward. > > My best guess is that we'll end up ripping out all NOMMU support in > a few years, when we get to a point when both of these things happen: > > - the number of actual users that still update their kernels becomes > really low > > - There is some treewide refactoring that isn't easily supportable without an > MMU unless someone puts extra work into it. > > At the moment, we still support NOMMU kernels on a bunch of architectures > (Arm, riscv/k210, sh/j2, m68k/coldfire, xtensa and h8300). Out of these, > Arm is by far the most active, and if Arm NOMMU support was to go away > for some reason, the others would likely follow. Ok, I understad now. >> This is to organize with Jesse also about buying evaluation boards and >> timing. >> >> We’ve meant this porting also as an exercise to deal with Linux deeper >> for us and for the other newbies. >> >> We’ve been also asked about a possible support for s32s(quad cortex-R52) >> on initial emails but it has no mmu too. >> While I’m seeing that some cortex-R is landing inside Linux. >> Would it be interesting anyway? > > I brought that up during the initial review, but I think this is even > less interesting > than Cortex-M support from the perspective of potential use cases. While > Cortex-M MCUs have some advantages over larger SoCs in terms of > power consumption and cost, this is generally not true for running Linux > on Cortex-R. The Cortex-R and Cortex-A cores are closely related, so > they tend have similar power/performance/area characteristics, but > the lack of an MMU makes the Cortex-R much less useful. If there was > an advantage to running with the MMU disabled, you could actually do that > on a Cortex-A as well, but clearly nobody does that either. Yes Thank you for the answer > Vladimir has put some work into making Cortex-R work in the kernel, and > he may have some other thoughts on this question. I'm curious if he has something specific to Cortex-R to tell. I've found that Cortex-R82 has a MMU: https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r82 but I can't find any SoC that uses it. Also, I don't know how many people could use it honestly. Best regards
On Fri, Dec 17, 2021 at 10:54 AM Giulio Benetti <giulio.benetti@benettiengineering.com> wrote: > On 16/12/21 22:13, Arnd Bergmann wrote: > > > Vladimir has put some work into making Cortex-R work in the kernel, and > > he may have some other thoughts on this question. > > I'm curious if he has something specific to Cortex-R to tell. > > I've found that Cortex-R82 has a MMU: > https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r82 > but I can't find any SoC that uses it. Also, I don't know how many > people could use it honestly. R82 is fairly new, but I expect that we will see support in Linux in the future. Aside from having an MMU, it also 64-bit-only, so we'd treat it like a normal ARMv8-A core in arch/arm64. Arnd
On 17/12/21 11:28, Arnd Bergmann wrote: > On Fri, Dec 17, 2021 at 10:54 AM Giulio Benetti > <giulio.benetti@benettiengineering.com> wrote: >> On 16/12/21 22:13, Arnd Bergmann wrote: >> >>> Vladimir has put some work into making Cortex-R work in the kernel, and >>> he may have some other thoughts on this question. >> >> I'm curious if he has something specific to Cortex-R to tell. >> >> I've found that Cortex-R82 has a MMU: >> https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r82 >> but I can't find any SoC that uses it. Also, I don't know how many >> people could use it honestly. > > R82 is fairly new, but I expect that we will see support in Linux in the > future. Aside from having an MMU, it also 64-bit-only, so we'd treat > it like a normal ARMv8-A core in arch/arm64. Ah yes, that's fine. So let's wait for the future, in the meanwhile we focus con i.MXRT :-) Thank you Best regards