From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754496AbbBTQtg (ORCPT ); Fri, 20 Feb 2015 11:49:36 -0500 Received: from mail-wg0-f49.google.com ([74.125.82.49]:51901 "EHLO mail-wg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754155AbbBTQte convert rfc822-to-8bit (ORCPT ); Fri, 20 Feb 2015 11:49:34 -0500 Subject: Re: [PATCH 2/4] of: DT quirks infrastructure Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 From: Pantelis Antoniou In-Reply-To: <54E7621B.6040100@hurleysoftware.com> Date: Fri, 20 Feb 2015 18:49:28 +0200 Cc: frowand.list@gmail.com, Mark Rutland , "devicetree@vger.kernel.org" , Tony Lindgren , Koen Kooi , Nicolas Ferre , "linux-kernel@vger.kernel.org" , Grant Likely , "linux-arm-kernel@lists.infradead.org" , Matt Porter , Guenter Roeck Content-Transfer-Encoding: 8BIT Message-Id: <886019B3-F60D-4FF5-AA93-EC8D6B68F8C2@konsulko.com> References: <1424271576-1952-3-git-send-email-pantelis.antoniou@konsulko.com> <20150218154106.GC29429@leverpostej> <20150218173115.GG29429@leverpostej> <76BD1B22-BAED-4205-9B34-186907CE0217@konsulko.com> <54E613E7.2020405@gmail.com> <670D0881-DBF0-45E8-A502-A6DB2B77A750@konsulko.com> <54E61DD2.3060002@gmail.com> <53F2F94C-0C43-4A54-B8CD-EEC454A0AC19@konsulko.com> <54E742F2.80506@hurleysoftware.com> <20150220143533.GA29908@odux.rfo.atmel.com> <54E74BF6.208@hurleysoftware.com> <54E751BF.3000604@hurleysoftware.com> <9EDB5290-5C9F-42C1-826A-B38CC8C01F9B@konsulko.com> <54E7621B.6040100@hurleysoftware.com> To: Peter Hurley X-Mailer: Apple Mail (2.2070.6) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, > On Feb 20, 2015, at 18:34 , Peter Hurley wrote: > > On 02/20/2015 10:38 AM, Pantelis Antoniou wrote: >> Hi Peter, >> >>> On Feb 20, 2015, at 17:24 , Peter Hurley wrote: >>> >>> On 02/20/2015 10:02 AM, Pantelis Antoniou wrote: >>>> Hi Peter, >>>> >>>>> On Feb 20, 2015, at 17:00 , Peter Hurley 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. > Of course and that’s the point. No-one is going to remove the vanilla DTSs for the beaglebone black. If you don’t want to use this capability there won’t be any impact. The EEPROM probe is only triggered by the presence of the quirk node, so if you don’t boot with a DTB that contains it there is no change in the boot process. > 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. > The beaglebone is just an open source friendly platform that I can demonstrate the capability. > >> 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 Regards — Pantelis From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pantelis Antoniou Subject: Re: [PATCH 2/4] of: DT quirks infrastructure Date: Fri, 20 Feb 2015 18:49:28 +0200 Message-ID: <886019B3-F60D-4FF5-AA93-EC8D6B68F8C2@konsulko.com> References: <1424271576-1952-3-git-send-email-pantelis.antoniou@konsulko.com> <20150218154106.GC29429@leverpostej> <20150218173115.GG29429@leverpostej> <76BD1B22-BAED-4205-9B34-186907CE0217@konsulko.com> <54E613E7.2020405@gmail.com> <670D0881-DBF0-45E8-A502-A6DB2B77A750@konsulko.com> <54E61DD2.3060002@gmail.com> <53F2F94C-0C43-4A54-B8CD-EEC454A0AC19@konsulko.com> <54E742F2.80506@hurleysoftware.com> <20150220143533.GA29908@odux.rfo.atmel.com> <54E74BF6.208@hurleysoftware.com> <54E751BF.3000604@hurleysoftware.com> <9EDB5290-5C9F-42C1-826A-B38CC8C01F9B@konsulko.com> <54E7621B.6040100@hurleysoftware.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <54E7621B.6040100@hurleysoftware.com> Sender: linux-kernel-owner@vger.kernel.org To: Peter Hurley Cc: frowand.list@gmail.com, Mark Rutland , "devicetree@vger.kernel.org" , Tony Lindgren , Koen Kooi , Nicolas Ferre , "linux-kernel@vger.kernel.org" , Grant Likely , "linux-arm-kernel@lists.infradead.org" , Matt Porter , Guenter Roeck List-Id: devicetree@vger.kernel.org Hi Peter, > On Feb 20, 2015, at 18:34 , Peter Hurley w= rote: >=20 > On 02/20/2015 10:38 AM, Pantelis Antoniou wrote: >> Hi Peter, >>=20 >>> On Feb 20, 2015, at 17:24 , Peter Hurley = wrote: >>>=20 >>> On 02/20/2015 10:02 AM, Pantelis Antoniou wrote: >>>> Hi Peter, >>>>=20 >>>>> On Feb 20, 2015, at 17:00 , Peter Hurley wrote: >>>>>=20 >>>>> On 02/20/2015 09:35 AM, Ludovic Desroches wrote: >=20 > [...] >=20 >>>>>> As you said, we can imagine many reasons to have a failure durin= g the >>>>>> production, having several DTB files will increase the risk. >>>>>=20 >>>>> 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 i= ncreased risk >>>>> (for us all). >>>>>=20 >>>>>=20 >>>>=20 >>>> You don=E2=80=99t have to use it. >>>=20 >>>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Ma= kefile >>>> index 5d27dfd..02129e7 100644 >>>> --- a/arch/arm/mach-omap2/Makefile >>>> +++ b/arch/arm/mach-omap2/Makefile >>>> @@ -259,6 +259,11 @@ obj-$(CONFIG_MACH_CRANEBOARD) +=3D board-am3= 517crane.o >>>>=20 >>>> obj-$(CONFIG_MACH_SBC3530) +=3D board-omap3stalker.o >>>>=20 >>>> +# DT quirks >>>> +ifneq ($(CONFIG_OF_DYNAMIC),) >>>> +obj-$(CONFIG_SOC_AM33XX) +=3D am33xx-dt-quirks.o >>>> +endif >>>=20 >>> Won't this automatically be included on my Black that supports DT o= verlays? >>>=20 >>=20 >> 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. >>=20 >> You do realize that you=E2=80=99re probably booting a multi-platform= kernel on the=20 >> black right? Including things for all 2xxx/3xxx and 44xx platforms? >> For instance: >>=20 >>> ~/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 >>=20 >> 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=20 >> increasing complexity so that he can consolidate the kernels for all= the >> other platforms he has to support besides the black. >=20 > Not that it really matters, but I'm not using any of that. >=20 >=20 >>>> Some people really do though. As for increased risk >>>> I expect to see arguments instead of a statement. >>>=20 >>> No one is wasting your time with random arguments. Please keep your= tone civil. >>>=20 >>=20 >> A statement like 'increasing risk for all of us' is very open ended.= What is >> the risk? How much of it exists? >=20 > My point was simply that this trades reduced complexity in one area > with increased complexity in another area. >=20 > For you, that trade-off is worth it, but for others, not so much. >=20 Of course and that=E2=80=99s the point. No-one is going to remove the v= anilla DTSs for the beaglebone black. If you don=E2=80=99t want to use this ca= pability there won=E2=80=99t be any impact. The EEPROM probe is only triggered by the presence of the quirk node, so if you don=E2=80=99t boot with a DTB that contains it there is no ch= ange in the boot process. > 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. >=20 The beaglebone is just an open source friendly platform that I can demonstrate the capability. >=20 >> If I offended you I=E2=80=99m really sorry though, I meant no such t= hing. >=20 > In re-reading it, I realize I shouldn't have taken offense. Thanks an= yway > for the apology. >=20 > Regards, > Peter Hurley Regards =E2=80=94 Pantelis From mboxrd@z Thu Jan 1 00:00:00 1970 From: pantelis.antoniou@konsulko.com (Pantelis Antoniou) Date: Fri, 20 Feb 2015 18:49:28 +0200 Subject: [PATCH 2/4] of: DT quirks infrastructure In-Reply-To: <54E7621B.6040100@hurleysoftware.com> References: <1424271576-1952-3-git-send-email-pantelis.antoniou@konsulko.com> <20150218154106.GC29429@leverpostej> <20150218173115.GG29429@leverpostej> <76BD1B22-BAED-4205-9B34-186907CE0217@konsulko.com> <54E613E7.2020405@gmail.com> <670D0881-DBF0-45E8-A502-A6DB2B77A750@konsulko.com> <54E61DD2.3060002@gmail.com> <53F2F94C-0C43-4A54-B8CD-EEC454A0AC19@konsulko.com> <54E742F2.80506@hurleysoftware.com> <20150220143533.GA29908@odux.rfo.atmel.com> <54E74BF6.208@hurleysoftware.com> <54E751BF.3000604@hurleysoftware.com> <9EDB5290-5C9F-42C1-826A-B38CC8C01F9B@konsulko.com> <54E7621B.6040100@hurleysoftware.com> Message-ID: <886019B3-F60D-4FF5-AA93-EC8D6B68F8C2@konsulko.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Peter, > On Feb 20, 2015, at 18:34 , Peter Hurley wrote: > > On 02/20/2015 10:38 AM, Pantelis Antoniou wrote: >> Hi Peter, >> >>> On Feb 20, 2015, at 17:24 , Peter Hurley wrote: >>> >>> On 02/20/2015 10:02 AM, Pantelis Antoniou wrote: >>>> Hi Peter, >>>> >>>>> On Feb 20, 2015, at 17:00 , Peter Hurley 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. > Of course and that?s the point. No-one is going to remove the vanilla DTSs for the beaglebone black. If you don?t want to use this capability there won?t be any impact. The EEPROM probe is only triggered by the presence of the quirk node, so if you don?t boot with a DTB that contains it there is no change in the boot process. > 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. > The beaglebone is just an open source friendly platform that I can demonstrate the capability. > >> 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 Regards ? Pantelis