Linux Serial subsystem development
 help / color / mirror / Atom feed
* Re: [PATCH v4 6/7] ARM: dts: meson8: switch to new bindings for UART nodes
From: Neil Armstrong @ 2017-06-12  7:27 UTC (permalink / raw)
  To: Martin Blumenstingl
  Cc: gregkh, khilman, devicetree, linux-kernel, hgkr.klein,
	linux-serial, linux-amlogic, linux-arm-kernel
In-Reply-To: <CAFBinCBNhRtt8jiY+19_B-9_mNmB800rvD+rwBzYNfB5pXM53Q@mail.gmail.com>

On 06/11/2017 10:18 PM, Martin Blumenstingl wrote:
> On Sat, Jun 10, 2017 at 12:37 AM, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
>> Hi Neil,
>>
>> On Fri, Jun 9, 2017 at 11:49 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>> Switch to the stable UART bindings by adding a XTAL node and using the
>>> proper compatible strings.
>> unfortunately this won't apply now that Kevin has merged my "ARM: dts:
>> meson8: add and use the real clock controller"
>> on the other hand this will make the patch easier as you can now do
>> the same changes as in meson8b.dtsi
> Neil, if you want you could also drop this from your series and let me
> handle this (just let me know). I would even go one step further and
> export the CLKID_UART0, CLKID_UART1 and CLKID_UART2 gates and pass
> them as "pclk" for uart_{A,B,C}
> I'll even *try* to test if this works on real hardware (my Meson8m2
> board has a RTL8723BS SDIO wifi + bluetooth chip - wifi driver support
> has been pretty bad so far - but I'll try to see if I can get and
> messages out of the bluetooth part)
> just let me know if you want me to handle this patch for you


No in fact it was just a "PoC" to show how to handle it on non-gx DTS.

I'm ok to leave it to you when the UART code is merged.

Neil

> 
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>>  arch/arm/boot/dts/meson8.dtsi | 23 +++++++++++++++++++----
>>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
>>> index 6993077..a2ea112 100644
>>> --- a/arch/arm/boot/dts/meson8.dtsi
>>> +++ b/arch/arm/boot/dts/meson8.dtsi
>>> @@ -83,6 +83,13 @@
>>>                 };
>>>         };
>>>
>>> +       xtal: xtal-clk {
>>> +               compatible = "fixed-clock";
>>> +               clock-frequency = <24000000>;
>>> +               clock-output-names = "xtal";
>>> +               #clock-cells = <0>;
>>> +       };
>>> +
>>>         clk81: clk@0 {
>>>                 #clock-cells = <0>;
>>>                 compatible = "fixed-clock";
>>> @@ -199,17 +206,25 @@
>>>  };
>>>
>>>  &uart_AO {
>>> -       clocks = <&clk81>;
>>> +       compatible = "amlogic,meson8-uart", "amlogic,meson-ao-uart";
>>> +       clocks = <&xtal>, <&clk81>, <&clk81>;
>>> +       clock-names = "xtal", "pclk", "baud";
>>>  };
>>>
>>>  &uart_A {
>>> -       clocks = <&clk81>;
>>> +       compatible = "amlogic,meson8-uart";
>>> +       clocks = <&xtal>, <&clk81>, <&clk81>;
>>> +       clock-names = "xtal", "pclk", "baud";
>>>  };
>>>
>>>  &uart_B {
>>> -       clocks = <&clk81>;
>>> +       compatible = "amlogic,meson8-uart";
>>> +       clocks = <&xtal>, <&clk81>, <&clk81>;
>>> +       clock-names = "xtal", "pclk", "baud";
>>>  };
>>>
>>>  &uart_C {
>>> -       clocks = <&clk81>;
>>> +       compatible = "amlogic,meson8-uart";
>>> +       clocks = <&xtal>, <&clk81>, <&clk81>;
>>> +       clock-names = "xtal", "pclk", "baud";
>>>  };
>>> --
>>> 1.9.1
>>>
>>>
>>> _______________________________________________
>>> linux-amlogic mailing list
>>> linux-amlogic@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-amlogic

^ permalink raw reply

* Re: [RFC, PATCH] imx: serial: Take tty->files_lock opportunistically
From: Greg Kroah-Hartman @ 2017-06-12  6:46 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Peter Senna Tschudin, Alan Cox, Rob Herring, Andrey Smirnov,
	linux-serial@vger.kernel.org, Chris Healy, Jiri Slaby,
	linux-kernel@vger.kernel.org
In-Reply-To: <CAOMZO5A_hLkuQkmfQFmCmLtCFimf0i70WbtYMr0o811vpreKbA@mail.gmail.com>

On Sun, Jun 11, 2017 at 09:33:13PM -0300, Fabio Estevam wrote:
> Hi Greg,
> 
> On Sat, Jun 3, 2017 at 6:30 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, May 30, 2017 at 03:44:27PM +0200, Peter Senna Tschudin wrote:
> >> On Tue, May 30, 2017 at 02:42:13PM +0100, Alan Cox wrote:
> >>
> >> I sent a second patch recently:
> >>
> >> https://patchwork.kernel.org/patch/9725625/
> >
> > And it's already in linux-next so all should be good here.
> 
> linux-next is good, but mainline is not.
> 
> Actually we need 4dec2f119e86f9c9 ("imx-serial: RX DMA startup
> latency") to be applied to 4.12-rc as well.

Why?  Can't it wait until 4.13-rc1?

thanks,

greg k-h

^ permalink raw reply

* Re: [RFC, PATCH] imx: serial: Take tty->files_lock opportunistically
From: Fabio Estevam @ 2017-06-12  0:33 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Peter Senna Tschudin, Alan Cox, Rob Herring, Andrey Smirnov,
	linux-serial@vger.kernel.org, Chris Healy, Jiri Slaby,
	linux-kernel@vger.kernel.org
In-Reply-To: <20170603093048.GA9120@kroah.com>

Hi Greg,

On Sat, Jun 3, 2017 at 6:30 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, May 30, 2017 at 03:44:27PM +0200, Peter Senna Tschudin wrote:
>> On Tue, May 30, 2017 at 02:42:13PM +0100, Alan Cox wrote:
>>
>> I sent a second patch recently:
>>
>> https://patchwork.kernel.org/patch/9725625/
>
> And it's already in linux-next so all should be good here.

linux-next is good, but mainline is not.

Actually we need 4dec2f119e86f9c9 ("imx-serial: RX DMA startup
latency") to be applied to 4.12-rc as well.

Thanks

^ permalink raw reply

* Re: [PATCH v4 6/7] ARM: dts: meson8: switch to new bindings for UART nodes
From: Martin Blumenstingl @ 2017-06-11 20:18 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	khilman-rdvid1DuHRBWk0Htik3J/w, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	hgkr.klein-Re5JQEeQqe8AvxtiuMwx3w,
	linux-serial-u79uwXL29TY76Z2rM5mHXA,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAFBinCD6_nGdqBSOJwyj0XQe8H05nw-r52pctY7ADJu0EqMb2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Sat, Jun 10, 2017 at 12:37 AM, Martin Blumenstingl
<martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> Hi Neil,
>
> On Fri, Jun 9, 2017 at 11:49 AM, Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
>> Switch to the stable UART bindings by adding a XTAL node and using the
>> proper compatible strings.
> unfortunately this won't apply now that Kevin has merged my "ARM: dts:
> meson8: add and use the real clock controller"
> on the other hand this will make the patch easier as you can now do
> the same changes as in meson8b.dtsi
Neil, if you want you could also drop this from your series and let me
handle this (just let me know). I would even go one step further and
export the CLKID_UART0, CLKID_UART1 and CLKID_UART2 gates and pass
them as "pclk" for uart_{A,B,C}
I'll even *try* to test if this works on real hardware (my Meson8m2
board has a RTL8723BS SDIO wifi + bluetooth chip - wifi driver support
has been pretty bad so far - but I'll try to see if I can get and
messages out of the bluetooth part)
just let me know if you want me to handle this patch for you

>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>>  arch/arm/boot/dts/meson8.dtsi | 23 +++++++++++++++++++----
>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
>> index 6993077..a2ea112 100644
>> --- a/arch/arm/boot/dts/meson8.dtsi
>> +++ b/arch/arm/boot/dts/meson8.dtsi
>> @@ -83,6 +83,13 @@
>>                 };
>>         };
>>
>> +       xtal: xtal-clk {
>> +               compatible = "fixed-clock";
>> +               clock-frequency = <24000000>;
>> +               clock-output-names = "xtal";
>> +               #clock-cells = <0>;
>> +       };
>> +
>>         clk81: clk@0 {
>>                 #clock-cells = <0>;
>>                 compatible = "fixed-clock";
>> @@ -199,17 +206,25 @@
>>  };
>>
>>  &uart_AO {
>> -       clocks = <&clk81>;
>> +       compatible = "amlogic,meson8-uart", "amlogic,meson-ao-uart";
>> +       clocks = <&xtal>, <&clk81>, <&clk81>;
>> +       clock-names = "xtal", "pclk", "baud";
>>  };
>>
>>  &uart_A {
>> -       clocks = <&clk81>;
>> +       compatible = "amlogic,meson8-uart";
>> +       clocks = <&xtal>, <&clk81>, <&clk81>;
>> +       clock-names = "xtal", "pclk", "baud";
>>  };
>>
>>  &uart_B {
>> -       clocks = <&clk81>;
>> +       compatible = "amlogic,meson8-uart";
>> +       clocks = <&xtal>, <&clk81>, <&clk81>;
>> +       clock-names = "xtal", "pclk", "baud";
>>  };
>>
>>  &uart_C {
>> -       clocks = <&clk81>;
>> +       compatible = "amlogic,meson8-uart";
>> +       clocks = <&xtal>, <&clk81>, <&clk81>;
>> +       clock-names = "xtal", "pclk", "baud";
>>  };
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-amlogic mailing list
>> linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v4 6/7] ARM: dts: meson8: switch to new bindings for UART nodes
From: Martin Blumenstingl @ 2017-06-09 22:37 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	khilman-rdvid1DuHRBWk0Htik3J/w, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	hgkr.klein-Re5JQEeQqe8AvxtiuMwx3w,
	linux-serial-u79uwXL29TY76Z2rM5mHXA,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1497001756-942-7-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Hi Neil,

