All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.