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
WARNING: multiple messages have this Message-ID (diff)
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
next prev parent reply other threads:[~2020-08-26 6:25 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: link
Be 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.