On Fri, Jun 9, 2017 at 11:49 AM, Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Switch to the stable UART bindings by adding a XTAL node and using the
> proper compatible strings.
unfortunately this won't apply now that Kevin has merged my "ARM: dts:
meson8: add and use the real clock controller"
on the other hand this will make the patch easier as you can now do
the same changes as in meson8b.dtsi

> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>  arch/arm/boot/dts/meson8.dtsi | 23 +++++++++++++++++++----
>  1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
> index 6993077..a2ea112 100644
> --- a/arch/arm/boot/dts/meson8.dtsi
> +++ b/arch/arm/boot/dts/meson8.dtsi
> @@ -83,6 +83,13 @@
>                 };
>         };
>
> +       xtal: xtal-clk {
> +               compatible = "fixed-clock";
> +               clock-frequency = <24000000>;
> +               clock-output-names = "xtal";
> +               #clock-cells = <0>;
> +       };
> +
>         clk81: clk@0 {
>                 #clock-cells = <0>;
>                 compatible = "fixed-clock";
> @@ -199,17 +206,25 @@
>  };
>
>  &uart_AO {
> -       clocks = <&clk81>;
> +       compatible = "amlogic,meson8-uart", "amlogic,meson-ao-uart";
> +       clocks = <&xtal>, <&clk81>, <&clk81>;
> +       clock-names = "xtal", "pclk", "baud";
>  };
>
>  &uart_A {
> -       clocks = <&clk81>;
> +       compatible = "amlogic,meson8-uart";
> +       clocks = <&xtal>, <&clk81>, <&clk81>;
> +       clock-names = "xtal", "pclk", "baud";
>  };
>
>  &uart_B {
> -       clocks = <&clk81>;
> +       compatible = "amlogic,meson8-uart";
> +       clocks = <&xtal>, <&clk81>, <&clk81>;
> +       clock-names = "xtal", "pclk", "baud";
>  };
>
>  &uart_C {
> -       clocks = <&clk81>;
> +       compatible = "amlogic,meson8-uart";
> +       clocks = <&xtal>, <&clk81>, <&clk81>;
> +       clock-names = "xtal", "pclk", "baud";
>  };
> --
> 1.9.1
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH v6 10/10] serial: exar: Add support for IOT2040 device
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1497033197.git.jan.kiszka@siemens.com>

This implements the setup of RS232 and the switch-over to RS485 or RS422
for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic
to switch between the different modes. The external logic is controlled
via MPIO pins of the EXAR controller.

Only pin 10 can be exported as GPIO on the IOT2040. It is connected to
an LED.

As the XR17V352 used on the IOT2040 is not equipped with an external
EEPROM, it cannot present itself as IOT2040-variant via subvendor/
subdevice IDs. Thus, we have to check via DMI for the target platform.

Co-developed with Sascha Weisenberger.

Signed-off-by: Sascha Weisenberger <sascha.weisenberger@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 drivers/tty/serial/8250/8250_exar.c | 129 +++++++++++++++++++++++++++++++++++-
 1 file changed, 128 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 95c6e24ebff1..6dfa7b86501f 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -10,6 +10,7 @@
  * the Free Software Foundation; either version 2 of the License.
  */
 #include <linux/acpi.h>
+#include <linux/dmi.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
@@ -62,6 +63,43 @@
 #define UART_EXAR_MPIOSEL_15_8	0x99	/* MPIOSEL[15:8] */
 #define UART_EXAR_MPIOOD_15_8	0x9a	/* MPIOOD[15:8] */
 
