From: Marco Felsch <m.felsch@pengutronix.de>
To: Anson Huang <anson.huang@nxp.com>
Cc: "robh+dt@kernel.org" <robh+dt@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"festevam@gmail.com" <festevam@gmail.com>,
"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
Aisheng Dong <aisheng.dong@nxp.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH] dt-bindings: imx: update scu resource id headfile
Date: Tue, 19 Feb 2019 15:48:08 +0100 [thread overview]
Message-ID: <20190219144808.qqpaubjcsb4huoml@pengutronix.de> (raw)
In-Reply-To: <DB3PR0402MB3916AF3AA0283DB22DF61E2FF57C0@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hi Anson,
On 19-02-19 13:21, Anson Huang wrote:
> Hi, Marco
>
> Best Regards!
> Anson Huang
>
> > -----Original Message-----
> > From: Marco Felsch [mailto:m.felsch@pengutronix.de]
> >
> > Hi Anson,
> >
> > On 19-02-19 09:01, Anson Huang wrote:
> > > Update i.MX SCU resource ID table according to latest system
> > > controller firmware.
> >
> > will this happen every time the scu firmware gets a update?
>
> If SCU firmware updates this table, then yes, it MUST keep same as SCU firmware,
> but such ID table is NOT updated very often, I checked the history in our internal tree, there
> are ONLY 3 updates since 2016.
Please don't get me wrong, but 3 times since 2016 == every year (since
now) == every 3rd kernel. This seems wrong to me. Can you explain me if
the following use-case will work:
Starting point:
- firmware (incl. bootloader, dtb, scu and other nxp closed source fw)
from 2017
- kernel from 2017
Now the project update the kernel to a version from 2019, but the fw
won't be updated.
There are a lot of projects using such a approach to retrieve security
updates.
I don't like droping some ID's (e.g. IMX_SC_R_DC_0_CAPTURE0) by mark
them as unused or even worse give them a other meaning. IMHO the scu-api
should be stable since day 1 and the ID's should only be extended.
Marking ID's as deprecated is much better than moving them around.
Regards,
Marco
>
> Anson.
>
> >
> > Regards,
> > Marco
> >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > ---
> > > include/dt-bindings/firmware/imx/rsrc.h | 39
> > > +++++++++++++++++++--------------
> > > 1 file changed, 22 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/include/dt-bindings/firmware/imx/rsrc.h
> > > b/include/dt-bindings/firmware/imx/rsrc.h
> > > index 4481f2d..ad747a8 100644
> > > --- a/include/dt-bindings/firmware/imx/rsrc.h
> > > +++ b/include/dt-bindings/firmware/imx/rsrc.h
> > > @@ -36,15 +36,15 @@
> > > #define IMX_SC_R_DC_0_BLIT1 20
> > > #define IMX_SC_R_DC_0_BLIT2 21
> > > #define IMX_SC_R_DC_0_BLIT_OUT 22
> > > -#define IMX_SC_R_DC_0_CAPTURE0 23
> > > -#define IMX_SC_R_DC_0_CAPTURE1 24
> > > +#define IMX_SC_R_PERF 23
> > > +#define IMX_SC_R_UNUSED5 24
> > > #define IMX_SC_R_DC_0_WARP 25
> > > -#define IMX_SC_R_DC_0_INTEGRAL0 26
> > > -#define IMX_SC_R_DC_0_INTEGRAL1 27
> > > +#define IMX_SC_R_UNUSED7 26
> > > +#define IMX_SC_R_UNUSED8 27
> > > #define IMX_SC_R_DC_0_VIDEO0 28
> > > #define IMX_SC_R_DC_0_VIDEO1 29
> > > #define IMX_SC_R_DC_0_FRAC0 30
> > > -#define IMX_SC_R_DC_0_FRAC1 31
> > > +#define IMX_SC_R_UNUSED6 31
> > > #define IMX_SC_R_DC_0 32
> > > #define IMX_SC_R_GPU_2_PID0 33
> > > #define IMX_SC_R_DC_0_PLL_0 34
> > > @@ -53,17 +53,17 @@
> > > #define IMX_SC_R_DC_1_BLIT1 37
> > > #define IMX_SC_R_DC_1_BLIT2 38
> > > #define IMX_SC_R_DC_1_BLIT_OUT 39
> > > -#define IMX_SC_R_DC_1_CAPTURE0 40
> > > -#define IMX_SC_R_DC_1_CAPTURE1 41
> > > +#define IMX_SC_R_UNUSED9 40
> > > +#define IMX_SC_R_UNUSED10 41
> > > #define IMX_SC_R_DC_1_WARP 42
> > > -#define IMX_SC_R_DC_1_INTEGRAL0 43
> > > -#define IMX_SC_R_DC_1_INTEGRAL1 44
> > > +#define IMX_SC_R_UNUSED11 43
> > > +#define IMX_SC_R_UNUSED12 44
> > > #define IMX_SC_R_DC_1_VIDEO0 45
> > > #define IMX_SC_R_DC_1_VIDEO1 46
> > > #define IMX_SC_R_DC_1_FRAC0 47
> > > -#define IMX_SC_R_DC_1_FRAC1 48
> > > +#define IMX_SC_R_UNUSED13 48
> > > #define IMX_SC_R_DC_1 49
> > > -#define IMX_SC_R_GPU_3_PID0 50
> > > +#define IMX_SC_R_UNUSED14 50
> > > #define IMX_SC_R_DC_1_PLL_0 51
> > > #define IMX_SC_R_DC_1_PLL_1 52
> > > #define IMX_SC_R_SPI_0 53
> > > @@ -303,8 +303,8 @@
> > > #define IMX_SC_R_M4_0_UART 287
> > > #define IMX_SC_R_M4_0_I2C 288
> > > #define IMX_SC_R_M4_0_INTMUX 289
> > > -#define IMX_SC_R_M4_0_SIM 290
> > > -#define IMX_SC_R_M4_0_WDOG 291
> > > +#define IMX_SC_R_UNUSED15 290
> > > +#define IMX_SC_R_UNUSED16 291
> > > #define IMX_SC_R_M4_0_MU_0B 292
> > > #define IMX_SC_R_M4_0_MU_0A0 293
> > > #define IMX_SC_R_M4_0_MU_0A1 294
> > > @@ -323,8 +323,8 @@
> > > #define IMX_SC_R_M4_1_UART 307
> > > #define IMX_SC_R_M4_1_I2C 308
> > > #define IMX_SC_R_M4_1_INTMUX 309
> > > -#define IMX_SC_R_M4_1_SIM 310
> > > -#define IMX_SC_R_M4_1_WDOG 311
> > > +#define IMX_SC_R_UNUSED17 310
> > > +#define IMX_SC_R_UNUSED18 311
> > > #define IMX_SC_R_M4_1_MU_0B 312
> > > #define IMX_SC_R_M4_1_MU_0A0 313
> > > #define IMX_SC_R_M4_1_MU_0A1 314
> > > @@ -337,7 +337,7 @@
> > > #define IMX_SC_R_IRQSTR_SCU2 321
> > > #define IMX_SC_R_IRQSTR_DSP 322
> > > #define IMX_SC_R_ELCDIF_PLL 323
> > > -#define IMX_SC_R_UNUSED6 324
> > > +#define IMX_SC_R_OCRAM 324
> > > #define IMX_SC_R_AUDIO_PLL_0 325
> > > #define IMX_SC_R_PI_0 326
> > > #define IMX_SC_R_PI_0_PWM_0 327
> > > @@ -554,6 +554,11 @@
> > > #define IMX_SC_R_VPU_MU_3 538
> > > #define IMX_SC_R_VPU_ENC_1 539
> > > #define IMX_SC_R_VPU 540
> > > -#define IMX_SC_R_LAST 541
> > > +#define IMX_SC_R_DMA_5_CH0 541
> > > +#define IMX_SC_R_DMA_5_CH1 542
> > > +#define IMX_SC_R_DMA_5_CH2 543
> > > +#define IMX_SC_R_DMA_5_CH3 544
> > > +#define IMX_SC_R_ATTESTATION 545
> > > +#define IMX_SC_R_LAST 546
> > >
> > > #endif /* __DT_BINDINGS_RSCRC_IMX_H */
> > > --
> > > 2.7.4
> > >
> > >
> > >
> >
> > --
> > Pengutronix e.K. | |
> > Industrial Linux Solutions |
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> > w.pengutronix.de%2F&data=02%7C01%7Canson.huang%40nxp.com%7
> > Cfe709ac17a164d82c7d508d6966915fb%7C686ea1d3bc2b4c6fa92cd99c5c301
> > 635%7C0%7C0%7C636861775412076730&sdata=05ZzPf2%2BQF10JXLLs
> > OPqDdqTi00BWXNHxmMOsQ1z0yI%3D&reserved=0 |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: Marco Felsch <m.felsch@pengutronix.de>
To: Anson Huang <anson.huang@nxp.com>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
Aisheng Dong <aisheng.dong@nxp.com>,
"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
dl-linux-imx <linux-imx@nxp.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"festevam@gmail.com" <festevam@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] dt-bindings: imx: update scu resource id headfile
Date: Tue, 19 Feb 2019 15:48:08 +0100 [thread overview]
Message-ID: <20190219144808.qqpaubjcsb4huoml@pengutronix.de> (raw)
In-Reply-To: <DB3PR0402MB3916AF3AA0283DB22DF61E2FF57C0@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hi Anson,
On 19-02-19 13:21, Anson Huang wrote:
> Hi, Marco
>
> Best Regards!
> Anson Huang
>
> > -----Original Message-----
> > From: Marco Felsch [mailto:m.felsch@pengutronix.de]
> >
> > Hi Anson,
> >
> > On 19-02-19 09:01, Anson Huang wrote:
> > > Update i.MX SCU resource ID table according to latest system
> > > controller firmware.
> >
> > will this happen every time the scu firmware gets a update?
>
> If SCU firmware updates this table, then yes, it MUST keep same as SCU firmware,
> but such ID table is NOT updated very often, I checked the history in our internal tree, there
> are ONLY 3 updates since 2016.
Please don't get me wrong, but 3 times since 2016 == every year (since
now) == every 3rd kernel. This seems wrong to me. Can you explain me if
the following use-case will work:
Starting point:
- firmware (incl. bootloader, dtb, scu and other nxp closed source fw)
from 2017
- kernel from 2017
Now the project update the kernel to a version from 2019, but the fw
won't be updated.
There are a lot of projects using such a approach to retrieve security
updates.
I don't like droping some ID's (e.g. IMX_SC_R_DC_0_CAPTURE0) by mark
them as unused or even worse give them a other meaning. IMHO the scu-api
should be stable since day 1 and the ID's should only be extended.
Marking ID's as deprecated is much better than moving them around.
Regards,
Marco
>
> Anson.
>
> >
> > Regards,
> > Marco
> >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > ---
> > > include/dt-bindings/firmware/imx/rsrc.h | 39
> > > +++++++++++++++++++--------------
> > > 1 file changed, 22 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/include/dt-bindings/firmware/imx/rsrc.h
> > > b/include/dt-bindings/firmware/imx/rsrc.h
> > > index 4481f2d..ad747a8 100644
> > > --- a/include/dt-bindings/firmware/imx/rsrc.h
> > > +++ b/include/dt-bindings/firmware/imx/rsrc.h
> > > @@ -36,15 +36,15 @@
> > > #define IMX_SC_R_DC_0_BLIT1 20
> > > #define IMX_SC_R_DC_0_BLIT2 21
> > > #define IMX_SC_R_DC_0_BLIT_OUT 22
> > > -#define IMX_SC_R_DC_0_CAPTURE0 23
> > > -#define IMX_SC_R_DC_0_CAPTURE1 24
> > > +#define IMX_SC_R_PERF 23
> > > +#define IMX_SC_R_UNUSED5 24
> > > #define IMX_SC_R_DC_0_WARP 25
> > > -#define IMX_SC_R_DC_0_INTEGRAL0 26
> > > -#define IMX_SC_R_DC_0_INTEGRAL1 27
> > > +#define IMX_SC_R_UNUSED7 26
> > > +#define IMX_SC_R_UNUSED8 27
> > > #define IMX_SC_R_DC_0_VIDEO0 28
> > > #define IMX_SC_R_DC_0_VIDEO1 29
> > > #define IMX_SC_R_DC_0_FRAC0 30
> > > -#define IMX_SC_R_DC_0_FRAC1 31
> > > +#define IMX_SC_R_UNUSED6 31
> > > #define IMX_SC_R_DC_0 32
> > > #define IMX_SC_R_GPU_2_PID0 33
> > > #define IMX_SC_R_DC_0_PLL_0 34
> > > @@ -53,17 +53,17 @@
> > > #define IMX_SC_R_DC_1_BLIT1 37
> > > #define IMX_SC_R_DC_1_BLIT2 38
> > > #define IMX_SC_R_DC_1_BLIT_OUT 39
> > > -#define IMX_SC_R_DC_1_CAPTURE0 40
> > > -#define IMX_SC_R_DC_1_CAPTURE1 41
> > > +#define IMX_SC_R_UNUSED9 40
> > > +#define IMX_SC_R_UNUSED10 41
> > > #define IMX_SC_R_DC_1_WARP 42
> > > -#define IMX_SC_R_DC_1_INTEGRAL0 43
> > > -#define IMX_SC_R_DC_1_INTEGRAL1 44
> > > +#define IMX_SC_R_UNUSED11 43
> > > +#define IMX_SC_R_UNUSED12 44
> > > #define IMX_SC_R_DC_1_VIDEO0 45
> > > #define IMX_SC_R_DC_1_VIDEO1 46
> > > #define IMX_SC_R_DC_1_FRAC0 47
> > > -#define IMX_SC_R_DC_1_FRAC1 48
> > > +#define IMX_SC_R_UNUSED13 48
> > > #define IMX_SC_R_DC_1 49
> > > -#define IMX_SC_R_GPU_3_PID0 50
> > > +#define IMX_SC_R_UNUSED14 50
> > > #define IMX_SC_R_DC_1_PLL_0 51
> > > #define IMX_SC_R_DC_1_PLL_1 52
> > > #define IMX_SC_R_SPI_0 53
> > > @@ -303,8 +303,8 @@
> > > #define IMX_SC_R_M4_0_UART 287
> > > #define IMX_SC_R_M4_0_I2C 288
> > > #define IMX_SC_R_M4_0_INTMUX 289
> > > -#define IMX_SC_R_M4_0_SIM 290
> > > -#define IMX_SC_R_M4_0_WDOG 291
> > > +#define IMX_SC_R_UNUSED15 290
> > > +#define IMX_SC_R_UNUSED16 291
> > > #define IMX_SC_R_M4_0_MU_0B 292
> > > #define IMX_SC_R_M4_0_MU_0A0 293
> > > #define IMX_SC_R_M4_0_MU_0A1 294
> > > @@ -323,8 +323,8 @@
> > > #define IMX_SC_R_M4_1_UART 307
> > > #define IMX_SC_R_M4_1_I2C 308
> > > #define IMX_SC_R_M4_1_INTMUX 309
> > > -#define IMX_SC_R_M4_1_SIM 310
> > > -#define IMX_SC_R_M4_1_WDOG 311
> > > +#define IMX_SC_R_UNUSED17 310
> > > +#define IMX_SC_R_UNUSED18 311
> > > #define IMX_SC_R_M4_1_MU_0B 312
> > > #define IMX_SC_R_M4_1_MU_0A0 313
> > > #define IMX_SC_R_M4_1_MU_0A1 314
> > > @@ -337,7 +337,7 @@
> > > #define IMX_SC_R_IRQSTR_SCU2 321
> > > #define IMX_SC_R_IRQSTR_DSP 322
> > > #define IMX_SC_R_ELCDIF_PLL 323
> > > -#define IMX_SC_R_UNUSED6 324
> > > +#define IMX_SC_R_OCRAM 324
> > > #define IMX_SC_R_AUDIO_PLL_0 325
> > > #define IMX_SC_R_PI_0 326
> > > #define IMX_SC_R_PI_0_PWM_0 327
> > > @@ -554,6 +554,11 @@
> > > #define IMX_SC_R_VPU_MU_3 538
> > > #define IMX_SC_R_VPU_ENC_1 539
> > > #define IMX_SC_R_VPU 540
> > > -#define IMX_SC_R_LAST 541
> > > +#define IMX_SC_R_DMA_5_CH0 541
> > > +#define IMX_SC_R_DMA_5_CH1 542
> > > +#define IMX_SC_R_DMA_5_CH2 543
> > > +#define IMX_SC_R_DMA_5_CH3 544
> > > +#define IMX_SC_R_ATTESTATION 545
> > > +#define IMX_SC_R_LAST 546
> > >
> > > #endif /* __DT_BINDINGS_RSCRC_IMX_H */
> > > --
> > > 2.7.4
> > >
> > >
> > >
> >
> > --
> > Pengutronix e.K. | |
> > Industrial Linux Solutions |
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> > w.pengutronix.de%2F&data=02%7C01%7Canson.huang%40nxp.com%7
> > Cfe709ac17a164d82c7d508d6966915fb%7C686ea1d3bc2b4c6fa92cd99c5c301
> > 635%7C0%7C0%7C636861775412076730&sdata=05ZzPf2%2BQF10JXLLs
> > OPqDdqTi00BWXNHxmMOsQ1z0yI%3D&reserved=0 |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: Marco Felsch <m.felsch@pengutronix.de>
To: Anson Huang <anson.huang@nxp.com>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
Aisheng Dong <aisheng.dong@nxp.com>,
"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
dl-linux-imx <linux-imx@nxp.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"festevam@gmail.com" <festevam@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] dt-bindings: imx: update scu resource id headfile
Date: Tue, 19 Feb 2019 15:48:08 +0100 [thread overview]
Message-ID: <20190219144808.qqpaubjcsb4huoml@pengutronix.de> (raw)
In-Reply-To: <DB3PR0402MB3916AF3AA0283DB22DF61E2FF57C0@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hi Anson,
On 19-02-19 13:21, Anson Huang wrote:
> Hi, Marco
>
> Best Regards!
> Anson Huang
>
> > -----Original Message-----
> > From: Marco Felsch [mailto:m.felsch@pengutronix.de]
> >
> > Hi Anson,
> >
> > On 19-02-19 09:01, Anson Huang wrote:
> > > Update i.MX SCU resource ID table according to latest system
> > > controller firmware.
> >
> > will this happen every time the scu firmware gets a update?
>
> If SCU firmware updates this table, then yes, it MUST keep same as SCU firmware,
> but such ID table is NOT updated very often, I checked the history in our internal tree, there
> are ONLY 3 updates since 2016.
Please don't get me wrong, but 3 times since 2016 == every year (since
now) == every 3rd kernel. This seems wrong to me. Can you explain me if
the following use-case will work:
Starting point:
- firmware (incl. bootloader, dtb, scu and other nxp closed source fw)
from 2017
- kernel from 2017
Now the project update the kernel to a version from 2019, but the fw
won't be updated.
There are a lot of projects using such a approach to retrieve security
updates.
I don't like droping some ID's (e.g. IMX_SC_R_DC_0_CAPTURE0) by mark
them as unused or even worse give them a other meaning. IMHO the scu-api
should be stable since day 1 and the ID's should only be extended.
Marking ID's as deprecated is much better than moving them around.
Regards,
Marco
>
> Anson.
>
> >
> > Regards,
> > Marco
> >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > ---
> > > include/dt-bindings/firmware/imx/rsrc.h | 39
> > > +++++++++++++++++++--------------
> > > 1 file changed, 22 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/include/dt-bindings/firmware/imx/rsrc.h
> > > b/include/dt-bindings/firmware/imx/rsrc.h
> > > index 4481f2d..ad747a8 100644
> > > --- a/include/dt-bindings/firmware/imx/rsrc.h
> > > +++ b/include/dt-bindings/firmware/imx/rsrc.h
> > > @@ -36,15 +36,15 @@
> > > #define IMX_SC_R_DC_0_BLIT1 20
> > > #define IMX_SC_R_DC_0_BLIT2 21
> > > #define IMX_SC_R_DC_0_BLIT_OUT 22
> > > -#define IMX_SC_R_DC_0_CAPTURE0 23
> > > -#define IMX_SC_R_DC_0_CAPTURE1 24
> > > +#define IMX_SC_R_PERF 23
> > > +#define IMX_SC_R_UNUSED5 24
> > > #define IMX_SC_R_DC_0_WARP 25
> > > -#define IMX_SC_R_DC_0_INTEGRAL0 26
> > > -#define IMX_SC_R_DC_0_INTEGRAL1 27
> > > +#define IMX_SC_R_UNUSED7 26
> > > +#define IMX_SC_R_UNUSED8 27
> > > #define IMX_SC_R_DC_0_VIDEO0 28
> > > #define IMX_SC_R_DC_0_VIDEO1 29
> > > #define IMX_SC_R_DC_0_FRAC0 30
> > > -#define IMX_SC_R_DC_0_FRAC1 31
> > > +#define IMX_SC_R_UNUSED6 31
> > > #define IMX_SC_R_DC_0 32
> > > #define IMX_SC_R_GPU_2_PID0 33
> > > #define IMX_SC_R_DC_0_PLL_0 34
> > > @@ -53,17 +53,17 @@
> > > #define IMX_SC_R_DC_1_BLIT1 37
> > > #define IMX_SC_R_DC_1_BLIT2 38
> > > #define IMX_SC_R_DC_1_BLIT_OUT 39
> > > -#define IMX_SC_R_DC_1_CAPTURE0 40
> > > -#define IMX_SC_R_DC_1_CAPTURE1 41
> > > +#define IMX_SC_R_UNUSED9 40
> > > +#define IMX_SC_R_UNUSED10 41
> > > #define IMX_SC_R_DC_1_WARP 42
> > > -#define IMX_SC_R_DC_1_INTEGRAL0 43
> > > -#define IMX_SC_R_DC_1_INTEGRAL1 44
> > > +#define IMX_SC_R_UNUSED11 43
> > > +#define IMX_SC_R_UNUSED12 44
> > > #define IMX_SC_R_DC_1_VIDEO0 45
> > > #define IMX_SC_R_DC_1_VIDEO1 46
> > > #define IMX_SC_R_DC_1_FRAC0 47
> > > -#define IMX_SC_R_DC_1_FRAC1 48
> > > +#define IMX_SC_R_UNUSED13 48
> > > #define IMX_SC_R_DC_1 49
> > > -#define IMX_SC_R_GPU_3_PID0 50
> > > +#define IMX_SC_R_UNUSED14 50
> > > #define IMX_SC_R_DC_1_PLL_0 51
> > > #define IMX_SC_R_DC_1_PLL_1 52
> > > #define IMX_SC_R_SPI_0 53
> > > @@ -303,8 +303,8 @@
> > > #define IMX_SC_R_M4_0_UART 287
> > > #define IMX_SC_R_M4_0_I2C 288
> > > #define IMX_SC_R_M4_0_INTMUX 289
> > > -#define IMX_SC_R_M4_0_SIM 290
> > > -#define IMX_SC_R_M4_0_WDOG 291
> > > +#define IMX_SC_R_UNUSED15 290
> > > +#define IMX_SC_R_UNUSED16 291
> > > #define IMX_SC_R_M4_0_MU_0B 292
> > > #define IMX_SC_R_M4_0_MU_0A0 293
> > > #define IMX_SC_R_M4_0_MU_0A1 294
> > > @@ -323,8 +323,8 @@
> > > #define IMX_SC_R_M4_1_UART 307
> > > #define IMX_SC_R_M4_1_I2C 308
> > > #define IMX_SC_R_M4_1_INTMUX 309
> > > -#define IMX_SC_R_M4_1_SIM 310
> > > -#define IMX_SC_R_M4_1_WDOG 311
> > > +#define IMX_SC_R_UNUSED17 310
> > > +#define IMX_SC_R_UNUSED18 311
> > > #define IMX_SC_R_M4_1_MU_0B 312
> > > #define IMX_SC_R_M4_1_MU_0A0 313
> > > #define IMX_SC_R_M4_1_MU_0A1 314
> > > @@ -337,7 +337,7 @@
> > > #define IMX_SC_R_IRQSTR_SCU2 321
> > > #define IMX_SC_R_IRQSTR_DSP 322
> > > #define IMX_SC_R_ELCDIF_PLL 323
> > > -#define IMX_SC_R_UNUSED6 324
> > > +#define IMX_SC_R_OCRAM 324
> > > #define IMX_SC_R_AUDIO_PLL_0 325
> > > #define IMX_SC_R_PI_0 326
> > > #define IMX_SC_R_PI_0_PWM_0 327
> > > @@ -554,6 +554,11 @@
> > > #define IMX_SC_R_VPU_MU_3 538
> > > #define IMX_SC_R_VPU_ENC_1 539
> > > #define IMX_SC_R_VPU 540
> > > -#define IMX_SC_R_LAST 541
> > > +#define IMX_SC_R_DMA_5_CH0 541
> > > +#define IMX_SC_R_DMA_5_CH1 542
> > > +#define IMX_SC_R_DMA_5_CH2 543
> > > +#define IMX_SC_R_DMA_5_CH3 544
> > > +#define IMX_SC_R_ATTESTATION 545
> > > +#define IMX_SC_R_LAST 546
> > >
> > > #endif /* __DT_BINDINGS_RSCRC_IMX_H */
> > > --
> > > 2.7.4
> > >
> > >
> > >
> >
> > --
> > Pengutronix e.K. | |
> > Industrial Linux Solutions |
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> > w.pengutronix.de%2F&data=02%7C01%7Canson.huang%40nxp.com%7
> > Cfe709ac17a164d82c7d508d6966915fb%7C686ea1d3bc2b4c6fa92cd99c5c301
> > 635%7C0%7C0%7C636861775412076730&sdata=05ZzPf2%2BQF10JXLLs
> > OPqDdqTi00BWXNHxmMOsQ1z0yI%3D&reserved=0 |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-02-19 14:48 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-19 9:01 [PATCH] dt-bindings: imx: update scu resource id headfile Anson Huang
2019-02-19 9:01 ` Anson Huang
2019-02-19 9:01 ` Anson Huang
2019-02-19 12:52 ` Marco Felsch
2019-02-19 12:52 ` Marco Felsch
2019-02-19 12:52 ` Marco Felsch
2019-02-19 13:21 ` Anson Huang
2019-02-19 13:21 ` Anson Huang
2019-02-19 13:21 ` Anson Huang
2019-02-19 14:48 ` Marco Felsch [this message]
2019-02-19 14:48 ` Marco Felsch
2019-02-19 14:48 ` Marco Felsch
2019-02-19 15:28 ` Anson Huang
2019-02-19 15:28 ` Anson Huang
2019-02-19 15:28 ` Anson Huang
2019-02-20 3:38 ` Aisheng Dong
2019-02-20 3:38 ` Aisheng Dong
2019-02-20 3:38 ` Aisheng Dong
2019-02-20 8:16 ` Marco Felsch
2019-02-20 8:16 ` Marco Felsch
2019-02-20 8:16 ` Marco Felsch
2019-02-20 9:49 ` Aisheng Dong
2019-02-20 9:49 ` Aisheng Dong
2019-02-20 9:49 ` Aisheng Dong
2019-02-20 10:52 ` Marco Felsch
2019-02-20 10:52 ` Marco Felsch
2019-02-20 10:52 ` Marco Felsch
2019-02-20 11:21 ` Aisheng Dong
2019-02-20 11:21 ` Aisheng Dong
2019-02-20 11:21 ` Aisheng Dong
2019-02-20 12:11 ` Lucas Stach
2019-02-20 12:11 ` Lucas Stach
2019-02-20 12:11 ` Lucas Stach
2019-02-20 13:44 ` Aisheng Dong
2019-02-20 13:44 ` Aisheng Dong
2019-02-20 13:44 ` Aisheng Dong
2019-02-20 13:52 ` Marco Felsch
2019-02-20 13:52 ` Marco Felsch
2019-02-20 13:52 ` Marco Felsch
2019-02-20 14:09 ` Aisheng Dong
2019-02-20 14:09 ` Aisheng Dong
2019-02-20 14:09 ` Aisheng Dong
2019-02-20 3:29 ` Aisheng Dong
2019-02-20 3:29 ` Aisheng Dong
2019-02-20 3:29 ` Aisheng Dong
2019-02-20 3:36 ` Anson Huang
2019-02-20 3:36 ` Anson Huang
2019-02-20 3:43 ` Aisheng Dong
2019-02-20 3:43 ` Aisheng Dong
2019-02-20 3:43 ` Aisheng Dong
2019-02-20 3:46 ` Anson Huang
2019-02-20 3:46 ` Anson Huang
2019-02-20 3:46 ` Anson Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190219144808.qqpaubjcsb4huoml@pengutronix.de \
--to=m.felsch@pengutronix.de \
--cc=aisheng.dong@nxp.com \
--cc=anson.huang@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.