From mboxrd@z Thu Jan 1 00:00:00 1970 From: marcel.ziswiler@toradex.com (Marcel Ziswiler) Date: Fri, 8 Jan 2016 10:59:20 +0000 Subject: [PATCH v2 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM In-Reply-To: <20160108084247.GB27359@ibawizard.net> References: <1452011942-11940-1-git-send-email-marcel.ziswiler@toradex.com> <1452011942-11940-2-git-send-email-marcel.ziswiler@toradex.com> <20160106080358.GD9030@ibawizard.net> <1452071716.30372.61.camel@toradex.com> <20160108084247.GB27359@ibawizard.net> Message-ID: <1452250758.3357.25.camel@toradex.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, 2016-01-08 at 09:42 +0100, Petr ?tetiar wrote: > Marcel Ziswiler [2016-01-06 09:15:18]: > > > > > <&pinctrl_regulator_usbotg_pwr>; > > > > + regulator-name = "usb_otg_vbus"; > > > > + regulator-min-microvolt = <5000000>; > > > > + regulator-max-microvolt = <5000000>; > > > > + gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>; > > > > + enable-active-high; > > > > + status = "disabled"; > > > > + }; > > > > > > I'm not sure, but it seems to me, that we should move this > > > regulator into > > > the carrier board DTS. On our custom carrier board we've this > > > regulator > > > always on and we use this GPIO for heartbeat LED, so I've this in > > > our > > > carrier board DTS[2]: > > > > Yes, you are absolutely right and e.g. on Apalis T30 [1] that is > > exactly how > > we did it. > > And what about usdhc? It leads to the same overrides in the carrier > board > file: > > &iomuxc { > usdhc { > /* GPIO4_IO20 is LVDS */ > pinctrl_mmc_cd: gpio_mmc_cd { > }; > > /* Used as misc GPIOs */ > pinctrl_usdhc1: usdhc1grp { > }; > }; > }; Yes, the same applies here. > > > > +/* PAD Ctrl values for common settings */ > > > > +/* > > > > + * (PAD_CTL_HYS | PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | > > > > PAD_CTL_PKE > > > > > > > > > + *??PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm) > > > > + */ > > > > +#define PAD_CTRL_HYS_PU 0x1b0b0 > > > > > > This was requested to be reworked. I've simply replaced all the > > > macros with > > > hex values. > > > > I don't think the reviewers really concluded on the action to be > > taken > > on here and just using hex values is probably the most stupid > > solution. > > It's simple, if you just leave it as it is, then it will never get > merged. > That's how kernel development works :) Thanks but I don't think you need to explain us how any of this works (;-p). > We've at least two options here: > > 1. Follow the old path and just convert those macros to hex values Yes, stupid. > 2. Rework it - move those macros to some header file etc. As mentioned before I don't think any agreement has been reached. > -- ynezz Cheers Marcel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcel Ziswiler Subject: Re: [PATCH v2 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM Date: Fri, 8 Jan 2016 10:59:20 +0000 Message-ID: <1452250758.3357.25.camel@toradex.com> References: <1452011942-11940-1-git-send-email-marcel.ziswiler@toradex.com> <1452011942-11940-2-git-send-email-marcel.ziswiler@toradex.com> <20160106080358.GD9030@ibawizard.net> <1452071716.30372.61.camel@toradex.com> <20160108084247.GB27359@ibawizard.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20160108084247.GB27359@ibawizard.net> Content-Language: en-US Content-ID: <9D0F830FB012EE4AA130749F190B69E0@eurprd05.prod.outlook.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: "ynezz@true.cz" Cc: "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "stillcompiling@gmail.com" , "linux@arm.linux.org.uk" , "pawel.moll@arm.com" , "ijc+devicetree@hellion.org.uk" , "shawnguo@kernel.org" , "linux-kernel@vger.kernel.org" , "stefan@agner.ch" , "robh+dt@kernel.org" , "kernel@pengutronix.de" , "galak@codeaurora.org" , "shawn.guo@linaro.org" , "festevam@gmail.com" , "linux-arm-kernel@lists.infradead.org" , "l.stach@pengutronix.de" List-Id: devicetree@vger.kernel.org T24gRnJpLCAyMDE2LTAxLTA4IGF0IDA5OjQyICswMTAwLCBQZXRyIMWgdGV0aWFyIHdyb3RlOg0K PiBNYXJjZWwgWmlzd2lsZXIgPG1hcmNlbC56aXN3aWxlckB0b3JhZGV4LmNvbT4gWzIwMTYtMDEt MDYgMDk6MTU6MThdOg0KPiANCj4gPiA+ID4gPCZwaW5jdHJsX3JlZ3VsYXRvcl91c2JvdGdfcHdy PjsNCj4gPiA+ID4gKwkJCXJlZ3VsYXRvci1uYW1lID0gInVzYl9vdGdfdmJ1cyI7DQo+ID4gPiA+ ICsJCQlyZWd1bGF0b3ItbWluLW1pY3Jvdm9sdCA9IDw1MDAwMDAwPjsNCj4gPiA+ID4gKwkJCXJl Z3VsYXRvci1tYXgtbWljcm92b2x0ID0gPDUwMDAwMDA+Ow0KPiA+ID4gPiArCQkJZ3BpbyA9IDwm Z3BpbzMgMjIgR1BJT19BQ1RJVkVfSElHSD47DQo+ID4gPiA+ICsJCQllbmFibGUtYWN0aXZlLWhp Z2g7DQo+ID4gPiA+ICsJCQlzdGF0dXMgPSAiZGlzYWJsZWQiOw0KPiA+ID4gPiArCQl9Ow0KPiA+ ID4gDQo+ID4gPiBJJ20gbm90IHN1cmUsIGJ1dCBpdCBzZWVtcyB0byBtZSwgdGhhdCB3ZSBzaG91 bGQgbW92ZSB0aGlzDQo+ID4gPiByZWd1bGF0b3IgaW50bw0KPiA+ID4gdGhlIGNhcnJpZXIgYm9h cmQgRFRTLiBPbiBvdXIgY3VzdG9tIGNhcnJpZXIgYm9hcmQgd2UndmUgdGhpcw0KPiA+ID4gcmVn dWxhdG9yDQo+ID4gPiBhbHdheXMgb24gYW5kIHdlIHVzZSB0aGlzIEdQSU8gZm9yIGhlYXJ0YmVh dCBMRUQsIHNvIEkndmUgdGhpcyBpbg0KPiA+ID4gb3VyDQo+ID4gPiBjYXJyaWVyIGJvYXJkIERU U1syXToNCj4gPiANCj4gPiBZZXMsIHlvdSBhcmUgYWJzb2x1dGVseSByaWdodCBhbmQgZS5nLiBv biBBcGFsaXMgVDMwIFsxXSB0aGF0IGlzDQo+ID4gZXhhY3RseSBob3cNCj4gPiB3ZSBkaWQgaXQu DQo+IA0KPiBBbmQgd2hhdCBhYm91dCB1c2RoYz8gSXQgbGVhZHMgdG8gdGhlIHNhbWUgb3ZlcnJp ZGVzIGluIHRoZSBjYXJyaWVyDQo+IGJvYXJkDQo+IGZpbGU6DQo+IA0KPiAmaW9tdXhjIHsNCj4g CXVzZGhjIHsNCj4gCQkvKiBHUElPNF9JTzIwIGlzIExWRFMgKi8NCj4gCQlwaW5jdHJsX21tY19j ZDogZ3Bpb19tbWNfY2Qgew0KPiAJCX07DQo+IA0KPiAJCS8qIFVzZWQgYXMgbWlzYyBHUElPcyAq Lw0KPiAJCXBpbmN0cmxfdXNkaGMxOiB1c2RoYzFncnAgew0KPiAJCX07DQo+IAl9Ow0KPiB9Ow0K DQpZZXMsIHRoZSBzYW1lIGFwcGxpZXMgaGVyZS4NCg0KPiA+ID4gPiArLyogUEFEIEN0cmwgdmFs dWVzIGZvciBjb21tb24gc2V0dGluZ3MgKi8NCj4gPiA+ID4gKy8qDQo+ID4gPiA+ICsgKiAoUEFE X0NUTF9IWVMgfCBQQURfQ1RMX1BVU18xMDBLX1VQIHwgUEFEX0NUTF9QVUUgfA0KPiA+ID4gPiBQ QURfQ1RMX1BLRQ0KPiA+ID4gPiA+IA0KPiA+ID4gPiArICrCoMKgUEFEX0NUTF9TUEVFRF9NRUQg fCBQQURfQ1RMX0RTRV80MG9obSkNCj4gPiA+ID4gKyAqLw0KPiA+ID4gPiArI2RlZmluZSBQQURf Q1RSTF9IWVNfUFUgMHgxYjBiMA0KPiA+ID4gDQo+ID4gPiBUaGlzIHdhcyByZXF1ZXN0ZWQgdG8g YmUgcmV3b3JrZWQuIEkndmUgc2ltcGx5IHJlcGxhY2VkIGFsbCB0aGUNCj4gPiA+IG1hY3JvcyB3 aXRoDQo+ID4gPiBoZXggdmFsdWVzLg0KPiA+IA0KPiA+IEkgZG9uJ3QgdGhpbmsgdGhlIHJldmll d2VycyByZWFsbHkgY29uY2x1ZGVkIG9uIHRoZSBhY3Rpb24gdG8gYmUNCj4gPiB0YWtlbg0KPiA+ IG9uIGhlcmUgYW5kIGp1c3QgdXNpbmcgaGV4IHZhbHVlcyBpcyBwcm9iYWJseSB0aGUgbW9zdCBz dHVwaWQNCj4gPiBzb2x1dGlvbi4NCj4gDQo+IEl0J3Mgc2ltcGxlLCBpZiB5b3UganVzdCBsZWF2 ZSBpdCBhcyBpdCBpcywgdGhlbiBpdCB3aWxsIG5ldmVyIGdldA0KPiBtZXJnZWQuDQo+IFRoYXQn cyBob3cga2VybmVsIGRldmVsb3BtZW50IHdvcmtzIDopDQoNClRoYW5rcyBidXQgSSBkb24ndCB0 aGluayB5b3UgbmVlZCB0byBleHBsYWluIHVzIGhvdyBhbnkgb2YgdGhpcyB3b3Jrcw0KKDstcCku DQoNCj4gIFdlJ3ZlIGF0IGxlYXN0IHR3byBvcHRpb25zIGhlcmU6DQo+IA0KPiAxLiBGb2xsb3cg dGhlIG9sZCBwYXRoIGFuZCBqdXN0IGNvbnZlcnQgdGhvc2UgbWFjcm9zIHRvIGhleCB2YWx1ZXMN Cg0KWWVzLCBzdHVwaWQuDQoNCj4gMi4gUmV3b3JrIGl0IC0gbW92ZSB0aG9zZSBtYWNyb3MgdG8g c29tZSBoZWFkZXIgZmlsZSBldGMuDQoNCkFzIG1lbnRpb25lZCBiZWZvcmUgSSBkb24ndCB0aGlu ayBhbnkgYWdyZWVtZW50IGhhcyBiZWVuIHJlYWNoZWQuDQoNCj4gLS0geW5lenoNCg0KDQpDaGVl cnMNCg0KTWFyY2VsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3Rz LmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5m by9saW51eC1hcm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932174AbcAHLOG (ORCPT ); Fri, 8 Jan 2016 06:14:06 -0500 Received: from mail-db3on0148.outbound.protection.outlook.com ([157.55.234.148]:33764 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932137AbcAHLOD (ORCPT ); Fri, 8 Jan 2016 06:14:03 -0500 From: Marcel Ziswiler To: "ynezz@true.cz" CC: "linux-kernel@vger.kernel.org" , "shawn.guo@linaro.org" , "pawel.moll@arm.com" , "stefan@agner.ch" , "robh+dt@kernel.org" , "devicetree@vger.kernel.org" , "festevam@gmail.com" , "mark.rutland@arm.com" , "stillcompiling@gmail.com" , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , "shawnguo@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "l.stach@pengutronix.de" , "kernel@pengutronix.de" , "linux@arm.linux.org.uk" Subject: Re: [PATCH v2 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM Thread-Topic: [PATCH v2 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM Thread-Index: AQHRSgOgbCBbCHVQIEmvgfJiRFAhaQ== Date: Fri, 8 Jan 2016 10:59:20 +0000 Message-ID: <1452250758.3357.25.camel@toradex.com> References: <1452011942-11940-1-git-send-email-marcel.ziswiler@toradex.com> <1452011942-11940-2-git-send-email-marcel.ziswiler@toradex.com> <20160106080358.GD9030@ibawizard.net> <1452071716.30372.61.camel@toradex.com> <20160108084247.GB27359@ibawizard.net> In-Reply-To: <20160108084247.GB27359@ibawizard.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcel.ziswiler@toradex.com; x-originating-ip: [84.227.37.153] x-microsoft-exchange-diagnostics: 1;VI1PR05MB0976;5:JnoPKdhwPG7uKRUZ9+I8dYsU4NLDbPLTQcN3cK2g6ZewhzsnEecuBi/QXVsHihH3d7/cASRUNcURaLExZB3nzlSqebzZxACI6OJgoHbJUwDaK3paSFkwtrJDFF7RA+CcuDIS3NEuAiRzgpzv0d060w==;24:1HxjrnReD7bb+hDjvnar5p6hddpHe/VvB42hZg8N6GLgTNaxdy4qMoKGnyIwXrKyNIo2b4rJ2CeEWZtkGQMcC0k+qeSumC089vbjdF2Y5EI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR05MB0976; x-ms-office365-filtering-correlation-id: a9086b0c-207f-4e29-d613-08d3181ac2ea x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(90676262408878); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001);SRVR:VI1PR05MB0976;BCL:0;PCL:0;RULEID:;SRVR:VI1PR05MB0976; x-forefront-prvs: 0815F8251E x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(199003)(377424004)(24454002)(189002)(106356001)(106116001)(105586002)(102836003)(3846002)(19580405001)(19580395003)(6116002)(1096002)(1220700001)(1730700002)(586003)(87936001)(5008740100001)(189998001)(103116003)(110136002)(93886004)(5001960100002)(11100500001)(81156007)(101416001)(5004730100002)(97736004)(2351001)(86362001)(40100003)(33646002)(54356999)(76176999)(575784001)(50986999)(2501003)(4326007)(2900100001)(2906002)(2950100001)(36756003)(5250100002)(92566002)(66066001)(5002640100001)(32563001)(473944003);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR05MB0976;H:VI1PR05MB0974.eurprd05.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9D0F830FB012EE4AA130749F190B69E0@eurprd05.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: toradex.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2016 10:59:20.4789 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d9995866-0d9b-4251-8315-093f062abab4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB0976 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u08BECkL016987 On Fri, 2016-01-08 at 09:42 +0100, Petr Štetiar wrote: > Marcel Ziswiler [2016-01-06 09:15:18]: > > > > > <&pinctrl_regulator_usbotg_pwr>; > > > > + regulator-name = "usb_otg_vbus"; > > > > + regulator-min-microvolt = <5000000>; > > > > + regulator-max-microvolt = <5000000>; > > > > + gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>; > > > > + enable-active-high; > > > > + status = "disabled"; > > > > + }; > > > > > > I'm not sure, but it seems to me, that we should move this > > > regulator into > > > the carrier board DTS. On our custom carrier board we've this > > > regulator > > > always on and we use this GPIO for heartbeat LED, so I've this in > > > our > > > carrier board DTS[2]: > > > > Yes, you are absolutely right and e.g. on Apalis T30 [1] that is > > exactly how > > we did it. > > And what about usdhc? It leads to the same overrides in the carrier > board > file: > > &iomuxc { > usdhc { > /* GPIO4_IO20 is LVDS */ > pinctrl_mmc_cd: gpio_mmc_cd { > }; > > /* Used as misc GPIOs */ > pinctrl_usdhc1: usdhc1grp { > }; > }; > }; Yes, the same applies here. > > > > +/* PAD Ctrl values for common settings */ > > > > +/* > > > > + * (PAD_CTL_HYS | PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | > > > > PAD_CTL_PKE > > > > > > > > > + *  PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm) > > > > + */ > > > > +#define PAD_CTRL_HYS_PU 0x1b0b0 > > > > > > This was requested to be reworked. I've simply replaced all the > > > macros with > > > hex values. > > > > I don't think the reviewers really concluded on the action to be > > taken > > on here and just using hex values is probably the most stupid > > solution. > > It's simple, if you just leave it as it is, then it will never get > merged. > That's how kernel development works :) Thanks but I don't think you need to explain us how any of this works (;-p). > We've at least two options here: > > 1. Follow the old path and just convert those macros to hex values Yes, stupid. > 2. Rework it - move those macros to some header file etc. As mentioned before I don't think any agreement has been reached. > -- ynezz Cheers Marcel