From: Peter Hurley <peter@hurleysoftware.com> To: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Cc: frowand.list@gmail.com, Mark Rutland <mark.rutland@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Tony Lindgren <tony@atomide.com>, Koen Kooi <koen@dominion.thruhere.net>, Nicolas Ferre <nicolas.ferre@atmel.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Grant Likely <grant.likely@secretlab.ca>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Matt Porter <matt.porter@linaro.org>, Guenter Roeck <linux@roeck-us.net> Subject: Re: [PATCH 2/4] of: DT quirks infrastructure Date: Fri, 20 Feb 2015 11:34:35 -0500 [thread overview] Message-ID: <54E7621B.6040100@hurleysoftware.com> (raw) In-Reply-To: <9EDB5290-5C9F-42C1-826A-B38CC8C01F9B@konsulko.com> On 02/20/2015 10:38 AM, Pantelis Antoniou wrote: > Hi Peter, > >> On Feb 20, 2015, at 17:24 , Peter Hurley <peter@hurleysoftware.com> wrote: >> >> On 02/20/2015 10:02 AM, Pantelis Antoniou wrote: >>> Hi Peter, >>> >>>> On Feb 20, 2015, at 17:00 , Peter Hurley <peter@hurleysoftware.com> wrote: >>>> >>>> On 02/20/2015 09:35 AM, Ludovic Desroches wrote: [...] >>>>> As you said, we can imagine many reasons to have a failure during the >>>>> production, having several DTB files will increase the risk. >>>> >>>> It's interesting that you don't see the added complexity of open-coding >>>> the i2c driver or mixing DTS fragments for different designs as increased risk >>>> (for us all). >>>> >>>> >>> >>> You don’t have to use it. >> >>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile >>> index 5d27dfd..02129e7 100644 >>> --- a/arch/arm/mach-omap2/Makefile >>> +++ b/arch/arm/mach-omap2/Makefile >>> @@ -259,6 +259,11 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o >>> >>> obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o >>> >>> +# DT quirks >>> +ifneq ($(CONFIG_OF_DYNAMIC),) >>> +obj-$(CONFIG_SOC_AM33XX) += am33xx-dt-quirks.o >>> +endif >> >> Won't this automatically be included on my Black that supports DT overlays? >> > > Yes it will. It is a grand total of 498 lines of code, and the total size of > the code segment is about 2.2K. > > You do realize that you’re probably booting a multi-platform kernel on the > black right? Including things for all 2xxx/3xxx and 44xx platforms? > For instance: > >> ~/ti/kernels/linux-github.git $ wc -l arch/arm/mach-omap2/*44xx*.c >> 443 arch/arm/mach-omap2/clockdomains44xx_data.c >> 526 arch/arm/mach-omap2/cminst44xx.c >> 251 arch/arm/mach-omap2/cpuidle44xx.c >> 250 arch/arm/mach-omap2/dpll44xx.c >> 4864 arch/arm/mach-omap2/omap_hwmod_44xx_data.c >> 295 arch/arm/mach-omap2/pm44xx.c >> 358 arch/arm/mach-omap2/powerdomains44xx_data.c >> 62 arch/arm/mach-omap2/prcm_mpu44xx.c >> 770 arch/arm/mach-omap2/prm44xx.c >> 210 arch/arm/mach-omap2/prminst44xx.c >> 117 arch/arm/mach-omap2/vc44xx_data.c >> 130 arch/arm/mach-omap2/voltagedomains44xx_data.c >> 104 arch/arm/mach-omap2/vp44xx_data.c >> 8380 total > > I bet those things are far larger than 2.2K. And I also bet that in the > tradeoff analysis that the board maintainer did things came down to > increasing complexity so that he can consolidate the kernels for all the > other platforms he has to support besides the black. Not that it really matters, but I'm not using any of that. >>> Some people really do though. As for increased risk >>> I expect to see arguments instead of a statement. >> >> No one is wasting your time with random arguments. Please keep your tone civil. >> > > A statement like 'increasing risk for all of us' is very open ended. What is > the risk? How much of it exists? My point was simply that this trades reduced complexity in one area with increased complexity in another area. For you, that trade-off is worth it, but for others, not so much. FWIW, I agree that some mechanism is required to support the other use cases. I just don't think ease of manufacturing, when the submit configuration is the BeagleBone, is where I would hang my hat. > If I offended you I’m really sorry though, I meant no such thing. In re-reading it, I realize I shouldn't have taken offense. Thanks anyway for the apology. Regards, Peter Hurley
WARNING: multiple messages have this Message-ID (diff)
From: peter@hurleysoftware.com (Peter Hurley) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 2/4] of: DT quirks infrastructure Date: Fri, 20 Feb 2015 11:34:35 -0500 [thread overview] Message-ID: <54E7621B.6040100@hurleysoftware.com> (raw) In-Reply-To: <9EDB5290-5C9F-42C1-826A-B38CC8C01F9B@konsulko.com> On 02/20/2015 10:38 AM, Pantelis Antoniou wrote: > Hi Peter, > >> On Feb 20, 2015, at 17:24 , Peter Hurley <peter@hurleysoftware.com> wrote: >> >> On 02/20/2015 10:02 AM, Pantelis Antoniou wrote: >>> Hi Peter, >>> >>>> On Feb 20, 2015, at 17:00 , Peter Hurley <peter@hurleysoftware.com> wrote: >>>> >>>> On 02/20/2015 09:35 AM, Ludovic Desroches wrote: [...] >>>>> As you said, we can imagine many reasons to have a failure during the >>>>> production, having several DTB files will increase the risk. >>>> >>>> It's interesting that you don't see the added complexity of open-coding >>>> the i2c driver or mixing DTS fragments for different designs as increased risk >>>> (for us all). >>>> >>>> >>> >>> You don?t have to use it. >> >>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile >>> index 5d27dfd..02129e7 100644 >>> --- a/arch/arm/mach-omap2/Makefile >>> +++ b/arch/arm/mach-omap2/Makefile >>> @@ -259,6 +259,11 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o >>> >>> obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o >>> >>> +# DT quirks >>> +ifneq ($(CONFIG_OF_DYNAMIC),) >>> +obj-$(CONFIG_SOC_AM33XX) += am33xx-dt-quirks.o >>> +endif >> >> Won't this automatically be included on my Black that supports DT overlays? >> > > Yes it will. It is a grand total of 498 lines of code, and the total size of > the code segment is about 2.2K. > > You do realize that you?re probably booting a multi-platform kernel on the > black right? Including things for all 2xxx/3xxx and 44xx platforms? > For instance: > >> ~/ti/kernels/linux-github.git $ wc -l arch/arm/mach-omap2/*44xx*.c >> 443 arch/arm/mach-omap2/clockdomains44xx_data.c >> 526 arch/arm/mach-omap2/cminst44xx.c >> 251 arch/arm/mach-omap2/cpuidle44xx.c >> 250 arch/arm/mach-omap2/dpll44xx.c >> 4864 arch/arm/mach-omap2/omap_hwmod_44xx_data.c >> 295 arch/arm/mach-omap2/pm44xx.c >> 358 arch/arm/mach-omap2/powerdomains44xx_data.c >> 62 arch/arm/mach-omap2/prcm_mpu44xx.c >> 770 arch/arm/mach-omap2/prm44xx.c >> 210 arch/arm/mach-omap2/prminst44xx.c >> 117 arch/arm/mach-omap2/vc44xx_data.c >> 130 arch/arm/mach-omap2/voltagedomains44xx_data.c >> 104 arch/arm/mach-omap2/vp44xx_data.c >> 8380 total > > I bet those things are far larger than 2.2K. And I also bet that in the > tradeoff analysis that the board maintainer did things came down to > increasing complexity so that he can consolidate the kernels for all the > other platforms he has to support besides the black. Not that it really matters, but I'm not using any of that. >>> Some people really do though. As for increased risk >>> I expect to see arguments instead of a statement. >> >> No one is wasting your time with random arguments. Please keep your tone civil. >> > > A statement like 'increasing risk for all of us' is very open ended. What is > the risk? How much of it exists? My point was simply that this trades reduced complexity in one area with increased complexity in another area. For you, that trade-off is worth it, but for others, not so much. FWIW, I agree that some mechanism is required to support the other use cases. I just don't think ease of manufacturing, when the submit configuration is the BeagleBone, is where I would hang my hat. > If I offended you I?m really sorry though, I meant no such thing. In re-reading it, I realize I shouldn't have taken offense. Thanks anyway for the apology. Regards, Peter Hurley
next prev parent reply other threads:[~2015-02-20 16:34 UTC|newest] Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-18 14:59 [PATCH 0/4] Device Tree Quirks & the Beaglebone Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-18 14:59 ` [PATCH 1/4] arm: of: Add a DT quirk method after unflattening Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-18 14:59 ` [PATCH 2/4] of: DT quirks infrastructure Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-18 15:41 ` Mark Rutland 2015-02-18 15:41 ` Mark Rutland 2015-02-18 15:41 ` Mark Rutland 2015-02-18 15:53 ` Pantelis Antoniou 2015-02-18 15:53 ` Pantelis Antoniou 2015-02-18 15:53 ` Pantelis Antoniou 2015-02-18 16:32 ` Ludovic Desroches 2015-02-18 16:32 ` Ludovic Desroches 2015-02-18 16:32 ` Ludovic Desroches 2015-02-18 16:39 ` Pantelis Antoniou 2015-02-18 16:39 ` Pantelis Antoniou 2015-02-18 16:39 ` Pantelis Antoniou 2015-02-18 16:47 ` Ludovic Desroches 2015-02-18 16:47 ` Ludovic Desroches 2015-02-18 16:47 ` Ludovic Desroches 2015-02-18 16:46 ` Matt Porter 2015-02-18 16:46 ` Matt Porter 2015-02-18 16:46 ` Matt Porter 2015-02-18 17:31 ` Mark Rutland 2015-02-18 17:31 ` Mark Rutland 2015-02-18 17:31 ` Mark Rutland 2015-02-18 19:32 ` Guenter Roeck 2015-02-18 19:32 ` Guenter Roeck 2015-02-18 19:32 ` Guenter Roeck 2015-02-19 14:29 ` Pantelis Antoniou 2015-02-19 14:29 ` Pantelis Antoniou 2015-02-19 14:29 ` Pantelis Antoniou 2015-02-19 16:48 ` Frank Rowand 2015-02-19 16:48 ` Frank Rowand 2015-02-19 16:48 ` Frank Rowand 2015-02-19 17:00 ` Pantelis Antoniou 2015-02-19 17:00 ` Pantelis Antoniou 2015-02-19 17:00 ` Pantelis Antoniou 2015-02-19 17:30 ` Frank Rowand 2015-02-19 17:30 ` Frank Rowand 2015-02-19 17:30 ` Frank Rowand 2015-02-19 17:38 ` Pantelis Antoniou 2015-02-19 17:38 ` Pantelis Antoniou 2015-02-19 17:38 ` Pantelis Antoniou 2015-02-19 18:01 ` Maxime Bizon 2015-02-19 18:01 ` Maxime Bizon 2015-02-19 18:01 ` Maxime Bizon 2015-02-19 18:12 ` Sylvain Rochet 2015-02-19 18:12 ` Sylvain Rochet 2015-02-19 18:12 ` Sylvain Rochet 2015-02-19 18:22 ` Maxime Bizon 2015-02-19 18:22 ` Maxime Bizon 2015-02-19 18:22 ` Maxime Bizon 2015-02-20 14:21 ` Peter Hurley 2015-02-20 14:21 ` Peter Hurley 2015-02-20 14:21 ` Peter Hurley 2015-02-20 14:35 ` Ludovic Desroches 2015-02-20 14:35 ` Ludovic Desroches 2015-02-20 14:35 ` Ludovic Desroches 2015-02-20 15:00 ` Peter Hurley 2015-02-20 15:00 ` Peter Hurley 2015-02-20 15:00 ` Peter Hurley 2015-02-20 15:02 ` Pantelis Antoniou 2015-02-20 15:02 ` Pantelis Antoniou 2015-02-20 15:02 ` Pantelis Antoniou 2015-02-20 15:24 ` Peter Hurley 2015-02-20 15:24 ` Peter Hurley 2015-02-20 15:24 ` Peter Hurley 2015-02-20 15:38 ` Pantelis Antoniou 2015-02-20 15:38 ` Pantelis Antoniou 2015-02-20 15:38 ` Pantelis Antoniou 2015-02-20 16:34 ` Peter Hurley [this message] 2015-02-20 16:34 ` Peter Hurley 2015-02-20 16:34 ` Peter Hurley 2015-02-20 16:49 ` Pantelis Antoniou 2015-02-20 16:49 ` Pantelis Antoniou 2015-02-20 16:49 ` Pantelis Antoniou 2015-02-20 17:30 ` Rob Herring 2015-02-20 17:30 ` Rob Herring 2015-02-20 17:30 ` Rob Herring 2015-02-20 17:37 ` Pantelis Antoniou 2015-02-20 17:37 ` Pantelis Antoniou 2015-02-20 17:37 ` Pantelis Antoniou 2015-02-23 7:00 ` Ludovic Desroches 2015-02-23 7:00 ` Ludovic Desroches 2015-02-23 7:00 ` Ludovic Desroches 2015-02-20 14:38 ` Pantelis Antoniou 2015-02-20 14:38 ` Pantelis Antoniou 2015-02-20 14:38 ` Pantelis Antoniou 2015-02-20 16:47 ` Guenter Roeck 2015-02-20 16:47 ` Guenter Roeck 2015-02-20 16:47 ` Guenter Roeck 2015-02-20 18:09 ` Peter Hurley 2015-02-20 18:09 ` Peter Hurley 2015-02-20 18:09 ` Peter Hurley 2015-02-20 18:48 ` Guenter Roeck 2015-02-20 18:48 ` Guenter Roeck 2015-02-20 18:48 ` Guenter Roeck 2015-02-23 7:30 ` Ludovic Desroches 2015-02-23 7:30 ` Ludovic Desroches 2015-02-23 7:30 ` Ludovic Desroches 2015-02-20 8:04 ` Ludovic Desroches 2015-02-20 8:04 ` Ludovic Desroches 2015-02-20 8:04 ` Ludovic Desroches 2015-02-19 2:08 ` Frank Rowand 2015-02-19 2:08 ` Frank Rowand 2015-02-19 14:41 ` Pantelis Antoniou 2015-02-19 14:41 ` Pantelis Antoniou 2015-02-19 16:40 ` Frank Rowand 2015-02-19 16:40 ` Frank Rowand 2015-02-19 16:51 ` Frank Rowand 2015-02-19 16:51 ` Frank Rowand 2015-02-19 16:51 ` Frank Rowand 2015-02-20 13:23 ` Peter Hurley 2015-02-20 13:23 ` Peter Hurley 2015-02-19 18:01 ` Rob Herring 2015-02-19 18:01 ` Rob Herring 2015-02-19 18:01 ` Rob Herring 2015-02-19 18:12 ` Guenter Roeck 2015-02-19 18:12 ` Guenter Roeck 2015-02-19 18:12 ` Guenter Roeck 2015-02-20 8:16 ` Ludovic Desroches 2015-02-20 8:16 ` Ludovic Desroches 2015-02-20 8:16 ` Ludovic Desroches 2015-02-18 14:59 ` [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-19 18:16 ` Tony Lindgren 2015-02-19 18:16 ` Tony Lindgren 2015-02-19 18:16 ` Tony Lindgren 2015-02-19 18:28 ` Pantelis Antoniou 2015-02-19 18:28 ` Pantelis Antoniou 2015-02-19 18:36 ` Tony Lindgren 2015-02-19 18:36 ` Tony Lindgren 2015-02-19 18:36 ` Tony Lindgren 2015-02-19 18:44 ` Pantelis Antoniou 2015-02-19 18:44 ` Pantelis Antoniou 2015-02-19 18:44 ` Pantelis Antoniou 2015-02-23 18:39 ` Peter Hurley 2015-02-23 18:39 ` Peter Hurley 2015-02-23 18:48 ` Pantelis Antoniou 2015-02-23 18:48 ` Pantelis Antoniou 2015-02-19 18:57 ` Guenter Roeck 2015-02-19 18:57 ` Guenter Roeck 2015-02-20 16:13 ` Jon Hunter 2015-02-20 16:13 ` Jon Hunter 2015-02-18 14:59 ` [PATCH 4/4] arm: dts: Common Black/White Beaglebone DTS using quirks Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou
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=54E7621B.6040100@hurleysoftware.com \ --to=peter@hurleysoftware.com \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=grant.likely@secretlab.ca \ --cc=koen@dominion.thruhere.net \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@roeck-us.net \ --cc=mark.rutland@arm.com \ --cc=matt.porter@linaro.org \ --cc=nicolas.ferre@atmel.com \ --cc=pantelis.antoniou@konsulko.com \ --cc=tony@atomide.com \ /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.