+#define UART_EXAR_RS485_DLY(x)	((x) << 4)
+
+/*
+ * IOT2040 MPIO wiring semantics:
+ *
+ * MPIO		Port	Function
+ * ----		----	--------
+ * 0		2 	Mode bit 0
+ * 1		2	Mode bit 1
+ * 2		2	Terminate bus
+ * 3		-	<reserved>
+ * 4		3	Mode bit 0
+ * 5		3	Mode bit 1
+ * 6		3	Terminate bus
+ * 7		-	<reserved>
+ * 8		2	Enable
+ * 9		3	Enable
+ * 10		-	Red LED
+ * 11..15	-	<unused>
+ */
+
+/* IOT2040 MPIOs 0..7 */
+#define IOT2040_UART_MODE_RS232		0x01
+#define IOT2040_UART_MODE_RS485		0x02
+#define IOT2040_UART_MODE_RS422		0x03
+#define IOT2040_UART_TERMINATE_BUS	0x04
+
+#define IOT2040_UART1_MASK		0x0f
+#define IOT2040_UART2_SHIFT		4
+
+#define IOT2040_UARTS_DEFAULT_MODE	0x11	/* both RS232 */
+#define IOT2040_UARTS_GPIO_LO_MODE	0x88	/* reserved pins as input */
+
+/* IOT2040 MPIOs 8..15 */
+#define IOT2040_UARTS_ENABLE		0x03
+#define IOT2040_UARTS_GPIO_HI_MODE	0xF8	/* enable & LED as outputs */
+
 struct exar8250;
 
 struct exar8250_platform {
@@ -243,18 +281,107 @@ static const struct exar8250_platform exar8250_default_platform = {
 	.register_gpio = xr17v35x_register_gpio,
 };
 
+static int iot2040_rs485_config(struct uart_port *port,
+				struct serial_rs485 *rs485)
+{
+	bool is_rs485 = !!(rs485->flags & SER_RS485_ENABLED);
+	u8 __iomem *p = port->membase;
+	u8 mask = IOT2040_UART1_MASK;
+	u8 mode, value;
+
+	if (is_rs485) {
+		if (rs485->flags & SER_RS485_RX_DURING_TX)
+			mode = IOT2040_UART_MODE_RS422;
+		else
+			mode = IOT2040_UART_MODE_RS485;
+
+		if (rs485->flags & SER_RS485_TERMINATE_BUS)
+			mode |= IOT2040_UART_TERMINATE_BUS;
+	} else {
+		mode = IOT2040_UART_MODE_RS232;
+	}
+
+	if (port->line == 3) {
+		mask <<= IOT2040_UART2_SHIFT;
+		mode <<= IOT2040_UART2_SHIFT;
+	}
+
+	value = readb(p + UART_EXAR_MPIOLVL_7_0);
+	value &= ~mask;
+	value |= mode;
+	writeb(value, p + UART_EXAR_MPIOLVL_7_0);
+
+	value = readb(p + UART_EXAR_FCTR);
+	if (is_rs485)
+		value |= UART_FCTR_EXAR_485;
+	else
+		value &= ~UART_FCTR_EXAR_485;
+	writeb(value, p + UART_EXAR_FCTR);
+
+	if (is_rs485)
+		writeb(UART_EXAR_RS485_DLY(4), p + UART_MSR);
+
+	port->rs485 = *rs485;
+
+	return 0;
+}
+
+static const struct property_entry iot2040_gpio_properties[] = {
+	PROPERTY_ENTRY_U32("linux,first-pin", 10),
+	PROPERTY_ENTRY_U32("ngpios", 1),
+	{ }
+};
+
+static int iot2040_register_gpio(struct pci_dev *pcidev,
+			      struct uart_8250_port *port)
+{
+	u8 __iomem *p = port->port.membase;
+
+	writeb(IOT2040_UARTS_DEFAULT_MODE, p + UART_EXAR_MPIOLVL_7_0);
+	writeb(IOT2040_UARTS_GPIO_LO_MODE, p + UART_EXAR_MPIOSEL_7_0);
+	writeb(IOT2040_UARTS_ENABLE, p + UART_EXAR_MPIOLVL_15_8);
+	writeb(IOT2040_UARTS_GPIO_HI_MODE, p + UART_EXAR_MPIOSEL_15_8);
+
+	port->port.private_data =
+		__xr17v35x_register_gpio(pcidev, iot2040_gpio_properties);
+
+	return 0;
+}
+
+static const struct exar8250_platform iot2040_platform = {
+	.rs485_config = iot2040_rs485_config,
+	.register_gpio = iot2040_register_gpio,
+};
+
+static const struct dmi_system_id exar_platforms[] = {
+	{
+		.matches = {
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+			DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+					"6ES7647-0AA00-1YA2"),
+		},
+		.driver_data = (void *)&iot2040_platform,
+	},
+	{}
+};
+
 static int
 pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
 		   struct uart_8250_port *port, int idx)
 {
 	const struct exar8250_board *board = priv->board;
 	const struct exar8250_platform *platform;
+	const struct dmi_system_id *dmi_match;
 	unsigned int offset = idx * 0x400;
 	unsigned int baud = 7812500;
 	u8 __iomem *p;
 	int ret;
 
-	platform = &exar8250_default_platform;
+	dmi_match = dmi_first_match(exar_platforms);
+	if (dmi_match)
+		platform = dmi_match->driver_data;
+	else
+		platform = &exar8250_default_platform;
 
 	port->port.uartclk = baud * 16;
 	port->port.rs485_config = platform->rs485_config;
-- 
2.12.3

^ permalink raw reply related

* [PATCH v6 09/10] gpio-exar/8250-exar: Make set of exported GPIOs configurable
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1497033197.git.jan.kiszka@siemens.com>

On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the
rest is required to operate the UART. To allow modeling this case,
expand the platform device data structure to specify a (consecutive) pin
subset for exporting by the gpio-exar driver.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 drivers/gpio/gpio-exar.c            | 56 ++++++++++++++++++++++---------------
 drivers/tty/serial/8250/8250_exar.c | 15 ++++++++--
 2 files changed, 45 insertions(+), 26 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 1a629831d45b..fb8d304cfa17 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -31,6 +31,7 @@ struct exar_gpio_chip {
 	int index;
 	void __iomem *regs;
 	char name[20];
+	unsigned int first_pin;
 };
 
 static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
@@ -51,11 +52,12 @@ static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
 static int exar_set_direction(struct gpio_chip *chip, int direction,
 			      unsigned int offset)
 {
-	unsigned int bank = offset / 8;
-	unsigned int addr;
+	struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+	unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
+		EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
+	unsigned int bit  = (offset + exar_gpio->first_pin) % 8;
 
-	addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
-	exar_update(chip, addr, direction, offset % 8);
+	exar_update(chip, addr, direction, bit);
 	return 0;
 }
 
@@ -73,36 +75,33 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg)
 
 static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
 {
-	unsigned int bank = offset / 8;
-	unsigned int addr;
-	int val;
-
-	addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
-	val = exar_get(chip, addr) & BIT(offset % 8);
+	struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+	unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
+		EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
+	unsigned int bit  = (offset + exar_gpio->first_pin) % 8;
 
-	return !!val;
+	return !!(exar_get(chip, addr) & BIT(bit));
 }
 
 static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
 {
-	unsigned int bank = offset / 8;
-	unsigned int addr;
-	int val;
-
-	addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
-	val = exar_get(chip, addr) & BIT(offset % 8);
+	struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+	unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
+		EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
+	unsigned int bit  = (offset + exar_gpio->first_pin) % 8;
 
-	return !!val;
+	return !!(exar_get(chip, addr) & BIT(bit));
 }
 
 static void exar_set_value(struct gpio_chip *chip, unsigned int offset,
 			   int value)
 {
-	unsigned int bank = offset / 8;
-	unsigned int addr;
+	struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+	unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
+		EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
+	unsigned int bit  = (offset + exar_gpio->first_pin) % 8;
 
-	addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
-	exar_update(chip, addr, value, offset % 8);
+	exar_update(chip, addr, value, bit);
 }
 
 static int exar_direction_output(struct gpio_chip *chip, unsigned int offset,
@@ -121,6 +120,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
 {
 	struct pci_dev *pcidev = to_pci_dev(pdev->dev.parent);
 	struct exar_gpio_chip *exar_gpio;
+	u32 first_pin, ngpios;
 	void __iomem *p;
 	int index, ret;
 
@@ -132,6 +132,15 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	if (!p)
 		return -ENOMEM;
 
+	ret = device_property_read_u32(&pdev->dev, "linux,first-pin",
+				       &first_pin);
+	if (ret)
+		return ret;
+
+	ret = device_property_read_u32(&pdev->dev, "ngpios", &ngpios);
+	if (ret)
+		return ret;
+
 	exar_gpio = devm_kzalloc(&pdev->dev, sizeof(*exar_gpio), GFP_KERNEL);
 	if (!exar_gpio)
 		return -ENOMEM;
@@ -149,9 +158,10 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	exar_gpio->gpio_chip.get = exar_get_value;
 	exar_gpio->gpio_chip.set = exar_set_value;
 	exar_gpio->gpio_chip.base = -1;
-	exar_gpio->gpio_chip.ngpio = 16;
+	exar_gpio->gpio_chip.ngpio = ngpios;
 	exar_gpio->regs = p;
 	exar_gpio->index = index;
+	exar_gpio->first_pin = first_pin;
 
 	ret = devm_gpiochip_add_data(&pdev->dev,
 				     &exar_gpio->gpio_chip, exar_gpio);
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 1106f1f58c77..95c6e24ebff1 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -14,6 +14,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/pci.h>
+#include <linux/property.h>
 #include <linux/serial_core.h>
 #include <linux/serial_reg.h>
 #include <linux/slab.h>
@@ -201,7 +202,8 @@ static void setup_gpio(struct pci_dev *pcidev, u8 __iomem *p)
 }
 
 static void *
-__xr17v35x_register_gpio(struct pci_dev *pcidev)
+__xr17v35x_register_gpio(struct pci_dev *pcidev,
+			 const struct property_entry *properties)
 {
 	struct platform_device *pdev;
 
@@ -212,7 +214,8 @@ __xr17v35x_register_gpio(struct pci_dev *pcidev)
 	pdev->dev.parent = &pcidev->dev;
 	ACPI_COMPANION_SET(&pdev->dev, ACPI_COMPANION(&pcidev->dev));
 
-	if (platform_device_add(pdev) < 0) {
+	if (platform_device_add_properties(pdev, properties) < 0 ||
+	    platform_device_add(pdev) < 0) {
 		platform_device_put(pdev);
 		return NULL;
 	}
@@ -220,12 +223,18 @@ __xr17v35x_register_gpio(struct pci_dev *pcidev)
 	return pdev;
 }
 
+static const struct property_entry exar_gpio_properties[] = {
+	PROPERTY_ENTRY_U32("linux,first-pin", 0),
+	PROPERTY_ENTRY_U32("ngpios", 16),
+	{ }
+};
+
 static int xr17v35x_register_gpio(struct pci_dev *pcidev,
 				  struct uart_8250_port *port)
 {
 	if (pcidev->vendor == PCI_VENDOR_ID_EXAR)
 		port->port.private_data =
-			__xr17v35x_register_gpio(pcidev);
+			__xr17v35x_register_gpio(pcidev, exar_gpio_properties);
 
 	return 0;
 }
-- 
2.12.3

^ permalink raw reply related

* [PATCH v6 08/10] platform: Accept const properties
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1497033197.git.jan.kiszka@siemens.com>

Aligns us with device_add_properties, the function we call.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 drivers/base/platform.c         | 2 +-
 include/linux/platform_device.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index a102152301c8..71ea6f4d33c2 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -344,7 +344,7 @@ EXPORT_SYMBOL_GPL(platform_device_add_data);
  * platform device is released.
  */
 int platform_device_add_properties(struct platform_device *pdev,
-				   struct property_entry *properties)
+				   const struct property_entry *properties)
 {
 	return device_add_properties(&pdev->dev, properties);
 }
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 98c2a7c7108e..49f634d96118 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -172,7 +172,7 @@ extern int platform_device_add_resources(struct platform_device *pdev,
 extern int platform_device_add_data(struct platform_device *pdev,
 				    const void *data, size_t size);
 extern int platform_device_add_properties(struct platform_device *pdev,
-					  struct property_entry *properties);
+				const struct property_entry *properties);
 extern int platform_device_add(struct platform_device *pdev);
 extern void platform_device_del(struct platform_device *pdev);
 extern void platform_device_put(struct platform_device *pdev);
-- 
2.12.3

^ permalink raw reply related

* [PATCH v6 07/10] serial: exar: Factor out platform hooks
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1497033197.git.jan.kiszka@siemens.com>

This prepares the addition of IOT2040 platform support by preparing the
needed setup and rs485_config hooks.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 drivers/tty/serial/8250/8250_exar.c | 32 +++++++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index ee4b142f3ed0..1106f1f58c77 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -63,6 +63,11 @@
 
 struct exar8250;
 
+struct exar8250_platform {
+	int (*rs485_config)(struct uart_port *, struct serial_rs485 *);
+	int (*register_gpio)(struct pci_dev *, struct uart_8250_port *);
+};
+
 /**
  * struct exar8250_board - board information
  * @num_ports: number of serial ports
@@ -196,7 +201,7 @@ static void setup_gpio(struct pci_dev *pcidev, u8 __iomem *p)
 }
 
 static void *
-xr17v35x_register_gpio(struct pci_dev *pcidev)
+__xr17v35x_register_gpio(struct pci_dev *pcidev)
 {
 	struct platform_device *pdev;
 
@@ -215,17 +220,36 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
 	return pdev;
 }
 
+static int xr17v35x_register_gpio(struct pci_dev *pcidev,
+				  struct uart_8250_port *port)
+{
+	if (pcidev->vendor == PCI_VENDOR_ID_EXAR)
+		port->port.private_data =
+			__xr17v35x_register_gpio(pcidev);
+
+	return 0;
+}
+
+static const struct exar8250_platform exar8250_default_platform = {
+	.register_gpio = xr17v35x_register_gpio,
+};
+
 static int
 pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
 		   struct uart_8250_port *port, int idx)
 {
 	const struct exar8250_board *board = priv->board;
+	const struct exar8250_platform *platform;
 	unsigned int offset = idx * 0x400;
 	unsigned int baud = 7812500;
 	u8 __iomem *p;
 	int ret;
 
+	platform = &exar8250_default_platform;
+
 	port->port.uartclk = baud * 16;
+	port->port.rs485_config = platform->rs485_config;
+
 	/*
 	 * Setup the uart clock for the devices on expansion slot to
 	 * half the clock speed of the main chip (which is 125MHz)
@@ -248,12 +272,10 @@ pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
 		/* Setup Multipurpose Input/Output pins. */
 		setup_gpio(pcidev, p);
 
-		if (pcidev->vendor == PCI_VENDOR_ID_EXAR)
-			port->port.private_data =
-				xr17v35x_register_gpio(pcidev);
+		ret = platform->register_gpio(pcidev, port);
 	}
 
-	return 0;
+	return ret;
 }
 
 static void pci_xr17v35x_exit(struct pci_dev *pcidev)
-- 
2.12.3

^ permalink raw reply related

* [PATCH v6 06/10] gpio-exar/8250-exar: Rearrange gpiochip parenthood
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1497033197.git.jan.kiszka@siemens.com>

Set the parent of the exar gpiochip to its platform device, like other
gpiochips are doing it. In order to keep the relationship discoverable
for ACPI systems, set the platform device companion to the PCI device.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpio/gpio-exar.c            | 2 +-
 drivers/tty/serial/8250/8250_exar.c | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index f3585a184f39..1a629831d45b 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -142,7 +142,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
 
 	sprintf(exar_gpio->name, "exar_gpio%d", index);
 	exar_gpio->gpio_chip.label = exar_gpio->name;
-	exar_gpio->gpio_chip.parent = &pcidev->dev;
+	exar_gpio->gpio_chip.parent = &pdev->dev;
 	exar_gpio->gpio_chip.direction_output = exar_direction_output;
 	exar_gpio->gpio_chip.direction_input = exar_direction_input;
 	exar_gpio->gpio_chip.get_direction = exar_get_direction;
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 0f4b236d7e68..ee4b142f3ed0 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -9,6 +9,7 @@
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License.
  */
+#include <linux/acpi.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
@@ -204,6 +205,7 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
 		return NULL;
 
 	pdev->dev.parent = &pcidev->dev;
