Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 26 Aug 2020 08:24:23 +0200
From:   Andreas Kemnade <andreas@kemnade.info>
To:     Jonathan =?UTF-8?B?TmV1c2Now6RmZXI=?= <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
Message-ID: <20200826082423.6e756fbb@aktux>
In-Reply-To: <20200816125247.GA103070@latitude>
References: <20200815193336.21598-1-andreas@kemnade.info>
        <20200815193336.21598-3-andreas@kemnade.info>
        <20200816125247.GA103070@latitude>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, 16 Aug 2020 14:54:41 +0200
Jonathan Neusch=C3=A4fer <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 ba=
sed
> > on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL
> > SoC.
> >=20
> > Expected to work:
> > - Buttons
> > - Wifi
> > - Touchscreen
> > - LED
> > - uSD
> > - USB
> > - RTC
> >=20
> > Not working due to missing drivers:
> > - Backlight (requires NTXEC driver)
> > - EPD
> >=20
> > Not working due to unknown reasons:
> > - deep sleep (echo standby >/sys/power/state works),
> >   wakeup fails when imx_gpc_pre_suspend(true) was called.
> >=20
> > 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. =20
> [...]
> > +++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> > @@ -0,0 +1,582 @@
> > +// SPDX-License-Identifier: (GPL-2.0) =20
>=20
> I don't think the parentheses are required when you don't have a logical
> operator (OR) in the SPDX expression.
>=20
> > +&i2c1 {
> > +	pinctrl-names =3D "default","sleep";
> > +	pinctrl-0 =3D <&pinctrl_i2c1>;
> > +	pinctrl-1 =3D <&pinctrl_i2c1_sleep>;
> > +	status =3D "okay";
> > +
> > +	/* TODO: embedded controller at 0x43 (driver missing) */ =20
>=20
> Sorry for the delay, BTW. I'm still (slowly) working on v2.
>=20
> > +	ricoh619: pmic@32 {
> > +		compatible =3D "ricoh,rc5t619";
> > +		pinctrl-names =3D "default";
> > +		pinctrl-0 =3D <&pinctrl_ricoh_gpio>;
> > +		reg =3D <0x32>;
> > +		interrupt-parent =3D <&gpio5>;
> > +		interrupts =3D <11 IRQ_TYPE_EDGE_FALLING>;
> > +		system-power-controller;
> > +
> > +		regulators { =20
>=20
> How did you derive the regulator voltages?
>=20
Several sources:
- deriving from the existing device trees,
- looking for board specific variances in
board-mx6sl_ntx.c of the Tolino kernel,=20
- 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 =3D <
> > +			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
> > +		>;
> > +	}; =20
>=20
> Why are there so many hogged pins? Will some of them receive a proper
> configuration once the EPDC driver is implemented?
>=20
I copied them over and found no hints in the
Tolino kernel that it is a bad idea.

Regards,
Andreas