From: Andreas Kemnade <andreas@kemnade.info> To: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net> Cc: robh+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com, Anson.Huang@nxp.com, marcel.ziswiler@toradex.com, sebastien.szymanski@armadeus.com, rjones@gateworks.com, leoyang.li@nxp.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, letux-kernel@openphoenux.org Subject: Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD Date: Wed, 26 Aug 2020 08:24:23 +0200 [thread overview] Message-ID: <20200826082423.6e756fbb@aktux> (raw) In-Reply-To: <20200816125247.GA103070@latitude> On Sun, 16 Aug 2020 14:54:41 +0200 Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote: > On Sat, Aug 15, 2020 at 09:33:36PM +0200, Andreas Kemnade wrote: > > This adds a devicetree for the Tolino Shine 2 HD Ebook reader. It is based > > on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL > > SoC. > > > > Expected to work: > > - Buttons > > - Wifi > > - Touchscreen > > - LED > > - uSD > > - USB > > - RTC > > > > Not working due to missing drivers: > > - Backlight (requires NTXEC driver) > > - EPD > > > > Not working due to unknown reasons: > > - deep sleep (echo standby >/sys/power/state works), > > wakeup fails when imx_gpc_pre_suspend(true) was called. > > > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info> > > --- > > Reason for RFC: The suspend trouble might be caused by bad devicetree. > > But as the devicetree is already useful I decided to submit it. > [...] > > +++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts > > @@ -0,0 +1,582 @@ > > +// SPDX-License-Identifier: (GPL-2.0) > > I don't think the parentheses are required when you don't have a logical > operator (OR) in the SPDX expression. > > > +&i2c1 { > > + pinctrl-names = "default","sleep"; > > + pinctrl-0 = <&pinctrl_i2c1>; > > + pinctrl-1 = <&pinctrl_i2c1_sleep>; > > + status = "okay"; > > + > > + /* TODO: embedded controller at 0x43 (driver missing) */ > > Sorry for the delay, BTW. I'm still (slowly) working on v2. > > > + ricoh619: pmic@32 { > > + compatible = "ricoh,rc5t619"; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pinctrl_ricoh_gpio>; > > + reg = <0x32>; > > + interrupt-parent = <&gpio5>; > > + interrupts = <11 IRQ_TYPE_EDGE_FALLING>; > > + system-power-controller; > > + > > + regulators { > > How did you derive the regulator voltages? > Several sources: - deriving from the existing device trees, - looking for board specific variances in board-mx6sl_ntx.c of the Tolino kernel, - looking for comments in the file. I compared a register dump of the PMIC from both the vendor kernel and my devicetree and found no significant differences. > > + pinctrl_hog: hoggrp { > > + fsl,pins = < > > + MX6SL_PAD_LCD_DAT0__GPIO2_IO20 0x79 > > + MX6SL_PAD_LCD_DAT1__GPIO2_IO21 0x79 > > + MX6SL_PAD_LCD_DAT2__GPIO2_IO22 0x79 > > + MX6SL_PAD_LCD_DAT3__GPIO2_IO23 0x79 > > + MX6SL_PAD_LCD_DAT4__GPIO2_IO24 0x79 > > + MX6SL_PAD_LCD_DAT5__GPIO2_IO25 0x79 > > + MX6SL_PAD_LCD_DAT6__GPIO2_IO26 0x79 > > + MX6SL_PAD_LCD_DAT7__GPIO2_IO27 0x79 > > + MX6SL_PAD_LCD_DAT8__GPIO2_IO28 0x79 > > + MX6SL_PAD_LCD_DAT9__GPIO2_IO29 0x79 > > + MX6SL_PAD_LCD_DAT10__GPIO2_IO30 0x79 > > + MX6SL_PAD_LCD_DAT11__GPIO2_IO31 0x79 > > + MX6SL_PAD_LCD_DAT12__GPIO3_IO00 0x79 > > + MX6SL_PAD_LCD_DAT13__GPIO3_IO01 0x79 > > + MX6SL_PAD_LCD_DAT14__GPIO3_IO02 0x79 > > + MX6SL_PAD_LCD_DAT15__GPIO3_IO03 0x79 > > + MX6SL_PAD_LCD_DAT16__GPIO3_IO04 0x79 > > + MX6SL_PAD_LCD_DAT17__GPIO3_IO05 0x79 > > + MX6SL_PAD_LCD_DAT18__GPIO3_IO06 0x79 > > + MX6SL_PAD_LCD_DAT19__GPIO3_IO07 0x79 > > + MX6SL_PAD_LCD_DAT20__GPIO3_IO08 0x79 > > + MX6SL_PAD_LCD_DAT21__GPIO3_IO09 0x79 > > + MX6SL_PAD_LCD_DAT22__GPIO3_IO10 0x79 > > + MX6SL_PAD_LCD_DAT23__GPIO3_IO11 0x79 > > + MX6SL_PAD_LCD_CLK__GPIO2_IO15 0x79 > > + MX6SL_PAD_LCD_ENABLE__GPIO2_IO16 0x79 > > + MX6SL_PAD_LCD_HSYNC__GPIO2_IO17 0x79 > > + MX6SL_PAD_LCD_VSYNC__GPIO2_IO18 0x79 > > + MX6SL_PAD_LCD_RESET__GPIO2_IO19 0x79 > > + MX6SL_PAD_KEY_COL3__GPIO3_IO30 0x79 > > + MX6SL_PAD_KEY_ROW7__GPIO4_IO07 0x79 > > + MX6SL_PAD_ECSPI2_MOSI__GPIO4_IO13 0x79 > > + MX6SL_PAD_KEY_COL5__GPIO4_IO02 0x79 > > + MX6SL_PAD_KEY_ROW6__GPIO4_IO05 0x79 > > + >; > > + }; > > Why are there so many hogged pins? Will some of them receive a proper > configuration once the EPDC driver is implemented? > I copied them over and found no hints in the Tolino kernel that it is a bad idea. Regards, Andreas
WARNING: multiple messages have this Message-ID (diff)
From: Andreas Kemnade <andreas@kemnade.info> To: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net> Cc: devicetree@vger.kernel.org, rjones@gateworks.com, Anson.Huang@nxp.com, marcel.ziswiler@toradex.com, shawnguo@kernel.org, s.hauer@pengutronix.de, linux-kernel@vger.kernel.org, leoyang.li@nxp.com, robh+dt@kernel.org, linux-imx@nxp.com, kernel@pengutronix.de, sebastien.szymanski@armadeus.com, letux-kernel@openphoenux.org, festevam@gmail.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD Date: Wed, 26 Aug 2020 08:24:23 +0200 [thread overview] Message-ID: <20200826082423.6e756fbb@aktux> (raw) In-Reply-To: <20200816125247.GA103070@latitude> On Sun, 16 Aug 2020 14:54:41 +0200 Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote: > On Sat, Aug 15, 2020 at 09:33:36PM +0200, Andreas Kemnade wrote: > > This adds a devicetree for the Tolino Shine 2 HD Ebook reader. It is based > > on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL > > SoC. > > > > Expected to work: > > - Buttons > > - Wifi > > - Touchscreen > > - LED > > - uSD > > - USB > > - RTC > > > > Not working due to missing drivers: > > - Backlight (requires NTXEC driver) > > - EPD > > > > Not working due to unknown reasons: > > - deep sleep (echo standby >/sys/power/state works), > > wakeup fails when imx_gpc_pre_suspend(true) was called. > > > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info> > > --- > > Reason for RFC: The suspend trouble might be caused by bad devicetree. > > But as the devicetree is already useful I decided to submit it. > [...] > > +++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts > > @@ -0,0 +1,582 @@ > > +// SPDX-License-Identifier: (GPL-2.0) > > I don't think the parentheses are required when you don't have a logical > operator (OR) in the SPDX expression. > > > +&i2c1 { > > + pinctrl-names = "default","sleep"; > > + pinctrl-0 = <&pinctrl_i2c1>; > > + pinctrl-1 = <&pinctrl_i2c1_sleep>; > > + status = "okay"; > > + > > + /* TODO: embedded controller at 0x43 (driver missing) */ > > Sorry for the delay, BTW. I'm still (slowly) working on v2. > > > + ricoh619: pmic@32 { > > + compatible = "ricoh,rc5t619"; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pinctrl_ricoh_gpio>; > > + reg = <0x32>; > > + interrupt-parent = <&gpio5>; > > + interrupts = <11 IRQ_TYPE_EDGE_FALLING>; > > + system-power-controller; > > + > > + regulators { > > How did you derive the regulator voltages? > Several sources: - deriving from the existing device trees, - looking for board specific variances in board-mx6sl_ntx.c of the Tolino kernel, - looking for comments in the file. I compared a register dump of the PMIC from both the vendor kernel and my devicetree and found no significant differences. > > + pinctrl_hog: hoggrp { > > + fsl,pins = < > > + MX6SL_PAD_LCD_DAT0__GPIO2_IO20 0x79 > > + MX6SL_PAD_LCD_DAT1__GPIO2_IO21 0x79 > > + MX6SL_PAD_LCD_DAT2__GPIO2_IO22 0x79 > > + MX6SL_PAD_LCD_DAT3__GPIO2_IO23 0x79 > > + MX6SL_PAD_LCD_DAT4__GPIO2_IO24 0x79 > > + MX6SL_PAD_LCD_DAT5__GPIO2_IO25 0x79 > > + MX6SL_PAD_LCD_DAT6__GPIO2_IO26 0x79 > > + MX6SL_PAD_LCD_DAT7__GPIO2_IO27 0x79 > > + MX6SL_PAD_LCD_DAT8__GPIO2_IO28 0x79 > > + MX6SL_PAD_LCD_DAT9__GPIO2_IO29 0x79 > > + MX6SL_PAD_LCD_DAT10__GPIO2_IO30 0x79 > > + MX6SL_PAD_LCD_DAT11__GPIO2_IO31 0x79 > > + MX6SL_PAD_LCD_DAT12__GPIO3_IO00 0x79 > > + MX6SL_PAD_LCD_DAT13__GPIO3_IO01 0x79 > > + MX6SL_PAD_LCD_DAT14__GPIO3_IO02 0x79 > > + MX6SL_PAD_LCD_DAT15__GPIO3_IO03 0x79 > > + MX6SL_PAD_LCD_DAT16__GPIO3_IO04 0x79 > > + MX6SL_PAD_LCD_DAT17__GPIO3_IO05 0x79 > > + MX6SL_PAD_LCD_DAT18__GPIO3_IO06 0x79 > > + MX6SL_PAD_LCD_DAT19__GPIO3_IO07 0x79 > > + MX6SL_PAD_LCD_DAT20__GPIO3_IO08 0x79 > > + MX6SL_PAD_LCD_DAT21__GPIO3_IO09 0x79 > > + MX6SL_PAD_LCD_DAT22__GPIO3_IO10 0x79 > > + MX6SL_PAD_LCD_DAT23__GPIO3_IO11 0x79 > > + MX6SL_PAD_LCD_CLK__GPIO2_IO15 0x79 > > + MX6SL_PAD_LCD_ENABLE__GPIO2_IO16 0x79 > > + MX6SL_PAD_LCD_HSYNC__GPIO2_IO17 0x79 > > + MX6SL_PAD_LCD_VSYNC__GPIO2_IO18 0x79 > > + MX6SL_PAD_LCD_RESET__GPIO2_IO19 0x79 > > + MX6SL_PAD_KEY_COL3__GPIO3_IO30 0x79 > > + MX6SL_PAD_KEY_ROW7__GPIO4_IO07 0x79 > > + MX6SL_PAD_ECSPI2_MOSI__GPIO4_IO13 0x79 > > + MX6SL_PAD_KEY_COL5__GPIO4_IO02 0x79 > > + MX6SL_PAD_KEY_ROW6__GPIO4_IO05 0x79 > > + >; > > + }; > > Why are there so many hogged pins? Will some of them receive a proper > configuration once the EPDC driver is implemented? > I copied them over and found no hints in the Tolino kernel that it is a bad idea. Regards, Andreas _______________________________________________ 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:[~2020-08-26 6:24 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-15 19:33 [PATCH 0/2] ARM: dts: add Tolino Shine 2 HD Andreas Kemnade 2020-08-15 19:33 ` Andreas Kemnade 2020-08-15 19:33 ` [PATCH 1/2] dt-bindings: arm: fsl: add compatible string for " Andreas Kemnade 2020-08-15 19:33 ` Andreas Kemnade 2020-08-25 2:16 ` Rob Herring 2020-08-25 2:16 ` Rob Herring 2020-08-15 19:33 ` [PATCH RFC 2/2] ARM: dts: imx: add devicetree " Andreas Kemnade 2020-08-15 19:33 ` Andreas Kemnade 2020-08-16 12:54 ` Jonathan Neuschäfer 2020-08-16 12:54 ` Jonathan Neuschäfer 2020-08-16 14:50 ` Andreas Kemnade 2020-08-16 14:50 ` Andreas Kemnade 2020-08-16 15:57 ` Jonathan Neuschäfer 2020-08-16 15:57 ` Jonathan Neuschäfer 2020-08-17 5:59 ` Andreas Kemnade 2020-08-17 5:59 ` Andreas Kemnade 2020-08-26 6:24 ` Andreas Kemnade [this message] 2020-08-26 6:24 ` Andreas Kemnade 2020-08-23 1:42 ` Shawn Guo 2020-08-23 1:42 ` Shawn Guo 2020-08-23 16:38 ` Andreas Kemnade 2020-08-23 16:38 ` Andreas Kemnade
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=20200826082423.6e756fbb@aktux \ --to=andreas@kemnade.info \ --cc=Anson.Huang@nxp.com \ --cc=devicetree@vger.kernel.org \ --cc=festevam@gmail.com \ --cc=j.neuschaefer@gmx.net \ --cc=kernel@pengutronix.de \ --cc=leoyang.li@nxp.com \ --cc=letux-kernel@openphoenux.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=marcel.ziswiler@toradex.com \ --cc=rjones@gateworks.com \ --cc=robh+dt@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=sebastien.szymanski@armadeus.com \ --cc=shawnguo@kernel.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.