+	ACPI_COMPANION_SET(&pdev->dev, ACPI_COMPANION(&pcidev->dev));
 
 	if (platform_device_add(pdev) < 0) {
 		platform_device_put(pdev);
-- 
2.12.3

^ permalink raw reply related

* [PATCH v6 05/10] gpio: exar: Fix reading of directions and values
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1497033197.git.jan.kiszka@siemens.com>

First, the logic for translating a register bit to the return code of
exar_get_direction and exar_get_value were wrong. And second, there was
a flip regarding the register bank in exar_get_direction.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpio/gpio-exar.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index b29890b143ce..f3585a184f39 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg)
 	value = readb(exar_gpio->regs + reg);
 	mutex_unlock(&exar_gpio->lock);
 
-	return !!value;
+	return value;
 }
 
 static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
@@ -78,7 +78,7 @@ static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
 	int val;
 
 	addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
-	val = exar_get(chip, addr) >> (offset % 8);
+	val = exar_get(chip, addr) & BIT(offset % 8);
 
 	return !!val;
 }
@@ -89,8 +89,8 @@ static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
 	unsigned int addr;
 	int val;
 
-	addr = bank ? EXAR_OFFSET_MPIOLVL_LO : EXAR_OFFSET_MPIOLVL_HI;
-	val = exar_get(chip, addr) >> (offset % 8);
+	addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
+	val = exar_get(chip, addr) & BIT(offset % 8);
 
 	return !!val;
 }
-- 
2.12.3


^ permalink raw reply related

* [PATCH v6 04/10] gpio: exar: Fix iomap request
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1497033197.git.jan.kiszka@siemens.com>

The UART driver already maps the resource for us. Trying to do this here
only fails and leaves us with a non-working device.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpio/gpio-exar.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 65126fa1e512..b29890b143ce 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -125,14 +125,10 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	int index, ret;
 
 	/*
-	 * Map the pci device to get the register addresses.
-	 * We will need to read and write those registers to control
-	 * the GPIO pins.
-	 * Using managed functions will save us from unmaping on exit.
-	 * As the device is enabled using managed functions by the
-	 * UART driver we can also use managed functions here.
+	 * The UART driver must have mapped region 0 prior to registering this
+	 * device - use it.
 	 */
-	p = pcim_iomap(pcidev, 0, 0);
+	p = pcim_iomap_table(pcidev)[0];
 	if (!p)
 		return -ENOMEM;
 
-- 
2.12.3

^ permalink raw reply related

* [PATCH v6 03/10] gpio: exar: Allocate resources on behalf of the platform device
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1497033197.git.jan.kiszka@siemens.com>

Do not allocate resources on behalf of the parent device but on our own.
Otherwise, cleanup does not properly work if gpio-exar is removed but
not the parent device.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpio/gpio-exar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index da4550bb9939..65126fa1e512 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -136,7 +136,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	if (!p)
 		return -ENOMEM;
 
-	exar_gpio = devm_kzalloc(&pcidev->dev, sizeof(*exar_gpio), GFP_KERNEL);
+	exar_gpio = devm_kzalloc(&pdev->dev, sizeof(*exar_gpio), GFP_KERNEL);
 	if (!exar_gpio)
 		return -ENOMEM;
 
@@ -157,7 +157,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	exar_gpio->regs = p;
 	exar_gpio->index = index;
 
