| Message ID | 20211024154027.1479261-1-Mr.Bossman075@gmail.com |
|---|---|
| Headers | show |
| Series | This patchset aims to add initial support for the i.MXRT10xx family | expand |
Hi Jesse, On Sun, Oct 24, 2021 at 12:40 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > +#include "clk.h" > +#define ANATOP_BASE_ADDR 0x400d8000 This should be retrieved from the device tree > + imx_check_clocks(clk, ARRAY_SIZE(clk)); > + clk_data.clks = clk; > + clk_data.clk_num = ARRAY_SIZE(clk); > + of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data); > + clk_set_parent(clk[IMXRT1050_CLK_PLL1_BYPASS], clk[IMXRT1050_CLK_PLL1_REF_SEL]); The clock parent description could be made via device tree.
On 10/24/21 8:40 AM, Jesse Taube wrote: > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig > index 47d9ec3abd2f..19adce25167d 100644 > --- a/drivers/clk/imx/Kconfig > +++ b/drivers/clk/imx/Kconfig > @@ -98,3 +98,6 @@ config CLK_IMX8QXP > select MXC_CLK_SCU > help > Build the driver for IMX8QXP SCU based clocks. > +config CLK_IMXRT > + def_bool SOC_IMXRT > + select MXC_CLK Hi, Please keep one blank line between config entries, the way that the rest of that file is. (and pretty much all other Kconfig files) thanks.
On Sun, Oct 24, 2021 at 5:40 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > +/* > + * The pin function ID is a tuple of > + * <mux_reg conf_reg input_reg mux_mode input_val> > + */ > + > +#define MXRT1050_IOMUXC_GPIO_EMC_00_SEMC_DA00 0x014 0x204 0x000 0x0 0x0 > +#define MXRT1050_IOMUXC_GPIO_EMC_00_FLEXPWM4_PWM0_A 0x014 0x204 0x494 0x1 0x0 > +#define MXRT1050_IOMUXC_GPIO_EMC_00_LPSPI2_SCK 0x014 0x204 0x500 0x2 0x1 > +#define MXRT1050_IOMUXC_GPIO_EMC_00_XBAR_INOUT2 0x014 0x204 0x60C 0x3 0x0 > +#define MXRT1050_IOMUXC_GPIO_EMC_00_FLEXIO1_D00 0x014 0x204 0x000 0x4 0x0 > +#define MXRT1050_IOMUXC_GPIO_EMC_00_GPIO4_IO00 0x014 0x204 0x000 0x5 0x0 The constants don't appear to be needed in this header at all, as the binding looks completely generic with a tuple of five values, so you could simply open-code the numbers where they are used, no need to include these in a driver. Arnd
On Sun, Oct 24, 2021 at 5:40 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > + pinctrl_semc: semcgrp { > + fsl,pins = < This node doesn't appear to be referenced from anywhere. Is it actually needed? > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + > + aliases { > + gpio0 = &gpio1; > + gpio1 = &gpio2; > + gpio2 = &gpio3; > + gpio3 = &gpio4; > + gpio4 = &gpio5; > + mmc0 = &usdhc1; > + serial0 = &lpuart1; > + }; The aliases should go into the .dts file. > + edma1: dma-controller@400E8000 { > + #dma-cells = <2>; > + compatible = "fsl,imx7ulp-edma"; > + reg = <0x400E8000 0x4000>, > + <0x400EC000 0x4000>; Use lowercase letters in hex numbers here. Arnd
On Sun, Oct 24, 2021 at 5:40 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > > Add initial support for the i.MXRT10xx SoC family > starting with the i.IMXRT1050 SoC. > 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 Can you expand the description a bit more so it makes sense as a changelog text for the merge commit? It's fairly rare these days that we add support for a MMU-less platform, so it would be good if the introductory text answers questions like: - what is this platform used for, and what is the purpose of running Linux on it in place of the usual RTOS variants? - are you doing this just for fun, or are there any commercial use cases? - what are the minimum and maximum memory configurations this has been tested with? - what user space are you testing with: any particular distro that supports this platform, and do you run elf-fdpic or flat binaries. - are you planning to also support the newer i.MXRT11xx or Cortex-R based designs like the S32S? Arnd
Hello Arnd, Giulio is in CC On 10/24/21 3:32 PM, Arnd Bergmann wrote: > On Sun, Oct 24, 2021 at 5:40 PM Jesse Taube <mr.bossman075@gmail.com> wrote: >> >> Add initial support for the i.MXRT10xx SoC family >> starting with the i.IMXRT1050 SoC. >> 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 > > Can you expand the description a bit more so it makes sense as a changelog > text for the merge commit? It's fairly rare these days that we add support for a > MMU-less platform, so it would be good if the introductory text answers > questions like: > > - what is this platform used for, and what is the purpose of running Linux on it > in place of the usual RTOS variants? > > - are you doing this just for fun, or are there any commercial use cases? The purpose of this is for learning and fun, as far as we know there are no commercial use cases, but we hope there will be. > - what are the minimum and maximum memory configurations this has > been tested with? We both have only tested with 32MB of ram on i.MXRT1050/60-evk. > - what user space are you testing with: any particular distro that supports > this platform, and do you run elf-fdpic or flat binaries. We are using Buildroot[1] and that only uses flat binaries. i.MXRT1050/20 have already been up-streamed to U-Boot[2]. > - are you planning to also support the newer i.MXRT11xx or > Cortex-R based designs like the S32S? We plan to support the i.MXRT11xx, but unsure about the S32x, it depends on the interest. > > Arnd > [1]: https://github.com/Mr-Bossman/imxrt-linux-buildroot.git [2]: https://source.denx.de/u-boot/u-boot/-/blob/master/configs/imxrt1050-evk_defconfig Thank you, Jesse Taube.
Hello Arnd, Jesse, All, Jesse and I have answered together, but I’ve missed 1 point below > Il giorno 25 ott 2021, alle ore 00:21, Jesse Taube <mr.bossman075@gmail.com> ha scritto: > > Hello Arnd, > > Giulio is in CC > >> On 10/24/21 3:32 PM, Arnd Bergmann wrote: >>> On Sun, Oct 24, 2021 at 5:40 PM Jesse Taube <mr.bossman075@gmail.com> wrote: >>> >>> Add initial support for the i.MXRT10xx SoC family >>> starting with the i.IMXRT1050 SoC. >>> 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 >> >> Can you expand the description a bit more so it makes sense as a changelog >> text for the merge commit? It's fairly rare these days that we add support for a >> MMU-less platform, so it would be good if the introductory text answers >> questions like: >> >> - what is this platform used for, and what is the purpose of running Linux on it >> in place of the usual RTOS variants? I’ve forgotten to mention the reason of Linux here before with Jesse. I think that someone could find an easier ready to go environment with Linux(and Buildroot as build system), not that much for graphics but for all the utilities starting from bash. Graphics can anyway benefit from qt lite or other lightweight library statically built. This SoC is used around the world with MCUXPRESSO and it’s the nxp answer to stm32f7 more or less. A private company already provide a commercial Linux 4.5 BSP for it(we’re rewritten from scratch), so I think this means that someone is interested. >> >> - are you doing this just for fun, or are there any commercial use cases? > > The purpose of this is for learning and fun, as far as we know there are no > commercial use cases, but we hope there will be. At the moment there is no request, but because of upstreaming maybe there could be. > >> - what are the minimum and maximum memory configurations this has >> been tested with? > > We both have only tested with 32MB of ram on i.MXRT1050/60-evk. Those 2 SoCs can expand up to 64MB. > >> - what user space are you testing with: any particular distro that supports >> this platform, and do you run elf-fdpic or flat binaries. > > We are using Buildroot[1] and that only uses flat binaries. > i.MXRT1050/20 have already been up-streamed to U-Boot[2]. > >> - are you planning to also support the newer i.MXRT11xx or >> Cortex-R based designs like the S32S? > > We plan to support the i.MXRT11xx, but unsure about the S32x, it depends > on the interest. > >> >> Arnd >> > [1]: https://github.com/Mr-Bossman/imxrt-linux-buildroot.git > [2]: https://source.denx.de/u-boot/u-boot/-/blob/master/configs/imxrt1050-evk_defconfig > > Thank you, > Jesse Taube. The rest is already answered Best regards Giulio Benetti Benetti Engineering sas
On Sun, Oct 24, 2021 at 5:40 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > From: Giulio Benetti <giulio.benetti@benettiengineering.com> > > Add binding doc for i.MXRT1050 pinctrl driver. > > Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> On this and all the pinctrl stuff I need review from the current Freescale maintainers, the fsl,pins stuff is a Freescale pecularity. I would hardcode all of this into the driver but there are historical reason for why Freescale want it and does it this way. (And I don't understand those.) Yours, Linus Walleij
On Sun, Oct 24, 2021 at 11:40:23AM -0400, Jesse Taube wrote: > Add support for i.MXRT1050's uart. > > Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On Sun, 24 Oct 2021 11:40:19 -0400, Jesse Taube wrote: > Add DT binding documentation for i.MXRT clock driver. > > Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> > --- > .../bindings/clock/imxrt-clock.yaml | 57 +++++++++++++++++++ > 1 file changed, 57 insertions(+) > create mode 100644 Documentation/devicetree/bindings/clock/imxrt-clock.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/clock/imxrt-clock.example.dts:32.27-28 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [scripts/Makefile.lib:385: Documentation/devicetree/bindings/clock/imxrt-clock.example.dt.yaml] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:1441: dt_binding_check] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1545398 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
On Sun, 24 Oct 2021 11:40:16 -0400, Jesse Taube wrote: > Add i.MXRT1050 pinctrl binding doc > > Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> > --- > .../bindings/pinctrl/fsl,imxrt1050.yaml | 85 +++++++++++++++++++ > 1 file changed, 85 insertions(+) > create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: ./Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/pinctrl/fsl,imxrt1050.yaml# Error: Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.example.dts:27.15-16 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [scripts/Makefile.lib:385: Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.example.dt.yaml] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:1441: dt_binding_check] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1545393 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
On Sun, Oct 24, 2021 at 11:40:17AM -0400, Jesse Taube wrote: > From: Giulio Benetti <giulio.benetti@benettiengineering.com> > > Add binding doc for i.MXRT1050 pinctrl driver. > > Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> > --- > include/dt-bindings/pinctrl/pins-imxrt1050.h | 993 +++++++++++++++++++ > 1 file changed, 993 insertions(+) > create mode 100644 include/dt-bindings/pinctrl/pins-imxrt1050.h > > diff --git a/include/dt-bindings/pinctrl/pins-imxrt1050.h b/include/dt-bindings/pinctrl/pins-imxrt1050.h > new file mode 100644 > index 000000000000..a29031ab3de0 > --- /dev/null > +++ b/include/dt-bindings/pinctrl/pins-imxrt1050.h > @@ -0,0 +1,993 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ Needs to match the .dts files which has BSD-3-Clause. The rest of i.MX uses MIT IIRC. You should align with that.
On Sun, 24 Oct 2021 11:40:22 -0400, Jesse Taube wrote: > Add i.MXRT documentation for compatible string. > > Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> > --- > Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring <robh@kernel.org>
On Sun, Oct 24, 2021 at 11:40:22AM -0400, Jesse Taube wrote: > Add i.MXRT documentation for compatible string. > > Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> > --- > Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml > index a90c971b4f1f..4b4340def2aa 100644 > --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml > +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml > @@ -21,6 +21,7 @@ properties: > - fsl,ls1028a-lpuart > - fsl,imx7ulp-lpuart > - fsl,imx8qm-lpuart > + - fsl,imxrt-lpuart Actually, 'rt' is not a single part is it? If the variations are same die, but fused off then no need to distinguish. Otherwise, these should be SoC specific. Same applies to other compatible strings. > - items: > - const: fsl,imx8qxp-lpuart > - const: fsl,imx7ulp-lpuart > -- > 2.33.0 > >
On 11/1/21 16:13, Rob Herring wrote: > On Sun, Oct 24, 2021 at 11:40:22AM -0400, Jesse Taube wrote: >> Add i.MXRT documentation for compatible string. >> >> Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> >> Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> >> --- >> Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml >> index a90c971b4f1f..4b4340def2aa 100644 >> --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml >> +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml >> @@ -21,6 +21,7 @@ properties: >> - fsl,ls1028a-lpuart >> - fsl,imx7ulp-lpuart >> - fsl,imx8qm-lpuart >> + - fsl,imxrt-lpuart > > Actually, 'rt' is not a single part is it? If the variations are same > die, but fused off then no need to distinguish. Otherwise, these should > be SoC specific. > I don't exactly know what "but fused off" means I would assume disconnected but on-die? The imxrtxxx is a series that has the same UART controller across them. Should I add ACK? > Same applies to other compatible strings. > >> - items: >> - const: fsl,imx8qxp-lpuart >> - const: fsl,imx7ulp-lpuart >> -- >> 2.33.0 >> >>
On 11/1/21 16:10, Rob Herring wrote: > On Sun, Oct 24, 2021 at 11:40:17AM -0400, Jesse Taube wrote: >> From: Giulio Benetti <giulio.benetti@benettiengineering.com> >> >> Add binding doc for i.MXRT1050 pinctrl driver. >> >> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> >> Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> >> --- >> include/dt-bindings/pinctrl/pins-imxrt1050.h | 993 +++++++++++++++++++ >> 1 file changed, 993 insertions(+) >> create mode 100644 include/dt-bindings/pinctrl/pins-imxrt1050.h >> >> diff --git a/include/dt-bindings/pinctrl/pins-imxrt1050.h b/include/dt-bindings/pinctrl/pins-imxrt1050.h >> new file mode 100644 >> index 000000000000..a29031ab3de0 >> --- /dev/null >> +++ b/include/dt-bindings/pinctrl/pins-imxrt1050.h >> @@ -0,0 +1,993 @@ >> +/* SPDX-License-Identifier: GPL-2.0+ */ > > Needs to match the .dts files which has BSD-3-Clause. The rest of i.MX > uses MIT IIRC. You should align with that. > It seems to use "GPL-2.0+ OR MIT", I shall replace the both with that.
On Mon, Nov 1, 2021 at 6:34 PM Jesse Taube <mr.bossman075@gmail.com> wrote: > > > > On 11/1/21 16:13, Rob Herring wrote: > > On Sun, Oct 24, 2021 at 11:40:22AM -0400, Jesse Taube wrote: > >> Add i.MXRT documentation for compatible string. > >> > >> Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> > >> Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> > >> --- > >> Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml > >> index a90c971b4f1f..4b4340def2aa 100644 > >> --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml > >> +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml > >> @@ -21,6 +21,7 @@ properties: > >> - fsl,ls1028a-lpuart > >> - fsl,imx7ulp-lpuart > >> - fsl,imx8qm-lpuart > >> + - fsl,imxrt-lpuart > > > > Actually, 'rt' is not a single part is it? If the variations are same > > die, but fused off then no need to distinguish. Otherwise, these should > > be SoC specific. > > > I don't exactly know what "but fused off" means I would assume > disconnected but on-die? Right. Or not pinned out is another possibility. > The imxrtxxx is a series that has the same UART > controller across them. Should I add ACK? Looking at the errata docs briefly, there's at least 2 die as some of the errata docs give the mask id. So they aren't necessarily 'the same'. You want the compatible strings to be specific enough to handle any differences or errata. If you only care about the imxrt1050, then I'd just use that and move on. Otherwise, maybe someone from NXP wants to comment? Rob
Hello Rob, Jesse, All, > Il giorno 3 nov 2021, alle ore 01:49, Rob Herring <robh@kernel.org> ha scritto: > > On Mon, Nov 1, 2021 at 6:34 PM Jesse Taube <mr.bossman075@gmail.com> wrote: >> >> >> >>> On 11/1/21 16:13, Rob Herring wrote: >>> On Sun, Oct 24, 2021 at 11:40:22AM -0400, Jesse Taube wrote: >>>> Add i.MXRT documentation for compatible string. >>>> >>>> Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> >>>> Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> >>>> --- >>>> Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml >>>> index a90c971b4f1f..4b4340def2aa 100644 >>>> --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml >>>> +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml >>>> @@ -21,6 +21,7 @@ properties: >>>> - fsl,ls1028a-lpuart >>>> - fsl,imx7ulp-lpuart >>>> - fsl,imx8qm-lpuart >>>> + - fsl,imxrt-lpuart >>> >>> Actually, 'rt' is not a single part is it? If the variations are same >>> die, but fused off then no need to distinguish. Otherwise, these should >>> be SoC specific. >>> >> I don't exactly know what "but fused off" means I would assume >> disconnected but on-die? > > Right. Or not pinned out is another possibility. > >> The imxrtxxx is a series that has the same UART >> controller across them. Should I add ACK? > > Looking at the errata docs briefly, there's at least 2 die as some of > the errata docs give the mask id. So they aren't necessarily 'the > same'. Thank you for pointing, we’ve missed this particular. > You want the compatible strings to be specific enough to handle > any differences or errata. If you only care about the imxrt1050, then > I'd just use that and move on. We plan to add from imxrt1020 to imxrt1170 and eventual new SoC, so we definitely need separate .compatible strings. @Jesse, can you please update with ‘fsl,imxrt1050”? > Otherwise, maybe someone from NXP wants > to comment? Any NXP comment is welcome! Best regards Giulio Benetti Benetti engineering sas > > Rob