From: Marco Felsch <m.felsch@pengutronix.de> To: Aisheng Dong <aisheng.dong@nxp.com> Cc: Anson Huang <anson.huang@nxp.com>, "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>, "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: Wed, 20 Feb 2019 11:52:49 +0100 [thread overview] Message-ID: <20190220105249.u2hcvk6ut3cycvqs@pengutronix.de> (raw) In-Reply-To: <AM6PR04MB4215014B734F71D409D617A5807D0@AM6PR04MB4215.eurprd04.prod.outlook.com> Hi Aisheng, On 19-02-20 09:49, Aisheng Dong wrote: > > From: Marco Felsch [mailto:m.felsch@pengutronix.de] > > Sent: Wednesday, February 20, 2019 4:17 PM > > 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. > > > > As far as I know, those remove resource IDs are pre-defined and has never been used > and won't be used anymore by SC firmware. (Anson can double check it) > So I think it's safe to remove them or mark them as deprecated. I think marking them as deprecated by a commentar is better than redefining bits to be unused. As I said the bindings not only linux related they are used in other projects too. > > Personally I may prefer to remove them as they never worked to avoid confusing, > especially at this early stage for mx8. So why they are there if they never worked? Wouldn't it a better approach to start with a basic and working ID file and extend this rather than adding id's because maybe the will work.. Sorry but this seems wrong to me too. I know the approach from driver development, adding a driver specific *_reg.h file and later figuring out that those bits won't work as aspected. As I said this will be driver and only linux related so we can change them as many times as we want. But in your case we are talking about dt-bindings and this approach won't work. Regards, Marco > > Regards > Dong Aisheng > -- 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: Aisheng Dong <aisheng.dong@nxp.com> Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>, Anson Huang <anson.huang@nxp.com>, "festevam@gmail.com" <festevam@gmail.com>, "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>, "shawnguo@kernel.org" <shawnguo@kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH] dt-bindings: imx: update scu resource id headfile Date: Wed, 20 Feb 2019 11:52:49 +0100 [thread overview] Message-ID: <20190220105249.u2hcvk6ut3cycvqs@pengutronix.de> (raw) In-Reply-To: <AM6PR04MB4215014B734F71D409D617A5807D0@AM6PR04MB4215.eurprd04.prod.outlook.com> Hi Aisheng, On 19-02-20 09:49, Aisheng Dong wrote: > > From: Marco Felsch [mailto:m.felsch@pengutronix.de] > > Sent: Wednesday, February 20, 2019 4:17 PM > > 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. > > > > As far as I know, those remove resource IDs are pre-defined and has never been used > and won't be used anymore by SC firmware. (Anson can double check it) > So I think it's safe to remove them or mark them as deprecated. I think marking them as deprecated by a commentar is better than redefining bits to be unused. As I said the bindings not only linux related they are used in other projects too. > > Personally I may prefer to remove them as they never worked to avoid confusing, > especially at this early stage for mx8. So why they are there if they never worked? Wouldn't it a better approach to start with a basic and working ID file and extend this rather than adding id's because maybe the will work.. Sorry but this seems wrong to me too. I know the approach from driver development, adding a driver specific *_reg.h file and later figuring out that those bits won't work as aspected. As I said this will be driver and only linux related so we can change them as many times as we want. But in your case we are talking about dt-bindings and this approach won't work. Regards, Marco > > Regards > Dong Aisheng > -- 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-20 10:52 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 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 [this message] 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=20190220105249.u2hcvk6ut3cycvqs@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: linkBe 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.