-	ret = devm_gpiochip_add_data(&pcidev->dev,
+	ret = devm_gpiochip_add_data(&pdev->dev,
 				     &exar_gpio->gpio_chip, exar_gpio);
 	if (ret)
 		goto err_destroy;
-- 
2.12.3


^ permalink raw reply related

* [PATCH v6 02/10] gpio-exar/8250-exar: Fix passing in of parent PCI device
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1497033197.git.jan.kiszka@siemens.com>

This fixes reloading of the GPIO driver for the same platform device
instance as created by the exar UART driver: First of all, the driver
sets drvdata to its own value during probing and does not restore the
original value on exit. But this won't help anyway as the core clears
drvdata after the driver left.

Set the platform device parent instead.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/gpio/gpio-exar.c            | 2 +-
 drivers/tty/serial/8250/8250_exar.c | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 006a9a67c2a4..da4550bb9939 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -119,7 +119,7 @@ static int exar_direction_input(struct gpio_chip *chip, unsigned int offset)
 
 static int gpio_exar_probe(struct platform_device *pdev)
 {
-	struct pci_dev *pcidev = platform_get_drvdata(pdev);
+	struct pci_dev *pcidev = to_pci_dev(pdev->dev.parent);
 	struct exar_gpio_chip *exar_gpio;
 	void __iomem *p;
 	int index, ret;
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index c29c7e675890..0f4b236d7e68 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -203,7 +203,8 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
 	if (!pdev)
 		return NULL;
 
-	platform_set_drvdata(pdev, pcidev);
+	pdev->dev.parent = &pcidev->dev;
+
 	if (platform_device_add(pdev) < 0) {
 		platform_device_put(pdev);
 		return NULL;
-- 
2.12.3

^ permalink raw reply related

* [PATCH v6 01/10] gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger
In-Reply-To: <cover.1497033197.git.jan.kiszka@siemens.com>

Commtech adapters need the MPIOs for internal purposes, and the
gpio-exar driver already refused to pick them up. But there is actually
no point in even creating the underlying platform device.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpio/gpio-exar.c            | 3 ---
 drivers/tty/serial/8250/8250_exar.c | 4 +++-
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 081076771217..006a9a67c2a4 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -124,9 +124,6 @@ static int gpio_exar_probe(struct platform_device *pdev)
 	void __iomem *p;
 	int index, ret;
 
-	if (pcidev->vendor != PCI_VENDOR_ID_EXAR)
-		return -ENODEV;
-
 	/*
 	 * Map the pci device to get the register addresses.
 	 * We will need to read and write those registers to control
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 8984e8b2d524..c29c7e675890 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -245,7 +245,9 @@ pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
 		/* Setup Multipurpose Input/Output pins. */
 		setup_gpio(pcidev, p);
 
-		port->port.private_data = xr17v35x_register_gpio(pcidev);
+		if (pcidev->vendor == PCI_VENDOR_ID_EXAR)
+			port->port.private_data =
+				xr17v35x_register_gpio(pcidev);
 	}
 
 	return 0;
-- 
2.12.3

^ permalink raw reply related

* [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000
From: Jan Kiszka @ 2017-06-09 18:33 UTC (permalink / raw)
  To: Linus Walleij, Alexandre Courbot
  Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, linux-serial,
	linux-gpio, Sudip Mukherjee, Andy Shevchenko, Sascha Weisenberger

This makes the gpio-exar driver usable, which was prevented by a number
of fatal bugs, and adds support for the SIMATIC IOT2040 to the 8250-exar
driver and, indirectly, to gpio-exar as well. It's a cross-subsystem
series, so I'm also cross-posting to the serial and gpio lists.

Changes in v6:
 - addressed Andy's remarks on "Make set of exported GPIOs configurable"
 - dropped "Leave MPIOs as output for Commtech adapters" - merged by Greg

Jan

Jan Kiszka (10):
  gpio-exar/8250-exar: Do not even instantiate a GPIO device for
    Commtech cards
  gpio-exar/8250-exar: Fix passing in of parent PCI device
  gpio: exar: Allocate resources on behalf of the platform device
  gpio: exar: Fix iomap request
  gpio: exar: Fix reading of directions and values
  gpio-exar/8250-exar: Rearrange gpiochip parenthood
  serial: exar: Factor out platform hooks
  platform: Accept const properties
  gpio-exar/8250-exar: Make set of exported GPIOs configurable
  serial: exar: Add support for IOT2040 device

 drivers/base/platform.c             |   2 +-
 drivers/gpio/gpio-exar.c            |  79 ++++++++--------
 drivers/tty/serial/8250/8250_exar.c | 173 ++++++++++++++++++++++++++++++++++--
 include/linux/platform_device.h     |   2 +-
 4 files changed, 211 insertions(+), 45 deletions(-)

-- 
2.12.3

^ permalink raw reply

* Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate calculation method
From: Andy Shevchenko @ 2017-06-09 15:48 UTC (permalink / raw)
  To: A.S. Dong
  Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm Mailing List, Greg Kroah-Hartman, Jiri Slaby, Andy Duan,
	Stefan Agner, Mingkai Hu, Y.B. Lu, Dong Aisheng
In-Reply-To: <AM3PR04MB30678CBD87777C6816DEFA580CE0@AM3PR04MB306.eurprd04.prod.outlook.com>

On Fri, Jun 9, 2017 at 5:20 PM, A.S. Dong <aisheng.dong@nxp.com> wrote:
>> > How about you send a separate baud algorithm improvement patch later?
>>
>> Why not to do it right a way?
>>
>
> Because I thought that could be a separate patch which is doing algorithm
> improvement, then we can have the full history and a clear comparison.
>
> And also we are still not sure whether it works, we don't want to block on it
> too long.
>
> But if you're pretty sure about it, I would wait for some more time.
>
> However, personally I would still rather keep them in two separate Patches
> for clearer history and comparison.

Since we already near to -rc5, I would rather agree with you.
So, please proceed with your approach and we can modify it in relaxing
mode later on.

Thanks, and sorry for the delay!

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply

* Re: [PATCH v2 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile
From: Marc Zyngier @ 2017-06-09 14:44 UTC (permalink / raw)
  To: YT Shen, Matthias Brugger
  Cc: Rob Herring, Mark Rutland, Thomas Gleixner, Jason Cooper,
	Greg Kroah-Hartman, Catalin Marinas, Will Deacon, Mars Cheng,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-serial-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	srv_heupstream-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <1497016569.29586.36.camel@mtksdaap41>

On 09/06/17 14:56, YT Shen wrote:
> On Wed, 2017-05-31 at 14:42 +0200, Matthias Brugger wrote:

[...]

>>> +		cpu0: cpu@0 {
>>> +			device_type = "cpu";
>>> +			compatible = "arm,cortex-a35";
>>
>> do you mean cortex-a53?
> No, the cpu is cortex-a35.
> Although I cannot find other cortex-a35 description in mainline kernel.

We usually don't keep track of individual cores if we don't need to
(errata workarounds, for example). And for the record, here's some blurb
about Cortex-A35:

https://www.arm.com/products/processors/cortex-a/cortex-a35-processor.php

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* RE: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate calculation method
From: A.S. Dong @ 2017-06-09 14:20 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm Mailing List, Greg Kroah-Hartman, Jiri Slaby, Andy Duan,
	Stefan Agner, Mingkai Hu, Y.B. Lu, Dong Aisheng
In-Reply-To: <CAHp75VcSToSfbUZ2TP0OsLRjV4TNpq7D_=4tnB_+rDvS2jp22Q@mail.gmail.com>

> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Friday, June 09, 2017 5:26 PM
> To: A.S. Dong
> Cc: linux-serial@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm
> Mailing List; Greg Kroah-Hartman; Jiri Slaby; Andy Duan; Stefan Agner;
> Mingkai Hu; Y.B. Lu; Dong Aisheng
> Subject: Re: [PATCH 6/6] tty: serial: lpuart: add a more accurate baud
> rate calculation method
> 
> On Fri, Jun 9, 2017 at 11:01 AM, A.S. Dong <aisheng.dong@nxp.com> wrote:
> 
> >> >> > +       u32 sbr, osr, baud_diff, tmp_osr, tmp_sbr, tmp_diff, tmp;
> >> >> > +       u32 clk = sport->port.uartclk;
> >> >> > +
> >> >> > +       /*
> >> >> > +        * The idea is to use the best OSR (over-sampling rate)
> >> possible.
> >> >> > +        * Note, OSR is typically hard-set to 16 in other LPUART
> >> >> instantiations.
> >> >> > +        * Loop to find the best OSR value possible, one that
> >> >> > + generates
> >> >> minimum
> >> >> > +        * baud_diff iterate through the rest of the supported
> >> >> > + values of
> >> >> OSR.
> >> >> > +        *
> >> >> > +        * Calculation Formula:
> >> >> > +        *  Baud Rate = baud clock / ((OSR+1) × SBR)
> >> >> > +        */
> >> >> > +       baud_diff = baudrate;
> >> >> > +       osr = 0;
> >> >> > +       sbr = 0;
> >> >> > +
> >> >>
> >> >> > +       for (tmp_osr = 4; tmp_osr <= 32; tmp_osr++) {
> >>
> >> I missed one thing, what happened by default to OSR? What is the
> >> value in use?
> >>
> >
> > No valid default value. (osc/sbr are 0 by default) If no proper osc
> > and sbr calculated, a WARNING will show.
> 
> Okay, so, it means the maximum supported speed is UART clock / 4. Correct?
> 

Yes.

> >> So, the algo is the following:
> >>
> >> Assume the ranges like this:
> >> OSR = [4 ... 32]
> >> SBR = [2 ... 8192]
> >>
> >
> > Baud Rate = baud clock / ((OSR+1) × SBR)
> >
> > In HW:
> > OSR range : 3 – 31
> > SBR range: 1 – 8191
> 
> I've read that, but think outside the box.
> 
> >> Then:
> >>
> >> 1. Get ratio factor as
> >>       ratio = CLK / desired baud rate 2. If ratio < 8192 * 9 / 2,
> >> just use (ratio / 4, 4) as (OSR, SBR) setting.
> >> (Needs clarification on OSR < 4)
> >
> > Sorry that I'm a bit mess here.
> > What is 8192 * 9 /2 meaning?
> 
> I forgot the details...
> 
> > And for (ratio / 4, 4) as (OSR,SBR), take 115200 as an example:
> > Assuming baud clock 24Mhz.
> >
> > Ratio = 24000000 / 115200 = 208
> > OSR = Ratio / 4 = 52
> > Then OSR is out of range which seems wrong.
> 
> ...yes...
> 
> >> 3. if ratio >= 8192 * 31, just use those two numbers (8192, 31). You
> >> can't do anything better there.
> >
> > This actually may not happen.
> > Even take a 9600 as example, the clk becomes:
> > 8191 * 31 * 9600 = 2.4GHz
> > Which is theoretically not exist.
> >
> >> 4. Otherwise, get a minimum required factor of OSR
> >>       osr_min = ratio / 8192
> >> 5. Start your loop from osr_min + 1 to 31.
> >>
> >> 6 (optional). Of course you may not consider baud_diff > osr_min,
> >> it's I suppose obvious
> >>
> >> P.S. Note, all divisions by 2^n are just simple right shifts. Diffs
> >> are calculated as multiplication of OSR and SBR in comparison to
> >> ratio. One division so far.
> 
> > I'm not quite understand the approach.
> 
> ...lemme prepare a python script demonstrating it.
> 

Great, thanks

> > How about you send a separate baud algorithm improvement patch later?
> 
> Why not to do it right a way?
> 

Because I thought that could be a separate patch which is doing algorithm
improvement, then we can have the full history and a clear comparison.

And also we are still not sure whether it works, we don't want to block on it
too long.

But if you're pretty sure about it, I would wait for some more time.

However, personally I would still rather keep them in two separate Patches
for clearer history and comparison.

> Just describe it in a comment if you afraid of reader can't understand
> from the code.
> 

That is good.

Regards
Dong Aisheng

> --
> With Best Regards,
> Andy Shevchenko

^ permalink raw reply

* Re: [PATCH v2 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile
From: YT Shen @ 2017-06-09 13:56 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: Rob Herring, Mark Rutland, Thomas Gleixner, Jason Cooper,
	Marc Zyngier, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
	Mars Cheng, devicetree, linux-kernel, linux-serial,
	linux-arm-kernel, linux-mediatek, srv_heupstream
In-Reply-To: <92e438b3-4e9c-421b-5398-5aad2541524c@gmail.com>

On Wed, 2017-05-31 at 14:42 +0200, Matthias Brugger wrote:
> 
> On 31/05/17 13:39, YT Shen wrote:
> > This adds basic chip support for Mediatek 2712
> > 
> > Signed-off-by: YT Shen <yt.shen@mediatek.com>
> > ---
> >   arch/arm64/boot/dts/mediatek/Makefile       |   1 +
> >   arch/arm64/boot/dts/mediatek/mt2712-evb.dts |  39 +++++++
> >   arch/arm64/boot/dts/mediatek/mt2712e.dtsi   | 166 ++++++++++++++++++++++++++++
> >   3 files changed, 206 insertions(+)
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-evb.dts
> >   create mode 100644 arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> > index 9fbfd32..fcc0604 100644
> > --- a/arch/arm64/boot/dts/mediatek/Makefile
> > +++ b/arch/arm64/boot/dts/mediatek/Makefile
> > @@ -1,3 +1,4 @@
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
> >   dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> > diff --git a/arch/arm64/boot/dts/mediatek/mt2712-evb.dts b/arch/arm64/boot/dts/mediatek/mt2712-evb.dts
> > new file mode 100644
> > index 0000000..e526c0f
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt2712-evb.dts
> > @@ -0,0 +1,39 @@
> > +/*
> > + * Copyright (c) 2017 MediaTek Inc.
> > + * Author: YT Shen <yt.shen@mediatek.com>
> > + *
> > + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt2712e.dtsi"
> > +
> > +/ {
> > +	model = "MediaTek MT2712 evaluation board";
> > +	compatible = "mediatek,mt2712-evb", "mediatek,mt2712";
> > +
> > +	aliases {
> > +		serial0 = &uart0;
> > +		serial1 = &uart1;
> > +		serial2 = &uart2;
> > +		serial3 = &uart3;
> > +		serial4 = &uart4;
> > +		serial5 = &uart5;
> > +	};
> 
> Just declare serial0 here, as you don't use the others.
Ok, will remove the others.

Sorry for the late reply.

> > +
> > +	memory@40000000 {
> > +		device_type = "memory";
> > +		reg = <0 0x40000000 0 0x80000000>;
> > +	};
> > +
> > +	chosen {
> > +		stdout-path = "serial0:921600n8";
> > +		linux,initrd-start = <0x45000000>;
> > +		linux,initrd-end   = <0x4a000000>;
> 
> initrd-start and end should be dynamically set by the bootloader and not 
> via a chosen node. Is your bootloader not able to do that?
OK, will remove initrd start and end later.
Yes, current bootloader I used is new development and it does not send
any parameters now

> 
> > +	};
> > +};
> > +
> > +&uart0 {
> > +	status = "okay";
> > +};
> > +
> > diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> > new file mode 100644
> > index 0000000..6df0da9
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> > @@ -0,0 +1,166 @@
> > +/*
> > + * Copyright (c) 2017 MediaTek Inc.
> > + * Author: YT Shen <yt.shen@mediatek.com>
> > + *
> > + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > + */
> > +
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > +	compatible = "mediatek,mt2712";
> > +	interrupt-parent = <&sysirq>;
> > +	#address-cells = <2>;
> > +	#size-cells = <2>;
> > +
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		cpu-map {
> > +			cluster0 {
> > +				core0 {
> > +					cpu = <&cpu0>;
> > +				};
> > +				core1 {
> > +					cpu = <&cpu1>;
> > +				};
> > +			};
> > +
> > +			cluster1 {
> > +				core0 {
> > +					cpu = <&cpu2>;
> > +				};
> > +			};
> > +		};
> > +
> > +		cpu0: cpu@0 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a35";
> 
> do you mean cortex-a53?
No, the cpu is cortex-a35.
Although I cannot find other cortex-a35 description in mainline kernel.

Thanks for the review.

yt.shen

> 
> > +			reg = <0x000>;
> > +		};
> > +
> > +		cpu1: cpu@1 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a35";
> 
> same here.
> 
> Regards,
> Matthias
> 
> > +			reg = <0x001>;
> > +			enable-method = "psci";
> > +		};
> > +
> > +		cpu2: cpu@200 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a72";
> > +			reg = <0x200>;
> > +			enable-method = "psci";
> > +		};
> > +	};
> > +
> > +	psci {
> > +		compatible = "arm,psci-0.2";
> > +		method = "smc";
> > +	};
> > +
> > +	uart_clk: dummy26m {
> > +		compatible = "fixed-clock";
> > +		clock-frequency = <26000000>;
> > +		#clock-cells = <0>;
> > +	};
> > +
> > +	timer {
> > +		compatible = "arm,armv8-timer";
> > +		interrupt-parent = <&gic>;
> > +		interrupts = <GIC_PPI 13
> > +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > +			     <GIC_PPI 14
> > +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > +			     <GIC_PPI 11
> > +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > +			     <GIC_PPI 10
> > +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
> > +	};
> > +
> > +	soc {
> > +		#address-cells = <2>;
> > +		#size-cells = <2>;
> > +		compatible = "simple-bus";
> > +		ranges;
> > +
> > +		uart5: serial@1000f000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x1000f000 0 0x400>;
> > +			interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +
> > +		sysirq: interrupt-controller@10220a80 {
> > +			compatible = "mediatek,mt2712-sysirq",
> > +				     "mediatek,mt6577-sysirq";
> > +			interrupt-controller;
> > +			#interrupt-cells = <3>;
> > +			interrupt-parent = <&gic>;
> > +			reg = <0 0x10220a80 0 0x40>;
> > +		};
> > +
> > +		gic: interrupt-controller@10510000 {
> > +			compatible = "arm,gic-400";
> > +			#interrupt-cells = <3>;
> > +			interrupt-parent = <&gic>;
> > +			interrupt-controller;
> > +			reg = <0 0x10510000 0 0x1000>,
> > +			      <0 0x10520000 0 0x1000>,
> > +			      <0 0x10540000 0 0x2000>,
> > +			      <0 0x10560000 0 0x2000>;
> > +			interrupts = <GIC_PPI 9
> > +				(GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
> > +		};
> > +
> > +		uart0: serial@11002000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x11002000 0 0x400>;
> > +			interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +
> > +		uart1: serial@11003000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x11003000 0 0x400>;
> > +			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +
> > +		uart2: serial@11004000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x11004000 0 0x400>;
> > +			interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +
> > +		uart3: serial@11005000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x11005000 0 0x400>;
> > +			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +
> > +		uart4: serial@11019000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x11019000 0 0x400>;
> > +			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +	};
> > +};
> > +
> > 

^ permalink raw reply

* [PATCH 09/10] Revert "printk: fix double printing with earlycon"
From: Dominik Heidler @ 2017-06-09 13:53 UTC (permalink / raw)
  To: dominik
  Cc: Petr Mladek, Aleksey Makarov, Sabrina Dubroca, Sudeep Holla,
	Greg Kroah-Hartman, Peter Hurley, Jiri Slaby, Robin Murphy,
	Steven Rostedt, Nair, Jayachandran, linux-serial, linux-kernel
In-Reply-To: <20170609135333.15847-1-dheidler@suse.de>

From: Petr Mladek <pmladek@suse.com>

This reverts commit cf39bf58afdaabc0b86f141630fb3fd18190294e.

The commit regression to users that define both console=ttyS1
and console=ttyS0 on the command line, see
https://lkml.kernel.org/r/20170509082915.GA13236@bistromath.localdomain

The kernel log messages always appeared only on one serial port. It is
even documented in Documentation/admin-guide/serial-console.rst:

"Note that you can only define one console per device type (serial,
video)."

The above mentioned commit changed the order in which the command line
parameters are searched. As a result, the kernel log messages go to
the last mentioned ttyS* instead of the first one.

We long thought that using two console=ttyS* on the command line
did not make sense. But then we realized that console= parameters
were handled also by systemd, see
http://0pointer.de/blog/projects/serial-console.html

"By default systemd will instantiate one serial-getty@.service on
the main kernel console, if it is not a virtual terminal."

where

"[4] If multiple kernel consoles are used simultaneously, the main
console is the one listed first in /sys/class/tty/console/active,
which is the last one listed on the kernel command line."

This puts the original report into another light. The system is running
in qemu. The first serial port is used to store the messages into a file.
The second one is used to login to the system via a socket. It depends
on systemd and the historic kernel behavior.

By other words, systemd causes that it makes sense to define both
console=ttyS1 console=ttyS0 on the command line. The kernel fix
caused regression related to userspace (systemd) and need to be
reverted.

In addition, it went out that the fix helped only partially.
The messages still were duplicated when the boot console was
removed early by late_initcall(printk_late_init). Then the entire
log was replayed when the same console was registered as a normal one.

Link: 20170606160339.GC7604@pathway.suse.cz
Cc: Aleksey Makarov <aleksey.makarov@linaro.org>
Cc: Sabrina Dubroca <sd@queasysnail.net>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: "Nair, Jayachandran" <Jayachandran.Nair@cavium.com>
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reported-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
 kernel/printk/printk.c | 46 ++++++++++------------------------------------
 1 file changed, 10 insertions(+), 36 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 779479ac9f57..9dbceb76e6bc 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -269,7 +269,6 @@ static struct console *exclusive_console;
 #define MAX_CMDLINECONSOLES 8
 
 static struct console_cmdline console_cmdline[MAX_CMDLINECONSOLES];
-static int console_cmdline_cnt;
 
 static int preferred_console = -1;
 int console_set_on_cmdline;
@@ -1906,25 +1905,12 @@ static int __add_preferred_console(char *name, int idx, char *options,
 	 *	See if this tty is not yet registered, and
 	 *	if we have a slot free.
 	 */
-	for (i = 0, c = console_cmdline; i < console_cmdline_cnt; i++, c++) {
+	for (i = 0, c = console_cmdline;
+	     i < MAX_CMDLINECONSOLES && c->name[0];
+	     i++, c++) {
 		if (strcmp(c->name, name) == 0 && c->index == idx) {
-			if (brl_options)
-				return 0;
-
-			/*
-			 * Maintain an invariant that will help to find if
-			 * the matching console is preferred, see
-			 * register_console():
-			 *
-			 * The last non-braille console is always
-			 * the preferred one.
-			 */
-			if (i != console_cmdline_cnt - 1)
-				swap(console_cmdline[i],
-				     console_cmdline[console_cmdline_cnt - 1]);
-
-			preferred_console = console_cmdline_cnt - 1;
-
+			if (!brl_options)
+				preferred_console = i;
 			return 0;
 		}
 	}
@@ -1937,7 +1923,6 @@ static int __add_preferred_console(char *name, int idx, char *options,
 	braille_set_options(c, brl_options);
 
 	c->index = idx;
-	console_cmdline_cnt++;
 	return 0;
 }
 /*
@@ -2477,23 +2462,12 @@ void register_console(struct console *newcon)
 	}
 
 	/*
-	 * See if this console matches one we selected on the command line.
-	 *
-	 * There may be several entries in the console_cmdline array matching
-	 * with the same console, one with newcon->match(), another by
-	 * name/index:
-	 *
-	 *	pl011,mmio,0x87e024000000,115200 -- added from SPCR
-	 *	ttyAMA0 -- added from command line
-	 *
-	 * Traverse the console_cmdline array in reverse order to be
-	 * sure that if this console is preferred then it will be the first
-	 * matching entry.  We use the invariant that is maintained in
-	 * __add_preferred_console().
+	 *	See if this console matches one we selected on
+	 *	the command line.
 	 */
-	for (i = console_cmdline_cnt - 1; i >= 0; i--) {
-		c = console_cmdline + i;
-
+	for (i = 0, c = console_cmdline;
+	     i < MAX_CMDLINECONSOLES && c->name[0];
+	     i++, c++) {
 		if (!newcon->match ||
 		    newcon->match(newcon, c->name, c->index, c->options) != 0) {
 			/* default matching */
-- 
2.13.0

^ permalink raw reply related

* Re: [PATCH v2 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile
From: Marc Zyngier @ 2017-06-09 13:50 UTC (permalink / raw)
  To: YT Shen
  Cc: Rob Herring, Matthias Brugger, Mark Rutland, Thomas Gleixner,
	Jason Cooper, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
	Mars Cheng, devicetree, linux-kernel, linux-serial,
	linux-arm-kernel, linux-mediatek, srv_heupstream, hongkun.cao
In-Reply-To: <1497015668.29586.26.camel@mtksdaap41>

On 09/06/17 14:41, YT Shen wrote:
> On Wed, 2017-05-31 at 13:38 +0100, Marc Zyngier wrote:
>> On 31/05/17 12:39, YT Shen wrote:
>>> This adds basic chip support for Mediatek 2712
>>>
>>> Signed-off-by: YT Shen <yt.shen@mediatek.com>
>>> ---
>>>  arch/arm64/boot/dts/mediatek/Makefile       |   1 +
>>>  arch/arm64/boot/dts/mediatek/mt2712-evb.dts |  39 +++++++
>>>  arch/arm64/boot/dts/mediatek/mt2712e.dtsi   | 166 ++++++++++++++++++++++++++++
>>>  3 files changed, 206 insertions(+)
>>>  create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-evb.dts
>>>  create mode 100644 arch/arm64/boot/dts/mediatek/mt2712e.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
>>> index 9fbfd32..fcc0604 100644
>>> --- a/arch/arm64/boot/dts/mediatek/Makefile
>>> +++ b/arch/arm64/boot/dts/mediatek/Makefile
>>> @@ -1,3 +1,4 @@
>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
>>>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
>>>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
>>>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt2712-evb.dts b/arch/arm64/boot/dts/mediatek/mt2712-evb.dts
>>> new file mode 100644
>>> index 0000000..e526c0f
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/mediatek/mt2712-evb.dts
>>> @@ -0,0 +1,39 @@
>>> +/*
>>> + * Copyright (c) 2017 MediaTek Inc.
>>> + * Author: YT Shen <yt.shen@mediatek.com>
>>> + *
>>> + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>> + */
>>> +
>>> +/dts-v1/;
>>> +#include "mt2712e.dtsi"
>>> +
>>> +/ {
>>> +	model = "MediaTek MT2712 evaluation board";
>>> +	compatible = "mediatek,mt2712-evb", "mediatek,mt2712";
>>> +
>>> +	aliases {
>>> +		serial0 = &uart0;
>>> +		serial1 = &uart1;
>>> +		serial2 = &uart2;
>>> +		serial3 = &uart3;
>>> +		serial4 = &uart4;
>>> +		serial5 = &uart5;
>>> +	};
>>> +
>>> +	memory@40000000 {
>>> +		device_type = "memory";
>>> +		reg = <0 0x40000000 0 0x80000000>;
>>> +	};
>>> +
>>> +	chosen {
>>> +		stdout-path = "serial0:921600n8";
>>> +		linux,initrd-start = <0x45000000>;
>>> +		linux,initrd-end   = <0x4a000000>;
>>> +	};
>>> +};
>>> +
>>> +&uart0 {
>>> +	status = "okay";
>>> +};
>>> +
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
>>> new file mode 100644
>>> index 0000000..6df0da9
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
>>> @@ -0,0 +1,166 @@
>>> +/*
>>> + * Copyright (c) 2017 MediaTek Inc.
>>> + * Author: YT Shen <yt.shen@mediatek.com>
>>> + *
>>> + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
>>> + */
>>> +
>>> +#include <dt-bindings/interrupt-controller/irq.h>
>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +
>>> +/ {
>>> +	compatible = "mediatek,mt2712";
>>> +	interrupt-parent = <&sysirq>;
>>> +	#address-cells = <2>;
>>> +	#size-cells = <2>;
>>> +
>>> +	cpus {
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +
>>> +		cpu-map {
>>> +			cluster0 {
>>> +				core0 {
>>> +					cpu = <&cpu0>;
>>> +				};
>>> +				core1 {
>>> +					cpu = <&cpu1>;
>>> +				};
>>> +			};
>>> +
>>> +			cluster1 {
>>> +				core0 {
>>> +					cpu = <&cpu2>;
>>> +				};
>>> +			};
>>> +		};
>>> +
>>> +		cpu0: cpu@0 {
>>> +			device_type = "cpu";
>>> +			compatible = "arm,cortex-a35";
>>> +			reg = <0x000>;
>>> +		};
>>> +
>>> +		cpu1: cpu@1 {
>>> +			device_type = "cpu";
>>> +			compatible = "arm,cortex-a35";
>>> +			reg = <0x001>;
>>> +			enable-method = "psci";
>>> +		};
>>> +
>>> +		cpu2: cpu@200 {
>>> +			device_type = "cpu";
>>> +			compatible = "arm,cortex-a72";
>>> +			reg = <0x200>;
>>> +			enable-method = "psci";
>>> +		};
>>> +	};
>>> +
>>> +	psci {
>>> +		compatible = "arm,psci-0.2";
>>> +		method = "smc";
>>> +	};
>>> +
>>> +	uart_clk: dummy26m {
>>> +		compatible = "fixed-clock";
>>> +		clock-frequency = <26000000>;
>>> +		#clock-cells = <0>;
>>> +	};
>>> +
>>> +	timer {
>>> +		compatible = "arm,armv8-timer";
>>> +		interrupt-parent = <&gic>;
>>> +		interrupts = <GIC_PPI 13
>>> +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
>>
>> Why 6? I only count 3 cores...
> OK, will change to GIC_CPU_MASK_RAW(0x13)
> 
> Sorry for the late reply.
>>
>>> +			     <GIC_PPI 14
>>> +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
>>> +			     <GIC_PPI 11
>>> +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
>>> +			     <GIC_PPI 10
>>> +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
>>> +	};
>>> +
>>> +	soc {
>>> +		#address-cells = <2>;
>>> +		#size-cells = <2>;
>>> +		compatible = "simple-bus";
>>> +		ranges;
>>> +
>>> +		uart5: serial@1000f000 {
>>> +			compatible = "mediatek,mt2712-uart",
>>> +				     "mediatek,mt6577-uart";
>>> +			reg = <0 0x1000f000 0 0x400>;
>>> +			interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
>>> +			clocks = <&uart_clk>;
>>> +			status = "disabled";
>>> +		};
>>> +
>>> +		sysirq: interrupt-controller@10220a80 {
>>> +			compatible = "mediatek,mt2712-sysirq",
>>> +				     "mediatek,mt6577-sysirq";
>>> +			interrupt-controller;
>>> +			#interrupt-cells = <3>;
>>> +			interrupt-parent = <&gic>;
>>> +			reg = <0 0x10220a80 0 0x40>;
>>> +		};
>>> +
>>> +		gic: interrupt-controller@10510000 {
>>> +			compatible = "arm,gic-400";
>>> +			#interrupt-cells = <3>;
>>> +			interrupt-parent = <&gic>;
>>> +			interrupt-controller;
>>> +			reg = <0 0x10510000 0 0x1000>,
>>> +			      <0 0x10520000 0 0x1000>,
>>
>> If that's truly a GIC400, then the above is wrong (the CPU interface is
>> spread over 8kB).
>>
>> I also suspect that the first 4kB are aliased over
>> 0x10520000:0x1052f000, and the second over 0x10530000:0x1053f000 (in the
>> true SBSA tradition). If that's the case, then the size is actually 128kB.
> The chip information at hand is not enough for me to answer this
> question, if I have further document will check this part.
> 
>>
>>> +			      <0 0x10540000 0 0x2000>,
>>> +			      <0 0x10560000 0 0x2000>;
>>
>> Please check GICV as well, which probably behaves the same way.
> The reg entry I changed to 
>   reg = <0 0x10510000 0 0x1000>,
>         <0 0x10520000 0 0x20000>,
>         <0 0x10540000 0 0x20000>,
>         <0 0x10560000 0 0x20000>;
>   is that correct?

Only you (or whoever integrated GIC400 on the platform) can know that.
I'd say that it is likely to be correct based on what's below, but
that's only an educated guess.

> 
> The platform boot to shell successfully.  The boot message shows
> additional different two lines:
> ...
> [    0.000000] GIC: Adjusting CPU interface base to 0x000000001052f000
> [    0.000000] GIC: Using split EOI/Deactivate mode
> ...

Seems OK to me.

>>
>>> +			interrupts = <GIC_PPI 9
>>> +				(GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
>>
>> Same thing here with 6 CPUs.
> Will change to GIC_CPU_MASK_RAW(0x13)
> 
>>
>>> +		};
>>> +
>>> +		uart0: serial@11002000 {
>>> +			compatible = "mediatek,mt2712-uart",
>>> +				     "mediatek,mt6577-uart";
>>> +			reg = <0 0x11002000 0 0x400>;
>>> +			interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>;
>>> +			clocks = <&uart_clk>;
>>> +			status = "disabled";
>>> +		};
>>> +
>>> +		uart1: serial@11003000 {
>>> +			compatible = "mediatek,mt2712-uart",
>>> +				     "mediatek,mt6577-uart";
>>> +			reg = <0 0x11003000 0 0x400>;
>>> +			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_LOW>;
>>> +			clocks = <&uart_clk>;
>>> +			status = "disabled";
>>> +		};
>>> +
>>> +		uart2: serial@11004000 {
>>> +			compatible = "mediatek,mt2712-uart",
>>> +				     "mediatek,mt6577-uart";
>>> +			reg = <0 0x11004000 0 0x400>;
>>> +			interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_LOW>;
>>> +			clocks = <&uart_clk>;
>>> +			status = "disabled";
>>> +		};
>>> +
>>> +		uart3: serial@11005000 {
>>> +			compatible = "mediatek,mt2712-uart",
>>> +				     "mediatek,mt6577-uart";
>>> +			reg = <0 0x11005000 0 0x400>;
>>> +			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_LOW>;
>>> +			clocks = <&uart_clk>;
>>> +			status = "disabled";
>>> +		};
>>> +
>>> +		uart4: serial@11019000 {
>>> +			compatible = "mediatek,mt2712-uart",
>>> +				     "mediatek,mt6577-uart";
>>> +			reg = <0 0x11019000 0 0x400>;
>>> +			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_LOW>;
>>> +			clocks = <&uart_clk>;
>>> +			status = "disabled";
>>> +		};
>>> +	};
>>> +};
>>> +
>>>
>>
>> No PMU wired on this system?
> After checking, there is a PMU on the system, but not verified yet.
> And the plan for this patch series does not include PMU, is it
> necessary?

Well, it is an important part of the system, and given that it comes
directly with the CPU cores, it'd be good to have it. But as always,
that's up to you.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* Re: [PATCH v2 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile
From: YT Shen @ 2017-06-09 13:41 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Rob Herring, Matthias Brugger, Mark Rutland, Thomas Gleixner,
	Jason Cooper, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
	Mars Cheng, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-serial-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
	hongkun.cao-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <d1be42ad-0b79-8487-1590-711b0e86d2ca-5wv7dgnIgG8@public.gmane.org>

On Wed, 2017-05-31 at 13:38 +0100, Marc Zyngier wrote:
> On 31/05/17 12:39, YT Shen wrote:
> > This adds basic chip support for Mediatek 2712
> > 
> > Signed-off-by: YT Shen <yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> >  arch/arm64/boot/dts/mediatek/Makefile       |   1 +
> >  arch/arm64/boot/dts/mediatek/mt2712-evb.dts |  39 +++++++
> >  arch/arm64/boot/dts/mediatek/mt2712e.dtsi   | 166 ++++++++++++++++++++++++++++
> >  3 files changed, 206 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-evb.dts
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> > index 9fbfd32..fcc0604 100644
> > --- a/arch/arm64/boot/dts/mediatek/Makefile
> > +++ b/arch/arm64/boot/dts/mediatek/Makefile
> > @@ -1,3 +1,4 @@
> > +dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
> >  dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
> >  dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
> >  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> > diff --git a/arch/arm64/boot/dts/mediatek/mt2712-evb.dts b/arch/arm64/boot/dts/mediatek/mt2712-evb.dts
> > new file mode 100644
> > index 0000000..e526c0f
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt2712-evb.dts
> > @@ -0,0 +1,39 @@
> > +/*
> > + * Copyright (c) 2017 MediaTek Inc.
> > + * Author: YT Shen <yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > + *
> > + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > + */
> > +
> > +/dts-v1/;
> > +#include "mt2712e.dtsi"
> > +
> > +/ {
> > +	model = "MediaTek MT2712 evaluation board";
> > +	compatible = "mediatek,mt2712-evb", "mediatek,mt2712";
> > +
> > +	aliases {
> > +		serial0 = &uart0;
> > +		serial1 = &uart1;
> > +		serial2 = &uart2;
> > +		serial3 = &uart3;
> > +		serial4 = &uart4;
> > +		serial5 = &uart5;
> > +	};
> > +
> > +	memory@40000000 {
> > +		device_type = "memory";
> > +		reg = <0 0x40000000 0 0x80000000>;
> > +	};
> > +
> > +	chosen {
> > +		stdout-path = "serial0:921600n8";
> > +		linux,initrd-start = <0x45000000>;
> > +		linux,initrd-end   = <0x4a000000>;
> > +	};
> > +};
> > +
> > +&uart0 {
> > +	status = "okay";
> > +};
> > +
> > diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> > new file mode 100644
> > index 0000000..6df0da9
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> > @@ -0,0 +1,166 @@
> > +/*
> > + * Copyright (c) 2017 MediaTek Inc.
> > + * Author: YT Shen <yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > + *
> > + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > + */
> > +
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > +	compatible = "mediatek,mt2712";
> > +	interrupt-parent = <&sysirq>;
> > +	#address-cells = <2>;
> > +	#size-cells = <2>;
> > +
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		cpu-map {
> > +			cluster0 {
> > +				core0 {
> > +					cpu = <&cpu0>;
> > +				};
> > +				core1 {
> > +					cpu = <&cpu1>;
> > +				};
> > +			};
> > +
> > +			cluster1 {
> > +				core0 {
> > +					cpu = <&cpu2>;
> > +				};
> > +			};
> > +		};
> > +
> > +		cpu0: cpu@0 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a35";
> > +			reg = <0x000>;
> > +		};
> > +
> > +		cpu1: cpu@1 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a35";
> > +			reg = <0x001>;
> > +			enable-method = "psci";
> > +		};
> > +
> > +		cpu2: cpu@200 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a72";
> > +			reg = <0x200>;
> > +			enable-method = "psci";
> > +		};
> > +	};
> > +
> > +	psci {
> > +		compatible = "arm,psci-0.2";
> > +		method = "smc";
> > +	};
> > +
> > +	uart_clk: dummy26m {
> > +		compatible = "fixed-clock";
> > +		clock-frequency = <26000000>;
> > +		#clock-cells = <0>;
> > +	};
> > +
> > +	timer {
> > +		compatible = "arm,armv8-timer";
> > +		interrupt-parent = <&gic>;
> > +		interrupts = <GIC_PPI 13
> > +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> 
> Why 6? I only count 3 cores...
OK, will change to GIC_CPU_MASK_RAW(0x13)

Sorry for the late reply.
> 
> > +			     <GIC_PPI 14
> > +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > +			     <GIC_PPI 11
> > +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> > +			     <GIC_PPI 10
> > +			      (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
> > +	};
> > +
> > +	soc {
> > +		#address-cells = <2>;
> > +		#size-cells = <2>;
> > +		compatible = "simple-bus";
> > +		ranges;
> > +
> > +		uart5: serial@1000f000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x1000f000 0 0x400>;
> > +			interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +
> > +		sysirq: interrupt-controller@10220a80 {
> > +			compatible = "mediatek,mt2712-sysirq",
> > +				     "mediatek,mt6577-sysirq";
> > +			interrupt-controller;
> > +			#interrupt-cells = <3>;
> > +			interrupt-parent = <&gic>;
> > +			reg = <0 0x10220a80 0 0x40>;
> > +		};
> > +
> > +		gic: interrupt-controller@10510000 {
> > +			compatible = "arm,gic-400";
> > +			#interrupt-cells = <3>;
> > +			interrupt-parent = <&gic>;
> > +			interrupt-controller;
> > +			reg = <0 0x10510000 0 0x1000>,
> > +			      <0 0x10520000 0 0x1000>,
> 
> If that's truly a GIC400, then the above is wrong (the CPU interface is
> spread over 8kB).
> 
> I also suspect that the first 4kB are aliased over
> 0x10520000:0x1052f000, and the second over 0x10530000:0x1053f000 (in the
> true SBSA tradition). If that's the case, then the size is actually 128kB.
The chip information at hand is not enough for me to answer this
question, if I have further document will check this part.

> 
> > +			      <0 0x10540000 0 0x2000>,
> > +			      <0 0x10560000 0 0x2000>;
> 
> Please check GICV as well, which probably behaves the same way.
The reg entry I changed to 
  reg = <0 0x10510000 0 0x1000>,
        <0 0x10520000 0 0x20000>,
        <0 0x10540000 0 0x20000>,
        <0 0x10560000 0 0x20000>;
  is that correct?

The platform boot to shell successfully.  The boot message shows
additional different two lines:
...
[    0.000000] GIC: Adjusting CPU interface base to 0x000000001052f000
[    0.000000] GIC: Using split EOI/Deactivate mode
...

> 
> > +			interrupts = <GIC_PPI 9
> > +				(GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
> 
> Same thing here with 6 CPUs.
Will change to GIC_CPU_MASK_RAW(0x13)

> 
> > +		};
> > +
> > +		uart0: serial@11002000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x11002000 0 0x400>;
> > +			interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +
> > +		uart1: serial@11003000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x11003000 0 0x400>;
> > +			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +
> > +		uart2: serial@11004000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x11004000 0 0x400>;
> > +			interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +
> > +		uart3: serial@11005000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x11005000 0 0x400>;
> > +			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +
> > +		uart4: serial@11019000 {
> > +			compatible = "mediatek,mt2712-uart",
> > +				     "mediatek,mt6577-uart";
> > +			reg = <0 0x11019000 0 0x400>;
> > +			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_LOW>;
> > +			clocks = <&uart_clk>;
> > +			status = "disabled";
> > +		};
> > +	};
> > +};
> > +
> > 
> 
> No PMU wired on this system?
After checking, there is a PMU on the system, but not verified yet.
And the plan for this patch series does not include PMU, is it
necessary?

Thanks for the review.

yt.shen

> 
> Thanks,
> 
> 	M.


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH v4 7/7] ARM: dts: meson8b: switch to new bindings for UART nodes
From: Neil Armstrong @ 2017-06-09  9:49 UTC (permalink / raw)
  To: gregkh, khilman
  Cc: Neil Armstrong, hgkr.klein, linux-serial, linux-amlogic,
	linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1497001756-942-1-git-send-email-narmstrong@baylibre.com>

Switch to the stable UART bindings by adding a XTAL node and using the
proper compatible strings.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm/boot/dts/meson8b.dtsi | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index d9f116a..651ad4a 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -82,6 +82,13 @@
 			reg = <0x203>;
 		};
 	};
+
+	xtal: xtal-clk {
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+		clock-output-names = "xtal";
+		#clock-cells = <0>;
+	};
 }; /* end of / */
 
 &aobus {
@@ -178,17 +185,25 @@
 };
 
 &uart_AO {
-	clocks = <&clkc CLKID_CLK81>;
+	compatible = "amlogic,meson8b-uart", "amlogic,meson-ao-uart";
+	clocks = <&xtal>, <&clkc CLKID_CLK81>, <&clkc CLKID_CLK81>;
+	clock-names = "xtal", "pclk", "baud";
 };
 
 &uart_A {
-	clocks = <&clkc CLKID_CLK81>;
+	compatible = "amlogic,meson8b-uart";
+	clocks = <&xtal>, <&clkc CLKID_CLK81>, <&clkc CLKID_CLK81>;
+	clock-names = "xtal", "pclk", "baud";
 };
 
 &uart_B {
-	clocks = <&clkc CLKID_CLK81>;
+	compatible = "amlogic,meson8b-uart";
+	clocks = <&xtal>, <&clkc CLKID_CLK81>, <&clkc CLKID_CLK81>;
+	clock-names = "xtal", "pclk", "baud";
 };
 
 &uart_C {
-	clocks = <&clkc CLKID_CLK81>;
+	compatible = "amlogic,meson8b-uart";
+	clocks = <&xtal>, <&clkc CLKID_CLK81>, <&clkc CLKID_CLK81>;
+	clock-names = "xtal", "pclk", "baud";
 };
