From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED, USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19614C43381 for ; Wed, 20 Feb 2019 08:17:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D112A2070B for ; Wed, 20 Feb 2019 08:17:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726479AbfBTIQ7 (ORCPT ); Wed, 20 Feb 2019 03:16:59 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:57925 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725779AbfBTIQ6 (ORCPT ); Wed, 20 Feb 2019 03:16:58 -0500 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gwN3k-0005VC-85; Wed, 20 Feb 2019 09:16:52 +0100 Received: from mfe by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1gwN3i-0008ML-Tz; Wed, 20 Feb 2019 09:16:50 +0100 Date: Wed, 20 Feb 2019 09:16:50 +0100 From: Marco Felsch To: Aisheng Dong Cc: Anson Huang , "robh+dt@kernel.org" , "mark.rutland@arm.com" , "shawnguo@kernel.org" , "s.hauer@pengutronix.de" , "kernel@pengutronix.de" , "festevam@gmail.com" , "ulf.hansson@linaro.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , dl-linux-imx Subject: Re: [PATCH] dt-bindings: imx: update scu resource id headfile Message-ID: <20190220081650.cu3yzausx55jefb6@pengutronix.de> References: <1550566601-11497-1-git-send-email-Anson.Huang@nxp.com> <20190219125211.2pg2bqxner4klcb5@pengutronix.de> <20190219144808.qqpaubjcsb4huoml@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 08:40:43 up 32 days, 12:22, 38 users, load average: 0.12, 0.04, 0.01 User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: mfe@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19-02-20 03:38, Aisheng Dong wrote: > [...] > > > > 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. > > > > I agree the SCU APIs should be stable since day 1 and the ID should ONLY be > > extended, but that is the best cases, the reality is, there are different > > SoCs/Revision, some revisions may remove the resources ID defined in > > pre-coded SCU firmware, like the IMX_SC_R_DC_0_CAPTURE0 etc., so SCU APIs > > removes them after real silicon arrived, now latest SCU firmware marks them > > as UNUSED, they could be replaced by some other new resources in later new > > SoC, I am NOT sure, but if it happens, this resource ID table should be updated > > anyway, leaving the out-of-date resource ID table there will have issues, since it > > is NOT sync with SCU firmware. > > > > So how to resolve such issue? We hope the SCU firmware should be stable > > since day 1, but the truth is NOT, could be still some updates but NOT very > > often. And I believe the updates will NOT break old kernel version. Hi Anson, Please don't mix the dt-bindings and the kernel related stuff. Unfortunately the bindings are within the kernel repo which in fact is great for us kernel developer but the bindings are also used in other projects such as barebox or other kernels (don't know the BSD guys). So you can't ensure that your change will break something. Please keep that in mind. IMHO solving that issue should be done by the scu firmware. I tought the scu is a cortex-m4 with a bunch of embedded flash and ram (I don't know that much about the scu since it is closed/black-boxed). Why do you don't use a translation table within the scu? As I said earlier I don't like the redefinition of ID's since they are now part of the dt-bindings. The bindings can store up to 32bit values which is a large number ;) IMHO wasting some ID's in favour of stability is a better solution. Regards, Marco > > > > Please double check with SCU firmware owner what the removed ID are used before? > Any side effect if removing them. > > And please also check if the combability can be maintained via IMX_SC_RPC_VERSION? > > Regards > Dong Aisheng > > > Anson. > > > > > > > > Regards, > > > Marco > > > > > > > > > > > Anson. > > > > > > > > > > > > > > Regards, > > > > > Marco > > > > > > > > > > > Signed-off-by: Anson Huang > > > > > > --- > > > > > > 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%7C686ea1d3bc2b4c6fa92cd99c5c30 > > 1 > > > > > > > > > > 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 | > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > > > w.pengutronix.de%2F&data=02%7C01%7Canson.huang%40nxp.com%7 > > > > > Cd5d39730435e4b06549c08d696794904%7C686ea1d3bc2b4c6fa92cd99c5c > > 30 > > > > > 1635%7C0%7C0%7C636861845015130502&sdata=tQYrNl5lzIRRNVBCji6 > > A > > > sPREOnIfDgdPWgAnsWyCErg%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 | From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marco Felsch Subject: Re: [PATCH] dt-bindings: imx: update scu resource id headfile Date: Wed, 20 Feb 2019 09:16:50 +0100 Message-ID: <20190220081650.cu3yzausx55jefb6@pengutronix.de> References: <1550566601-11497-1-git-send-email-Anson.Huang@nxp.com> <20190219125211.2pg2bqxner4klcb5@pengutronix.de> <20190219144808.qqpaubjcsb4huoml@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Aisheng Dong Cc: Anson Huang , "robh+dt@kernel.org" , "mark.rutland@arm.com" , "shawnguo@kernel.org" , "s.hauer@pengutronix.de" , "kernel@pengutronix.de" , "festevam@gmail.com" , "ulf.hansson@linaro.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , dl-linux-imx List-Id: devicetree@vger.kernel.org On 19-02-20 03:38, Aisheng Dong wrote: > [...] > > > > 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. > > > > I agree the SCU APIs should be stable since day 1 and the ID should ONLY be > > extended, but that is the best cases, the reality is, there are different > > SoCs/Revision, some revisions may remove the resources ID defined in > > pre-coded SCU firmware, like the IMX_SC_R_DC_0_CAPTURE0 etc., so SCU APIs > > removes them after real silicon arrived, now latest SCU firmware marks them > > as UNUSED, they could be replaced by some other new resources in later new > > SoC, I am NOT sure, but if it happens, this resource ID table should be updated > > anyway, leaving the out-of-date resource ID table there will have issues, since it > > is NOT sync with SCU firmware. > > > > So how to resolve such issue? We hope the SCU firmware should be stable > > since day 1, but the truth is NOT, could be still some updates but NOT very > > often. And I believe the updates will NOT break old kernel version. Hi Anson, Please don't mix the dt-bindings and the kernel related stuff. Unfortunately the bindings are within the kernel repo which in fact is great for us kernel developer but the bindings are also used in other projects such as barebox or other kernels (don't know the BSD guys). So you can't ensure that your change will break something. Please keep that in mind. IMHO solving that issue should be done by the scu firmware. I tought the scu is a cortex-m4 with a bunch of embedded flash and ram (I don't know that much about the scu since it is closed/black-boxed). Why do you don't use a translation table within the scu? As I said earlier I don't like the redefinition of ID's since they are now part of the dt-bindings. The bindings can store up to 32bit values which is a large number ;) IMHO wasting some ID's in favour of stability is a better solution. Regards, Marco > > > > Please double check with SCU firmware owner what the removed ID are used before? > Any side effect if removing them. > > And please also check if the combability can be maintained via IMX_SC_RPC_VERSION? > > Regards > Dong Aisheng > > > Anson. > > > > > > > > Regards, > > > Marco > > > > > > > > > > > Anson. > > > > > > > > > > > > > > Regards, > > > > > Marco > > > > > > > > > > > Signed-off-by: Anson Huang > > > > > > --- > > > > > > 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%7C686ea1d3bc2b4c6fa92cd99c5c30 > > 1 > > > > > > > > > > 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 | > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > > > w.pengutronix.de%2F&data=02%7C01%7Canson.huang%40nxp.com%7 > > > > > Cd5d39730435e4b06549c08d696794904%7C686ea1d3bc2b4c6fa92cd99c5c > > 30 > > > > > 1635%7C0%7C0%7C636861845015130502&sdata=tQYrNl5lzIRRNVBCji6 > > A > > > sPREOnIfDgdPWgAnsWyCErg%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 | From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A915C43381 for ; Wed, 20 Feb 2019 08:17:13 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EC3212070B for ; Wed, 20 Feb 2019 08:17:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YjXnumCE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EC3212070B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fo5xHOvGcu3Q+i/C74eMEuZJxABdX2QqoOXo0MGdcmc=; b=YjXnumCEFCd6/z s/omheA54MIGP0YHNPmdYZgyGdRYlg4xRDL8WastbO7YYmH1Dshp1gR7mkE5HSWYidHxfz+WNkF1X 0kMKvcMb86F8oojifjkZSKCgU2n9MEoV1N3A4t7993nOmZ9oVu8vvgcXFSVNGhJbvqnpD5vbJ1wmH UdKY1gMd//tDr+w6ZjEq4aOQkXXFdETJPb3/qf/i9OI2HYxcFqTn/hP6WMeOFgHgTIsSX8VakPmuF PLsaqohj0ER+moWXSxVt/y7EL7PFtGtFnn23S71SL6C52djtWuNAjM2rpQ3QrTWMCxF2AG/EjRuF+ YM975RqZF8aVt5VeYwQw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gwN3u-0001ia-26; Wed, 20 Feb 2019 08:17:02 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gwN3p-0001i6-KS for linux-arm-kernel@lists.infradead.org; Wed, 20 Feb 2019 08:16:59 +0000 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gwN3k-0005VC-85; Wed, 20 Feb 2019 09:16:52 +0100 Received: from mfe by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1gwN3i-0008ML-Tz; Wed, 20 Feb 2019 09:16:50 +0100 Date: Wed, 20 Feb 2019 09:16:50 +0100 From: Marco Felsch To: Aisheng Dong Subject: Re: [PATCH] dt-bindings: imx: update scu resource id headfile Message-ID: <20190220081650.cu3yzausx55jefb6@pengutronix.de> References: <1550566601-11497-1-git-send-email-Anson.Huang@nxp.com> <20190219125211.2pg2bqxner4klcb5@pengutronix.de> <20190219144808.qqpaubjcsb4huoml@pengutronix.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 08:40:43 up 32 days, 12:22, 38 users, load average: 0.12, 0.04, 0.01 User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: mfe@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190220_001657_834091_F0B7F289 X-CRM114-Status: GOOD ( 23.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "ulf.hansson@linaro.org" , Anson Huang , "festevam@gmail.com" , "s.hauer@pengutronix.de" , "linux-kernel@vger.kernel.org" , "robh+dt@kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , "shawnguo@kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 19-02-20 03:38, Aisheng Dong wrote: > [...] > > > > 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. > > > > I agree the SCU APIs should be stable since day 1 and the ID should ONLY be > > extended, but that is the best cases, the reality is, there are different > > SoCs/Revision, some revisions may remove the resources ID defined in > > pre-coded SCU firmware, like the IMX_SC_R_DC_0_CAPTURE0 etc., so SCU APIs > > removes them after real silicon arrived, now latest SCU firmware marks them > > as UNUSED, they could be replaced by some other new resources in later new > > SoC, I am NOT sure, but if it happens, this resource ID table should be updated > > anyway, leaving the out-of-date resource ID table there will have issues, since it > > is NOT sync with SCU firmware. > > > > So how to resolve such issue? We hope the SCU firmware should be stable > > since day 1, but the truth is NOT, could be still some updates but NOT very > > often. And I believe the updates will NOT break old kernel version. Hi Anson, Please don't mix the dt-bindings and the kernel related stuff. Unfortunately the bindings are within the kernel repo which in fact is great for us kernel developer but the bindings are also used in other projects such as barebox or other kernels (don't know the BSD guys). So you can't ensure that your change will break something. Please keep that in mind. IMHO solving that issue should be done by the scu firmware. I tought the scu is a cortex-m4 with a bunch of embedded flash and ram (I don't know that much about the scu since it is closed/black-boxed). Why do you don't use a translation table within the scu? As I said earlier I don't like the redefinition of ID's since they are now part of the dt-bindings. The bindings can store up to 32bit values which is a large number ;) IMHO wasting some ID's in favour of stability is a better solution. Regards, Marco > > > > Please double check with SCU firmware owner what the removed ID are used before? > Any side effect if removing them. > > And please also check if the combability can be maintained via IMX_SC_RPC_VERSION? > > Regards > Dong Aisheng > > > Anson. > > > > > > > > Regards, > > > Marco > > > > > > > > > > > Anson. > > > > > > > > > > > > > > Regards, > > > > > Marco > > > > > > > > > > > Signed-off-by: Anson Huang > > > > > > --- > > > > > > 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%7C686ea1d3bc2b4c6fa92cd99c5c30 > > 1 > > > > > > > > > > 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 | > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww > > > w.pengutronix.de%2F&data=02%7C01%7Canson.huang%40nxp.com%7 > > > > > Cd5d39730435e4b06549c08d696794904%7C686ea1d3bc2b4c6fa92cd99c5c > > 30 > > > > > 1635%7C0%7C0%7C636861845015130502&sdata=tQYrNl5lzIRRNVBCji6 > > A > > > sPREOnIfDgdPWgAnsWyCErg%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