-- 
1.9.1

^ permalink raw reply related

* [PATCH v4 6/7] ARM: dts: meson8: switch to new bindings for UART nodes
From: Neil Armstrong @ 2017-06-09  9:49 UTC (permalink / raw)
  To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	khilman-rdvid1DuHRBWk0Htik3J/w
  Cc: Neil Armstrong, hgkr.klein-Re5JQEeQqe8AvxtiuMwx3w,
	linux-serial-u79uwXL29TY76Z2rM5mHXA,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1497001756-942-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Switch to the stable UART bindings by adding a XTAL node and using the
proper compatible strings.

Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
 arch/arm/boot/dts/meson8.dtsi | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 6993077..a2ea112 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -83,6 +83,13 @@
 		};
 	};
 
+	xtal: xtal-clk {
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+		clock-output-names = "xtal";
+		#clock-cells = <0>;
+	};
+
 	clk81: clk@0 {
 		#clock-cells = <0>;
 		compatible = "fixed-clock";
@@ -199,17 +206,25 @@
 };
 
 &uart_AO {
-	clocks = <&clk81>;
+	compatible = "amlogic,meson8-uart", "amlogic,meson-ao-uart";
+	clocks = <&xtal>, <&clk81>, <&clk81>;
+	clock-names = "xtal", "pclk", "baud";
 };
 
 &uart_A {
-	clocks = <&clk81>;
+	compatible = "amlogic,meson8-uart";
+	clocks = <&xtal>, <&clk81>, <&clk81>;
+	clock-names = "xtal", "pclk", "baud";
 };
 
 &uart_B {
-	clocks = <&clk81>;
+	compatible = "amlogic,meson8-uart";
+	clocks = <&xtal>, <&clk81>, <&clk81>;
+	clock-names = "xtal", "pclk", "baud";
 };
 
 &uart_C {
-	clocks = <&clk81>;
+	compatible = "amlogic,meson8-uart";
+	clocks = <&xtal>, <&clk81>, <&clk81>;
+	clock-names = "xtal", "pclk", "baud";
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox