Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/8] ARM: dts: imx7d-sbc-iot: add initial iot gateway dts
From: tyler at opensourcefoundries.com @ 2017-11-30 20:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130201434.14122-1-tyler@opensourcefoundries.com>

From: Tyler Baker <tyler@opensourcefoundries.com>

The Compulab IoT Gateway is based on an NXP i.MX7D, dual core
Cortex-A7 clocking at 1GHz. It supports up to 2GB of DDR3,
and 32GB of eMMC flash. Onboard, there are two gigabit
ethernet controllers, 4 x USB2, RS485, and CAN.

This platform is based on the imx7d-cl-som-imx7 module but
includes a baseboard with additional peripherals
which is what this device tree is meant to describe.

This work has been derrived from the Compulab Linux sources
based on v4.1.

Signed-off-by: Tyler Baker <tyler@opensourcefoundries.com>
Signed-off-by: Ilya Ledvich <ilya@compulab.co.il>
---
 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts | 238 +++++++++++++++++++++++++++++++
 1 file changed, 238 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts

diff --git a/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
new file mode 100644
index 0000000..50dfdd3
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
@@ -0,0 +1,238 @@
+/*
+ * Support for CompuLab SBC-IOT-iMX7 Single Board Computer
+ *
+ * Copyright (C) 2017 CompuLab Ltd. - http://www.compulab.co.il/
+ * Author: Ilya Ledvich <ilya@compulab.co.il>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "imx7d-cl-som-imx7.dts"
+
+/ {
+	model = "CompuLab SBC-IOT-iMX7";
+	compatible = "compulab,sbc-iot-imx7", "compulab,cl-som-imx7", "fsl,imx7d";
+
+	aliases {
+		lcdif = &lcdif;
+	};
+};
+
+&ecspi3 {
+	fsl,spi-num-chipselects = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
+	cs-gpios = <&gpio4 11 0>;
+	status = "okay";
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+};
+
+&i2c4 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c4>;
+	status = "okay";
+
+	eeprom_iot at 54 {
+		compatible = "atmel,24c08";
+		reg = <0x54>;
+		pagesize = <16>;
+	};
+
+	dvicape at 39 {
+		compatible = "sil164_simple";
+		reg = <0x39>;
+	};
+};
+
+&iomuxc {
+	pinctrl_xpen: xpengrp {
+		fsl,pins = <
+			MX7D_PAD_LCD_DATA13__GPIO3_IO18		0x34 /* P7-4 - gpio82 */
+			MX7D_PAD_LCD_DATA12__GPIO3_IO17		0x34 /* P7-5 - gpio81 */
+		>;
+	};
+
+	pinctrl_ecspi3: ecspi3grp {
+		fsl,pins = <
+			MX7D_PAD_I2C1_SDA__ECSPI3_MOSI		0xf /* P7-8 */
+			MX7D_PAD_I2C1_SCL__ECSPI3_MISO		0xf /* P7-7 */
+			MX7D_PAD_I2C2_SCL__ECSPI3_SCLK		0xf /* P7-6 */
+		>;
+	};
+
+	pinctrl_ecspi3_cs: ecspi3_cs_grp {
+		fsl,pins = <
+			MX7D_PAD_I2C2_SDA__GPIO4_IO11		0x34 /* P7-9 */
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX7D_PAD_GPIO1_IO09__I2C3_SDA		0x4000000f /* P7-3 */
+			MX7D_PAD_GPIO1_IO08__I2C3_SCL		0x4000000f /* P7-2 */
+		>;
+	};
+
+	pinctrl_i2c4: i2c4grp {
+		fsl,pins = <
+			MX7D_PAD_GPIO1_IO11__I2C4_SDA		0x4000000f
+			MX7D_PAD_GPIO1_IO10__I2C4_SCL		0x4000000f
+		>;
+	};
+
+	pinctrl_lcdif_dat: lcdifdatgrp {
+		fsl,pins = <
+			MX7D_PAD_LCD_DATA00__LCD_DATA0		0x79
+			MX7D_PAD_LCD_DATA01__LCD_DATA1		0x79
+			MX7D_PAD_LCD_DATA02__LCD_DATA2		0x79
+			MX7D_PAD_LCD_DATA03__LCD_DATA3		0x79
+			MX7D_PAD_EPDC_DATA04__LCD_DATA4		0x79
+			MX7D_PAD_EPDC_DATA05__LCD_DATA5		0x79
+			MX7D_PAD_EPDC_DATA06__LCD_DATA6		0x79
+			MX7D_PAD_EPDC_DATA07__LCD_DATA7		0x79
+			MX7D_PAD_EPDC_DATA08__LCD_DATA8		0x79
+			MX7D_PAD_EPDC_DATA09__LCD_DATA9		0x79
+			MX7D_PAD_EPDC_DATA10__LCD_DATA10	0x79
+			MX7D_PAD_EPDC_DATA11__LCD_DATA11	0x79
+			MX7D_PAD_EPDC_DATA12__LCD_DATA12	0x79
+			MX7D_PAD_EPDC_DATA13__LCD_DATA13	0x79
+			MX7D_PAD_EPDC_DATA14__LCD_DATA14	0x79
+			MX7D_PAD_EPDC_DATA15__LCD_DATA15	0x79
+			MX7D_PAD_LCD_DATA16__LCD_DATA16		0x79
+			MX7D_PAD_LCD_DATA17__LCD_DATA17		0x79
+			MX7D_PAD_LCD_DATA18__LCD_DATA18		0x79
+			MX7D_PAD_LCD_DATA19__LCD_DATA19		0x79
+			MX7D_PAD_LCD_DATA20__LCD_DATA20		0x79
+			MX7D_PAD_LCD_DATA21__LCD_DATA21		0x79
+			MX7D_PAD_LCD_DATA22__LCD_DATA22		0x79
+			MX7D_PAD_LCD_DATA23__LCD_DATA23		0x79
+		>;
+	};
+
+	pinctrl_lcdif_ctrl: lcdifctrlgrp {
+		fsl,pins = <
+			MX7D_PAD_EPDC_DATA00__LCD_CLK		0x79
+			MX7D_PAD_EPDC_DATA01__LCD_ENABLE	0x79
+			MX7D_PAD_EPDC_DATA02__LCD_VSYNC		0x79
+			MX7D_PAD_EPDC_DATA03__LCD_HSYNC		0x79
+		>;
+	};
+
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			MX7D_PAD_LCD_ENABLE__UART2_DCE_TX	0x79 /* P7-12 */
+			MX7D_PAD_LCD_CLK__UART2_DCE_RX		0x79 /* P7-13 */
+			MX7D_PAD_LCD_VSYNC__UART2_DCE_CTS	0x79 /* P7-11 */
+			MX7D_PAD_LCD_HSYNC__UART2_DCE_RTS	0x79 /* P7-10 */
+		>;
+	};
+
+	pinctrl_uart5: uart5grp {
+		fsl,pins = <
+			MX7D_PAD_I2C4_SDA__UART5_DCE_TX		0x79 /* RS232-TX */
+			MX7D_PAD_I2C4_SCL__UART5_DCE_RX		0x79 /* RS232-RX */
+			MX7D_PAD_I2C3_SDA__UART5_DCE_RTS	0x79 /* RS232-RTS */
+			MX7D_PAD_I2C3_SCL__UART5_DCE_CTS	0x79 /* RS232-CTS */
+		>;
+	};
+
+	pinctrl_uart7: uart7grp {
+		fsl,pins = <
+			MX7D_PAD_ECSPI2_MOSI__UART7_DCE_TX	0x79 /* R485-TX */
+			MX7D_PAD_ECSPI2_SCLK__UART7_DCE_RX	0x79 /* R485-RX */
+			MX7D_PAD_ECSPI2_SS0__UART7_DCE_CTS	0x79 /* R485-CTS */
+			MX7D_PAD_ECSPI2_MISO__UART7_DCE_RTS	0x79 /* R485-TTS */
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX7D_PAD_SD1_CMD__SD1_CMD		0x59
+			MX7D_PAD_SD1_CLK__SD1_CLK		0x19
+			MX7D_PAD_SD1_DATA0__SD1_DATA0		0x59
+			MX7D_PAD_SD1_DATA1__SD1_DATA1		0x59
+			MX7D_PAD_SD1_DATA2__SD1_DATA2		0x59
+			MX7D_PAD_SD1_DATA3__SD1_DATA3		0x59
+			MX7D_PAD_SD1_CD_B__GPIO5_IO0		0x59 /* CD */
+		>;
+	};
+};
+
+&lcdif {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lcdif_dat
+		     &pinctrl_lcdif_ctrl>;
+	display = <&display0>;
+	status = "okay";
+
+	display0: display {
+		bits-per-pixel = <24>;
+		bus-width = <24>;
+
+		display-timings {
+			native-mode = <&timing0>;
+			timing0: dvi {
+				/* 1024x768p60 */
+				clock-frequency = <65000000>;
+				hactive = <1024>;
+				hfront-porch = <40>;
+				hback-porch = <220>;
+				hsync-len = <60>;
+				vactive = <768>;
+				vfront-porch = <7>;
+				vback-porch = <21>;
+				vsync-len = <10>;
+
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <0>;
+			};
+		};
+	};
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	assigned-clocks = <&clks IMX7D_UART2_ROOT_SRC>;
+	assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
+&uart5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart5>;
+	assigned-clocks = <&clks IMX7D_UART5_ROOT_SRC>;
+	assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
+&uart7 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart7>;
+	assigned-clocks = <&clks IMX7D_UART7_ROOT_SRC>;
+	assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	cd-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+	wp-gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+	enable-sdio-wakeup;
+	status = "okay";
+};
-- 
2.9.3

^ permalink raw reply related

* [PATCH 0/8] ARM: dts: introduce Compulab IoT Gateway
From: tyler at opensourcefoundries.com @ 2017-11-30 20:14 UTC (permalink / raw)
  To: linux-arm-kernel

From: Tyler Baker <tyler@opensourcefoundries.com>

The Compulab IoT Gateway is based on an NXP i.MX7D, dual core
Cortex-A7 clocking at 1GHz. It supports up to 2GB of DDR3,
and 32GB of eMMC flash. Onboard, there are two gigabit
ethernet controllers, 4 x USB2, RS485, and CAN.

It uses the same SoM as the cl-som-imx7, but includes a baseboard 
with additional I/O.

Compulab has provided patches for this platform based on v4.1. 
I've used these patches as reference to get things working on tip.

The entire series is based on v4.15-rc1.

Tyler Baker (8):
  ARM: dts: imx7d-sbc-iot: add initial iot gateway dts
  ARM: dts: imx7: build imx7d-sbc-iot-imx7 dtb
  ARM: dts: imx7d-cl-som: add nodes for usbh, and usbotg2
  ARM: dts: imx7s: add dma support
  ARM: dts: imx7s: add node and supplies for vdd1p2
  ARM: dts: imx7d-sbc-iot: enable PCIe peripheral
  ARM: dts: imx7s: add usb hsic phy domain
  PCIe: imx6: imx7d: add support for phy refclk source

 arch/arm/boot/dts/Makefile               |   1 +
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts  |  36 ++++-
 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts | 252 +++++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx7s.dtsi             |  29 +++-
 drivers/pci/dwc/pci-imx6.c               |   8 +-
 5 files changed, 316 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts

-- 
2.9.3

^ permalink raw reply

* [PATCH v3 5/6] ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
From: Alexander Sverdlin @ 2017-11-30 20:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <BLUPR0101MB155444953DA2E47B0AEE80BFD0380@BLUPR0101MB1554.prod.exchangelabs.com>

Hello Hartley!

On Thu, 30 Nov 2017 17:23:02 +0000
Hartley Sweeten <HartleyS@visionengravers.com> wrote:

> > +/**********************************************************************
> > +***
> > + * IO map
> > + 
> > +***********************************************************************
> > +**/
> 
> There is also something funny with the patch. The lines above appear to be getting split incorrectly.

That's definitely not the case, I can apply the patch to 4.14 just fine and
there is no funny wrapping. But you are right about the rest, it should be
re-based.

-- 
Alexander Sverdlin.

^ permalink raw reply

* [PATCH/RFT renesas-devel] arm64: dts: ulcb: Enable NFS root
From: Sergei Shtylyov @ 2017-11-30 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMuHMdVKA5YmRPcTTGafKciMF-cKtKTx+PdNJtrDRb20jCxtAA@mail.gmail.com>

On 11/30/2017 04:45 PM, Geert Uytterhoeven wrote:

>>>>> Enable NFS root on the r8a7795/h3ulcb and r8a7796/m3ulcb
>>>>> as per:
>>>>> * commit b2407c566ba29215 ("arm64: dts: r8a7795: enable nfs root on Salvator-X board").
>>>>> * commit 742a9dfb90f0 ("arm64: dts: r8a7796: salvator-x: Enable NFS root")
>>>>>
>>>>> Also set ignore_loglevel rw as boot args as is the case for the boards
>>>>> for the boards for other Renesas ARM/ARM64 based SoCs.
>>>>
>>>> s/for the boards//
>>>>
>>>>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>>>
>>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>
>>>> Gr{oetje,eeting}s,
>>>
>>> Sergei has pointed out that bootargs has seems to have effect on ARM64
>>> kernels. So I think this patch should be withdrawn and we should consider
>>> removing bootargs from those ARM64 boards where it is present.
>>>
>>
>> I don't think this is true.
>>
>> I just added a argument to bootargs to salvator-common.dtsi for some
>> hack testing and it took effect. Tested on-top of latest renesas-drivers
>> and H3 ES2.0.
>>
>>>>> DIFF <<<
>> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> index 7b30044a55367d35..4cb4b44f8be42cb4 100644
>> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> @@ -42,7 +42,7 @@
>>          };
>>
>>          chosen {
>> -               bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
>> +               bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp adv748x.txbvc=1";
>>                  stdout-path = "serial0:115200n8";
>>          };
>>>>> END DIFF <<<
>>
>> # cat /sys/firmware/devicetree/base/chosen/bootargs
>> ignore_loglevel rw root=/dev/nfs ip=dhcp adv748x.txbvc=1
>>
>> And the module parameter had the expected effect on the adv7482x driver.
>> Is there another issue here which I'm missing?
> 
> 1. It may depend on the U-Boot version

    It probably does! My U-Boot clearly copies its "bootargs" env. variable 
into DT's "/chosen/bootargs" prop.

> 2. Anyone playing with CONFIG_CMDLINE and CONFIG_CMDLINE_FORCE?

    Not me (before now). Tried it now and it works as expected.

> Gr{oetje,eeting}s,
> 
>                          Geert

MBR, Sergei

^ permalink raw reply

* [PATCH v2 01/18] dt-bindings: panel: lvds: Document power-supply property
From: Rob Herring @ 2017-11-30 19:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130153002.3vuqenr72dippg27@flea.lan>

On Thu, Nov 30, 2017 at 9:30 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Rob,
>
> On Tue, Nov 28, 2017 at 11:48:47AM -0600, Rob Herring wrote:
>> Please CC DT list.
>>
>> On Mon, Nov 27, 2017 at 9:41 AM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > The power-supply property is used by a vast majority of panels, including
>> > panel-simple. Let's document it as a common property
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>> > ---
>> >  Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++++++
>> >  Documentation/devicetree/bindings/display/panel/panel-lvds.txt   | 1 +
>> >  2 files changed, 7 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt b/Documentation/devicetree/bindings/display/panel/panel-common.txt
>> > index ec52c472c845..125ea68052af 100644
>> > --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
>> > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
>> > @@ -78,6 +78,12 @@ used for panels that implement compatible control signals.
>> >    while active. Active high reset signals can be supported by inverting the
>> >    GPIO specifier polarity flag.
>> >
>> > +Power
>> > +-----
>> > +
>> > +- power-supply: many display panels need an additional power supply in
>> > +  order to be fully powered-up. For such panels, power-supply contains
>> > +  a phandle to the regulator powering the panel.
>> >
>> >  Backlight
>> >  ---------
>> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> > index b938269f841e..250850a2150b 100644
>> > --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> > @@ -32,6 +32,7 @@ Optional properties:
>> >  - label: See panel-common.txt.
>> >  - gpios: See panel-common.txt.
>> >  - backlight: See panel-common.txt.
>> > +- power-supply: See panel-common.txt.
>>
>> simple-panel.txt should do the same.
>
> I'll make simple-panel do that then
>
>> Really, I'd like to see panel-common.txt and simple-panel.txt merged
>> and simple-panel.txt removed altogether. But there are a lot of
>> references back to simple-panel.txt. A given panel still needs to say
>> what common properties it uses or doesn't use. Omitting a property
>> like power-supply is ambiguous and can either mean "I only have 1
>> supply" or "I haven't thought about supplies yet there are more than
>> 1".
>
> While I agree with you here, and in general, power-supply should be
> mandatory, do you expect me to fix all the panel bindings as part of
> this serie?

No, certainly not.

Rob

^ permalink raw reply

* [PATCH] rtc: Allow rtc drivers to specify the tv_nsec value for ntp
From: Alexandre Belloni @ 2017-11-30 19:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130193959.GC21126@piout.net>

Please disregard this email, this was a draft that should not have been
sent, written while I was still too annoyed about the whole situation.

On 30/11/2017 at 20:39:59 +0100, Alexandre Belloni wrote:
> On 28/11/2017 at 10:20:25 +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 27, 2017 at 08:31:35PM +0100, Alexandre Belloni wrote:
> > > On 27/11/2017 at 18:53:52 +0000, Russell King - ARM Linux wrote:
> > > > You are, yet again, wrong.
> > > > 
> > > > I am in a position to make the comment because it was me who identified
> > > > the problem, put in the hours to work on, develop and extensively test
> > > > Jason's patch.  So, it's partly my time that you seem to be wasting,
> > > > and that gives me every right to complain at this point.
> > > > 
> > > > You, on the other hand, were copied with every single email, and did
> > > > nothing to discuss the issue except for the "easy" bits when I posted
> > > > a relatively smaller patch - but you ignored the bigger issue.
> > > 
> > > And this is exactly what you do with other people patches/time when you
> > > don't like their changes.
> > > You simply ignore the patch series until they go away.
> > 
> > That is not intentional.
> > 
> 
> But that is exactly what you are currently reproaching me right now. I
> didn't have the time to have a good look a it so I didn't reply it
> wasn't intentional either.
> 
> You sometimes don't reply to patch series, I sometimes take time to
> reply, I don't see how this is different then.
> 
> > > I would really expect people merging code in any subsystem to wait for
> > > the ack of the maintainer of that subsystem.
> > > 
> > > I didn't complain about any missing email addresses, I said the RTC ML
> > > was not copied but that is didn't matter.
> > 
> > A mailing list is an email address.
> > 
> 
> Yes and I said that it didn't matter it was not copied (the patch didn't
> make it in patchwork though).
> 
> > > What I don't get is that it has been broken for almost 5 years and now
> > > you seem to think it has to be fixed urgently.
> > 
> > Now you're making crap up.  I've not made any comment about this being
> > something that needs fixing urgently.  In fact, as I've said several
> > times already, I really don't care what you do with the mainline kernel,
> > because I have a fix here locally that I intend to use and maintain
> > into the future.  For me, the issue is fixed and resolved, and I intend
> > to spend no further time developing any fixes for it.
> > 
> 
> Oh great, that's really the way to go to make progress.
> 
> > My comments are about the _two months_ its taken to get to the stage of
> > finding out that you don't like the approach.
> > 
> 
> While I can understand some of the frustration, I don't get why you are
> giving up so easily.
> 
> > The result of this is, most likely, one of:
> > 1. you'll revert the patch (which, incidentally, has no real effect until
> >    my other patches get merged) and everyone will either be stuck with a
> >    kernel that sets their RTC time wrong when they have NTP installed
> > 
> 
> Or when using hwclock from util-linux
> 
> > 2. you'll remove the systohc code, people won't realise that their kernel
> >    no longer sync's the RTC time, and systems that are on the Internet
> >    (eg, providing stratum 1 NTP servers) will be unreliable if they are
> >    rebooted even more so than they are today.
> > 
> > > On my side, I want to take the opportunity to think about systohc before
> > > adding an ABI that we will maybe regret later.
> > 
> > Fine, but bear in mind that I don't care anymore, because I have
> > perfectly good fixes locally, and I'm not wasting any further time
> > in this issue.
> > 
> > While you think about it, I would encourage anyone who wishing to run
> > or running a public NTP server using rtclib to ditch Linux and use
> > FreeBSD instead to avoid their NTP server supplying false time, even
> > when synchronised to a reference clock.  A reboot of such a server
> > will supply false time for a period of a few hours depending on how
> > far the time is out (which can be up to a couple of seconds) after
> > such an event.  In such a scenario, NTP will not step-correct the
> > time but will gradually slew it instead.
> > 
> > This goes for systems that some ISPs deploy as stratum 1 NTP servers,
> > which today tend to be Raspberry Pis.
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH] rtc: Allow rtc drivers to specify the tv_nsec value for ntp
From: Alexandre Belloni @ 2017-11-30 19:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171128102025.GT31757@n2100.armlinux.org.uk>

On 28/11/2017 at 10:20:25 +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 27, 2017 at 08:31:35PM +0100, Alexandre Belloni wrote:
> > On 27/11/2017 at 18:53:52 +0000, Russell King - ARM Linux wrote:
> > > You are, yet again, wrong.
> > > 
> > > I am in a position to make the comment because it was me who identified
> > > the problem, put in the hours to work on, develop and extensively test
> > > Jason's patch.  So, it's partly my time that you seem to be wasting,
> > > and that gives me every right to complain at this point.
> > > 
> > > You, on the other hand, were copied with every single email, and did
> > > nothing to discuss the issue except for the "easy" bits when I posted
> > > a relatively smaller patch - but you ignored the bigger issue.
> > 
> > And this is exactly what you do with other people patches/time when you
> > don't like their changes.
> > You simply ignore the patch series until they go away.
> 
> That is not intentional.
> 

But that is exactly what you are currently reproaching me right now. I
didn't have the time to have a good look a it so I didn't reply it
wasn't intentional either.

You sometimes don't reply to patch series, I sometimes take time to
reply, I don't see how this is different then.

> > I would really expect people merging code in any subsystem to wait for
> > the ack of the maintainer of that subsystem.
> > 
> > I didn't complain about any missing email addresses, I said the RTC ML
> > was not copied but that is didn't matter.
> 
> A mailing list is an email address.
> 

Yes and I said that it didn't matter it was not copied (the patch didn't
make it in patchwork though).

> > What I don't get is that it has been broken for almost 5 years and now
> > you seem to think it has to be fixed urgently.
> 
> Now you're making crap up.  I've not made any comment about this being
> something that needs fixing urgently.  In fact, as I've said several
> times already, I really don't care what you do with the mainline kernel,
> because I have a fix here locally that I intend to use and maintain
> into the future.  For me, the issue is fixed and resolved, and I intend
> to spend no further time developing any fixes for it.
> 

Oh great, that's really the way to go to make progress.

> My comments are about the _two months_ its taken to get to the stage of
> finding out that you don't like the approach.
> 

While I can understand some of the frustration, I don't get why you are
giving up so easily.

> The result of this is, most likely, one of:
> 1. you'll revert the patch (which, incidentally, has no real effect until
>    my other patches get merged) and everyone will either be stuck with a
>    kernel that sets their RTC time wrong when they have NTP installed
> 

Or when using hwclock from util-linux

> 2. you'll remove the systohc code, people won't realise that their kernel
>    no longer sync's the RTC time, and systems that are on the Internet
>    (eg, providing stratum 1 NTP servers) will be unreliable if they are
>    rebooted even more so than they are today.
> 
> > On my side, I want to take the opportunity to think about systohc before
> > adding an ABI that we will maybe regret later.
> 
> Fine, but bear in mind that I don't care anymore, because I have
> perfectly good fixes locally, and I'm not wasting any further time
> in this issue.
> 
> While you think about it, I would encourage anyone who wishing to run
> or running a public NTP server using rtclib to ditch Linux and use
> FreeBSD instead to avoid their NTP server supplying false time, even
> when synchronised to a reference clock.  A reboot of such a server
> will supply false time for a period of a few hours depending on how
> far the time is out (which can be up to a couple of seconds) after
> such an event.  In such a scenario, NTP will not step-correct the
> time but will gradually slew it instead.
> 
> This goes for systems that some ISPs deploy as stratum 1 NTP servers,
> which today tend to be Raspberry Pis.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH] rtc: Allow rtc drivers to specify the tv_nsec value for ntp
From: Alexandre Belloni @ 2017-11-30 19:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171128102025.GT31757@n2100.armlinux.org.uk>

On 28/11/2017 at 10:20:25 +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 27, 2017 at 08:31:35PM +0100, Alexandre Belloni wrote:
> > On 27/11/2017 at 18:53:52 +0000, Russell King - ARM Linux wrote:
> > > You are, yet again, wrong.
> > > 
> > > I am in a position to make the comment because it was me who identified
> > > the problem, put in the hours to work on, develop and extensively test
> > > Jason's patch.  So, it's partly my time that you seem to be wasting,
> > > and that gives me every right to complain at this point.
> > > 
> > > You, on the other hand, were copied with every single email, and did
> > > nothing to discuss the issue except for the "easy" bits when I posted
> > > a relatively smaller patch - but you ignored the bigger issue.
> > 
> > And this is exactly what you do with other people patches/time when you
> > don't like their changes.
> > You simply ignore the patch series until they go away.
> 
> That is not intentional.
> 

So please, don't assume that I replied late intentionally.

> > I would really expect people merging code in any subsystem to wait for
> > the ack of the maintainer of that subsystem.
> > 
> > I didn't complain about any missing email addresses, I said the RTC ML
> > was not copied but that is didn't matter.
> 
> A mailing list is an email address.
> 

Yes and again, this was a non issue, simply that the patch was not in
the RTC patchwork but that is completely irrelevant to the matter.

> Now you're making crap up.  I've not made any comment about this being
> something that needs fixing urgently.  In fact, as I've said several
> times already, I really don't care what you do with the mainline kernel,
> because I have a fix here locally that I intend to use and maintain
> into the future.  For me, the issue is fixed and resolved, and I intend
> to spend no further time developing any fixes for it.
> 
> My comments are about the _two months_ its taken to get to the stage of
> finding out that you don't like the approach.
> 

Again, sorry, this was not intentional.

> The result of this is, most likely, one of:
> 1. you'll revert the patch (which, incidentally, has no real effect until
>    my other patches get merged) and everyone will either be stuck with a
>    kernel that sets their RTC time wrong when they have NTP installed
> 

Ok, let's not waste everything. I think the main issue is that I still
don't get how this can actually improve the situation with regards to
userspace. Can you share your series so I could maybe understand? I'm
especially interested in how you will handle the pcf8523 (if you did
that of course).


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH 08/37] KVM: arm64: Defer restoring host VFP state to vcpu_put
From: Marc Zyngier @ 2017-11-30 19:07 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171126185852.bjte7raycorctft2@yury-thinkpad>

On 26/11/17 18:58, Yury Norov wrote:
> On Sun, Nov 26, 2017 at 05:17:16PM +0100, Christoffer Dall wrote:
>> Hi Yury,
>>
>> On Sat, Nov 25, 2017 at 10:52:21AM +0300, Yury Norov wrote:
>>>
>>> On Thu, Oct 12, 2017 at 12:41:12PM +0200, Christoffer Dall wrote:
>>>> Avoid saving the guest VFP registers and restoring the host VFP
>>>> registers on every exit from the VM.  Only when we're about to run
>>>> userspace or other threads in the kernel do we really have to switch the
>>>> state back to the host state.
>>>>
>>>> We still initially configure the VFP registers to trap when entering the
>>>> VM, but the difference is that we now leave the guest state in the
>>>> hardware registers while running the VM.
>>>>
>>>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>>>> ---
>>>>  arch/arm64/include/asm/kvm_emulate.h |  5 ++++
>>>>  arch/arm64/include/asm/kvm_host.h    |  3 +++
>>>>  arch/arm64/kernel/asm-offsets.c      |  1 +
>>>>  arch/arm64/kvm/hyp/entry.S           |  3 +++
>>>>  arch/arm64/kvm/hyp/switch.c          | 47 +++++++++++-------------------------
>>>>  arch/arm64/kvm/hyp/sysreg-sr.c       | 21 +++++++++++++---
>>>>  6 files changed, 44 insertions(+), 36 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
>>>> index 1fbfe96..630dd60 100644
>>>> --- a/arch/arm64/include/asm/kvm_emulate.h
>>>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>>>> @@ -56,6 +56,11 @@ static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
>>>>  	return (unsigned long *)&vcpu->arch.hcr_el2;
>>>>  }
>>>>  
>>>> +static inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
>>>> +{
>>>> +	return (!(vcpu->arch.hcr_el2 & HCR_RW));
>>>> +}
>>>> +
>>>>  static inline unsigned long *vcpu_pc(const struct kvm_vcpu *vcpu)
>>>>  {
>>>>  	return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.pc;
>>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>>> index 7d3bfa7..5e09eb9 100644
>>>> --- a/arch/arm64/include/asm/kvm_host.h
>>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>>> @@ -210,6 +210,9 @@ struct kvm_vcpu_arch {
>>>>  	/* Guest debug state */
>>>>  	u64 debug_flags;
>>>>  
>>>> +	/* 1 if the guest VFP state is loaded into the hardware */
>>>> +	u64 guest_vfp_loaded;
>>>
>>> May it be just u8/bool?
>>>
>> This particular field is accessed from assembly code, and I'm not sure
>> what guarantees the compiler makes in terms of how a u8/bool is
>> allocated with respect to padding and alignment, and I think that's why
>> we've been using u64 fields in the past.
>>
>> I don't actually remember the details, but I'd rather err on the side of
>> caution than trying to save a few bytes.  However, if someone can
>> convince me there's a completely safe way to do this, then I'm happy to
>> change it.
> 
> 'strb     w0, [x3, #VCPU_GUEST_VFP_LOADED]' would work. See
> C6.6.181 STRB (register) in ARM64 ARM.
> 
> The only thing I would recommend is to reorder fields in kvm_vcpu_arch
> to avoid unneeded holes in the structure. It already spend 10 bytes for
> nothing in 3 holes.

Terrifying. How many vcpu are you going to run before this becomes a
real bottleneck? KVM on a 6502? ;-)

Now, when it comes to reordering fields, please keep in mind that the
order of the fields in the structure does matter. We want the hottest
fields grouped together so that they are fetched in the same cache line.

Thanks,

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

^ permalink raw reply

* [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: Russell King - ARM Linux @ 2017-11-30 18:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130182621.GC28828@lunn.ch>

On Thu, Nov 30, 2017 at 07:26:21PM +0100, Andrew Lunn wrote:
> On Thu, Nov 30, 2017 at 06:15:20PM +0000, Russell King - ARM Linux wrote:
> > On Thu, Nov 30, 2017 at 06:41:27PM +0100, Andrew Lunn wrote:
> > > SGMII supports passing auto-negotiation results from the PHY to the
> > > MAC. 1000BASE-X does not.
> > > 
> > > SGMII supports the PHY running at 10, 100, and 1000 Mbps. But to
> > > support this, the MAC needs to replicate the bits 100, or 10 times
> > > when the PHY is running in 10 or 100Mbps mode.
> > > 
> > > So with your 2.5G SGMII, you need to replicate the bits 250, 25, or
> > > 2.5 times if they PHY is running at lower speeds. This last one is
> > > interesting.
> > 
> > That's not what I've read so far - but I don't know about the PHY
> > in this exact case because the docs are only available under NDA
> > (which makes it incredibly difficult to have this discussion.)
> > 
> > However, from what I can ascertain from a Xilinx document, 2.5G is
> > 1G SGMII clocked 2.5x faster.  When in 2.5G mode, the other modes
> > are unavailable.
> 
> Hi Russell
> 
> Thanks for looking into the details.
> 
> So you need the PHY driver to see what it has negotiated, and when it
> calls the adjust_link callback, the MAC needs look at the
> phydev->interface and set the MAC to 2.5G SGMII or SGMII.

Yes, it /looks/ that way from what I've read so far.  I'd like to do
a more comprehensive look around at what various manufacturers are
doing before saying that definitively.  Even better would be to find
a specification for 2.5G SGMII!

> Same as the Marvell 10G PHY driver flips between
> PHY_INTERFACE_MODE_10GKR and PHY_INTERFACE_MODE_SGMII depending on
> what it has negotiated.

Having played extensively with the Marvell 88x3310 and thoroughly
inspected its registers and analysed its behaviour, I'd be hessitant
to compare other PHYs with it.  The 3310 PHY seems to be multiple PHY
blocks (from two vendors) in a single package, and it dynamically
switches in the appropriate hardware blocks according to the negotiated
link modes.

However, given that 1G SGMII is clocked at a different rate from 2.5G
SGMII, both ends would need to be configured the same.

For example, both mvneta and mvpp2.2 support 2.5G modes merely by
reconfiguring the comphy block, and all that does is increase the
serdes clock.  That's used for 2500BASE-X (which I have had working
locally through a devmem2 pokes on Clearfog and the older Marvell
pp2x driver on Macchiatobin) but it's more difficult to find 2.5G
copper SFP modules to test with - which would presumably talk 2.5G
SGMII.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply

* [PATCH v2 2/2] ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850
From: Peter Rosin @ 2017-11-30 18:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130172606.GZ21126@piout.net>

On 2017-11-30 18:26, Alexandre Belloni wrote:
> On 30/11/2017 at 09:16:38 -0800, Guenter Roeck wrote:
>> On Wed, Nov 29, 2017 at 09:56:29PM +0100, Alexandre Belloni wrote:
>>> On 29/11/2017 at 12:53:11 -0800, Guenter Roeck wrote:
>>>> On Mon, Nov 27, 2017 at 05:31:01PM +0100, Peter Rosin wrote:
>>>>> The I2C adapter driver is sometimes slow, causing the SCL line to
>>>>> be stuck low for more than the stipulated SMBUS timeout of 25-35 ms.
>>>>> This causes the client device to give up which in turn causes silent
>>>>> corruption of data. So, disable the SMBUS timeout in the client device.
>>>>>
>>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>>>
>>>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>>>
>>>> I assume this will be sent upstream through an arm tree.
>>>>
>>>
>>> Yes, I'm applying it right now.
>>>
>> Are you going to apply the patch for 4.15, or queue it up for 4.16 ?
>> I have been arguing with myself if this is a feature or a bug fix.
>> So far I queued the driver change up for 4.16, but I am open to
>> applying it to 4.15. Any thoughts ?
>>
> 
> I was wondering that myself. I'm open to have it as a fix in 4.15. Or
> maybe Peter can send the series to stable if he needs it in 4.14.
> 
> Peter, what do you think/want?

TL;DR Either way is fine.

I think it's a bugfix; it fixes real problems where the application
misbehave due to faulty content when reading from an eeprom. I'm
expecting to make a new release for the hw in question RSN and these
are the only local patches. So, it would be nice if they made it to
4.14.x before my release happens. However, it's not like it's difficult
to rebase the patches should that backport not happen or take too long.

The badness started to happen much more frequently due to some timing
difference affecting the i2c bus driver, but in theory it's a problem
that has been there from the start. I have just not noticed it before...

Cheers,
Peter

^ permalink raw reply

* [PATCH RFC 2/2] arm64: allwinner: a64: Add Brava Keller initial support
From: Jagan Teki @ 2017-11-30 18:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1512067334-12761-1-git-send-email-jagan@amarulasolutions.com>

Brava Keller is A64 based IoT device, which support
- Allwinner A64 Cortex-A53
- AXP803 PMIC
- 1GB DDR3 RAM
- 8GB eMMC
- Mali-400MP2 GPU
- AP6330 Wifi/BLE
- Camera OV5640
- USB Host and OTG

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Note: Need to test it on hardware
 
 arch/arm64/boot/dts/allwinner/Makefile             |   1 +
 .../boot/dts/allwinner/sun50i-a64-brava-keller.dts | 244 +++++++++++++++++++++
 2 files changed, 245 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index f505227..af80ca0 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-brava-keller.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
new file mode 100644
index 0000000..f5303a3
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
@@ -0,0 +1,244 @@
+/*
+ * Copyright (C) 2017 Jagan Teki <jagan@amarulasolutions.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	model = "Brava Keller";
+	compatible = "brava,brava-keller", "allwinner,sun50i-a64";
+
+	aliases {
+		serial2 = &uart2;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	wifi_pwrseq: wifi_pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		reset-gpios = <&pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
+		post-power-on-delay-ms = <200>;
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_dldo4>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+
+	brcmf: wifi at 1 {
+		reg = <1>;
+		compatible = "brcm,bcm4329-fmac";
+		interrupt-parent = <&r_pio>;
+		interrupts = <0 7 IRQ_TYPE_LEVEL_LOW>;	/* WL-WAKE-AP: PL3 */
+		interrupt-names = "host-wake";
+	};
+};
+
+&mmc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc2_pins>;
+	vmmc-supply = <&reg_dcdc1>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&r_rsb {
+	status = "okay";
+
+	axp803: pmic at 3a3 {
+		compatible = "x-powers,axp803";
+		reg = <0x3a3>;
+		interrupt-parent = <&r_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+#include "axp803.dtsi"
+
+&reg_aldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "avdd-csi";
+};
+
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vcc-pl";
+};
+
+&reg_aldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-pll-avcc";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-3v3";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1040000>;
+	regulator-max-microvolt = <1300000>;
+	regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1500000>;
+	regulator-max-microvolt = <1500000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_dcdc6 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_dldo1 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-hdmi-dsi-sensor";
+};
+
+&reg_dldo2 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-mipi";
+};
+
+&reg_dldo3 {
+	regulator-min-microvolt = <2800000>;
+	regulator-max-microvolt = <2800000>;
+	regulator-name = "vcc-gen";
+};
+
+&reg_dldo4 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi-io";
+};
+
+&reg_eldo1 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "cpvdd";
+};
+
+&reg_fldo1 {
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vcc-1v2-hsic";
+};
+
+/*
+ * The A64 chip cannot work without this regulator off, although
+ * it seems to be only driving the AR100 core.
+ * Maybe we don't still know well about CPUs domain.
+ */
+&reg_fldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpus";
+};
+
+&reg_rtc_ldo {
+	regulator-name = "vcc-rtc";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart2_pins>;
+	status = "okay";
+};
+
+&usbphy {
+	status = "okay";
+};
-- 
2.7.4

^ permalink raw reply related

* [PATCH RFC 1/2] dt-bindings: Add vendor prefix for Brava Home
From: Jagan Teki @ 2017-11-30 18:42 UTC (permalink / raw)
  To: linux-arm-kernel

Added 'brava' as a vendor prefix for Brava Home, Inc.
which is consumer electronics and IoT company.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 9bce76f..6004c3f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -54,6 +54,7 @@ bhf	Beckhoff Automation GmbH & Co. KG
 boe	BOE Technology Group Co., Ltd.
 bosch	Bosch Sensortec GmbH
 boundary	Boundary Devices Inc.
+brava	Brava Home, Inc.
 brcm	Broadcom Corporation
 buffalo	Buffalo, Inc.
 calxeda	Calxeda
-- 
2.7.4

^ permalink raw reply related

* [PATCH v2] watchdog: stm32: Fix copyright
From: Guenter Roeck @ 2017-11-30 18:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130084804.23693-1-benjamin.gaignard@st.com>

On Thu, Nov 30, 2017 at 09:48:04AM +0100, Benjamin Gaignard wrote:
> Uniformize STMicroelectronics copyrights header
> Add SPDX identifier
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
> CC: Yannick Fertre <yannick.fertre@st.com>

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

> ---
>  drivers/watchdog/stm32_iwdg.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
> index be64a8699de3..c97ad5619cb0 100644
> --- a/drivers/watchdog/stm32_iwdg.c
> +++ b/drivers/watchdog/stm32_iwdg.c
> @@ -1,12 +1,12 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Driver for STM32 Independent Watchdog
>   *
> - * Copyright (C) Yannick Fertre 2017
> - * Author: Yannick Fertre <yannick.fertre@st.com>
> + * Copyright (C) STMicroelectronics 2017
> + * Author: Yannick Fertre <yannick.fertre@st.com> for STMicroelectronics.
>   *
>   * This driver is based on tegra_wdt.c
>   *
> - * License terms:  GNU General Public License (GPL), version 2
>   */
>  
>  #include <linux/clk.h>
> -- 
> 2.15.0
> 

^ permalink raw reply

* [PATCH 37/37] KVM: arm/arm64: Avoid VGICv3 save/restore on VHE with no IRQs
From: Yury Norov @ 2017-11-30 18:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171012104141.26902-38-christoffer.dall@linaro.org>

On Thu, Oct 12, 2017 at 12:41:41PM +0200, Christoffer Dall wrote:
> We can finally get completely rid of any calls to the VGICv3
> save/restore functions when the AP lists are empty on VHE systems.  This
> requires carefully factoring out trap configuration from saving and
> restoring state, and carefully choosing what to do on the VHE and
> non-VHE path.
> 
> One of the challenges is that we cannot save/restore the VMCR lazily
> because we can only write the VMCR when ICC_SRE_EL1.SRE is cleared when
> emulating a GICv2-on-GICv3, since otherwise all Group-0 interrupts end
> up being delivered as FIQ.
> 
> To solve this problem, and still provide fast performance in the fast
> path of exiting a VM when no interrupts are pending (which also
> optimized the latency for actually delivering virtual interrupts coming
> from physical interrupts), we orchestrate a dance of only doing the
> activate/deactivate traps in vgic load/put for VHE systems (which can
> have ICC_SRE_EL1.SRE cleared when running in the host), and doing the
> configuration on every round-trip on non-VHE systems.
> 
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
>  arch/arm/include/asm/kvm_hyp.h   |   2 +
>  arch/arm/kvm/hyp/switch.c        |   8 ++-
>  arch/arm64/include/asm/kvm_hyp.h |   2 +
>  arch/arm64/kvm/hyp/switch.c      |   8 ++-
>  virt/kvm/arm/hyp/vgic-v3-sr.c    | 116 +++++++++++++++++++++++++--------------
>  virt/kvm/arm/vgic/vgic-v3.c      |   6 ++
>  virt/kvm/arm/vgic/vgic.c         |   7 +--
>  7 files changed, 101 insertions(+), 48 deletions(-)

[...]

> diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
> index ed5da75..34d71d2 100644
> --- a/virt/kvm/arm/hyp/vgic-v3-sr.c
> +++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
> @@ -208,15 +208,15 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
>  {
>  	struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
>  	u64 used_lrs = vcpu->arch.vgic_cpu.used_lrs;
> -	u64 val;
>  
>  	/*
>  	 * Make sure stores to the GIC via the memory mapped interface
> -	 * are now visible to the system register interface.
> +	 * are now visible to the system register interface when reading the
> +	 * LRs, and when reading back the VMCR on non-VHE systems.
>  	 */
> -	if (!cpu_if->vgic_sre) {
> -		dsb(st);
> -		cpu_if->vgic_vmcr = read_gicreg(ICH_VMCR_EL2);
> +	if (used_lrs || !has_vhe()) {
> +		if (!cpu_if->vgic_sre)
> +			dsb(st);
>  	}

Nit:
	if ((used_lrs || !has_vhe()) && !cpu_if->vgic_sre)
		dsb(st);

>  
>  	if (used_lrs) {
> @@ -225,7 +225,7 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
>  
>  		elrsr = read_gicreg(ICH_ELSR_EL2);
>  
> -		write_gicreg(0, ICH_HCR_EL2);
> +		write_gicreg(cpu_if->vgic_hcr & ~ICH_HCR_EN, ICH_HCR_EL2);
>  
>  		for (i = 0; i < used_lrs; i++) {
>  			if (elrsr & (1 << i))
> @@ -235,18 +235,6 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
>  
>  			__gic_v3_set_lr(0, i);
>  		}
> -	} else {
> -		if (static_branch_unlikely(&vgic_v3_cpuif_trap))
> -			write_gicreg(0, ICH_HCR_EL2);
> -	}
> -
> -	val = read_gicreg(ICC_SRE_EL2);
> -	write_gicreg(val | ICC_SRE_EL2_ENABLE, ICC_SRE_EL2);
> -
> -	if (!cpu_if->vgic_sre) {
> -		/* Make sure ENABLE is set at EL2 before setting SRE at EL1 */
> -		isb();
> -		write_gicreg(1, ICC_SRE_EL1);
>  	}
>  }
>  
> @@ -256,6 +244,31 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
>  	u64 used_lrs = vcpu->arch.vgic_cpu.used_lrs;
>  	int i;
>  
> +	if (used_lrs) {
> +		write_gicreg(cpu_if->vgic_hcr, ICH_HCR_EL2);
> +
> +		for (i = 0; i < used_lrs; i++)
> +			__gic_v3_set_lr(cpu_if->vgic_lr[i], i);
> +	}
> +
> +	/*
> +	 * Ensure that writes to the LRs, and on non-VHE systems ensure that
> +	 * the write to the VMCR in __vgic_v3_activate_traps(), will have
> +	 * reached the (re)distributors. This ensure the guest will read the
> +	 * correct values from the memory-mapped interface.
> +	 */
> +	if (used_lrs || !has_vhe()) {
> +		if (!cpu_if->vgic_sre) {
> +			isb();
> +			dsb(sy);
> +		}
> +	}

And here

> +}
> +

^ permalink raw reply

* [PATCH v2 11/18] arm64: mm: Map entry trampoline into trampoline and kernel page tables
From: Mark Rutland @ 2017-11-30 18:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1512059986-21325-12-git-send-email-will.deacon@arm.com>

Hi Will,

On Thu, Nov 30, 2017 at 04:39:39PM +0000, Will Deacon wrote:
> diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
> index 4052ec39e8db..8119b49be98d 100644
> --- a/arch/arm64/include/asm/fixmap.h
> +++ b/arch/arm64/include/asm/fixmap.h
> @@ -58,6 +58,10 @@ enum fixed_addresses {
>  	FIX_APEI_GHES_NMI,
>  #endif /* CONFIG_ACPI_APEI_GHES */
>  
> +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> +	FIX_ENTRY_TRAMP_TEXT,
> +#define TRAMP_VALIAS		(__fix_to_virt(FIX_ENTRY_TRAMP_TEXT))
> +#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
>  	__end_of_permanent_fixed_addresses,

Defining TRAMP_VALIAS here is a little surprising, especially given we
reuse the name in asm-offsets:

> +  DEFINE(TRAMP_VALIAS,		TRAMP_VALIAS);

Can't we have asm-offsets do:

  DEFINE(TRAMP_VALIAS, __fix_to_virt(FIX_ENTRY_TRAMP_TEXT));

... and rely on the asm-offsets TRAMP_VALIAS definition everywhere?

[...]

> +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> +static int __init map_entry_trampoline(void)
> +{
> +	extern char __entry_tramp_text_start[];
> +
> +	pgprot_t prot = rodata_enabled ? PAGE_KERNEL_ROX : PAGE_KERNEL_EXEC;
> +	phys_addr_t pa_start = __pa_symbol(__entry_tramp_text_start);
> +
> +	/* The trampoline is always mapped and can therefore be global */
> +	pgprot_val(prot) &= ~PTE_NG;
> +
> +	/* Map only the text into the trampoline page table */
> +	memset((char *)tramp_pg_dir, 0, PGD_SIZE);

The (char *) cast can go; memset() takes a void pointer and we don't do
similar casts for other memset instances.

> +	__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
> +			     prot, pgd_pgtable_alloc, 0);
> +
> +	/* ...as well as the kernel page table */

This might be clearer as:

	/* map the text in the kernel page table, too */

Otherwise, this looks good to me.

Thanks,
Mark.

^ permalink raw reply

* [PATCH] arm64: context: Fix comments and remove pointless smp_wmb()
From: Will Deacon @ 2017-11-30 18:28 UTC (permalink / raw)
  To: linux-arm-kernel

The comments in the ASID allocator incorrectly hint at an MP-style idiom
using the asid_generation and the active_asids array. In fact, the
synchronisation is achieved using a combination of an xchg operation
and a spinlock, so update the comments and remove the pointless smp_wmb().

Cc: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm64/mm/context.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index ab9f5f0fb2c7..98fcecae0827 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -96,12 +96,6 @@ static void flush_context(unsigned int cpu)
 
 	set_reserved_asid_bits();
 
-	/*
-	 * Ensure the generation bump is observed before we xchg the
-	 * active_asids.
-	 */
-	smp_wmb();
-
 	for_each_possible_cpu(i) {
 		asid = atomic64_xchg_relaxed(&per_cpu(active_asids, i), 0);
 		/*
@@ -202,11 +196,18 @@ void check_and_switch_context(struct mm_struct *mm, unsigned int cpu)
 	asid = atomic64_read(&mm->context.id);
 
 	/*
-	 * The memory ordering here is subtle. We rely on the control
-	 * dependency between the generation read and the update of
-	 * active_asids to ensure that we are synchronised with a
-	 * parallel rollover (i.e. this pairs with the smp_wmb() in
-	 * flush_context).
+	 * The memory ordering here is subtle.
+	 * If our ASID matches the current generation, then we update
+	 * our active_asids entry with a relaxed xchg. Racing with a
+	 * concurrent rollover means that either:
+	 *
+	 * - We get a zero back from the xchg and end up waiting on the
+	 *   lock. Taking the lock synchronises with the rollover and so
+	 *   we are forced to see the updated generation.
+	 *
+	 * - We get a valid ASID back from the xchg, which means the
+	 *   relaxed xchg in flush_context will treat us as reserved
+	 *   because atomic RmWs are totally ordered for a given location.
 	 */
 	if (!((asid ^ atomic64_read(&asid_generation)) >> asid_bits)
 	    && atomic64_xchg_relaxed(&per_cpu(active_asids, cpu), asid))
-- 
2.1.4

^ permalink raw reply related

* [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: Andrew Lunn @ 2017-11-30 18:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130181520.GF10595@n2100.armlinux.org.uk>

On Thu, Nov 30, 2017 at 06:15:20PM +0000, Russell King - ARM Linux wrote:
> On Thu, Nov 30, 2017 at 06:41:27PM +0100, Andrew Lunn wrote:
> > SGMII supports passing auto-negotiation results from the PHY to the
> > MAC. 1000BASE-X does not.
> > 
> > SGMII supports the PHY running at 10, 100, and 1000 Mbps. But to
> > support this, the MAC needs to replicate the bits 100, or 10 times
> > when the PHY is running in 10 or 100Mbps mode.
> > 
> > So with your 2.5G SGMII, you need to replicate the bits 250, 25, or
> > 2.5 times if they PHY is running at lower speeds. This last one is
> > interesting.
> 
> That's not what I've read so far - but I don't know about the PHY
> in this exact case because the docs are only available under NDA
> (which makes it incredibly difficult to have this discussion.)
> 
> However, from what I can ascertain from a Xilinx document, 2.5G is
> 1G SGMII clocked 2.5x faster.  When in 2.5G mode, the other modes
> are unavailable.

Hi Russell

Thanks for looking into the details.

So you need the PHY driver to see what it has negotiated, and when it
calls the adjust_link callback, the MAC needs look at the
phydev->interface and set the MAC to 2.5G SGMII or SGMII.

Same as the Marvell 10G PHY driver flips between
PHY_INTERFACE_MODE_10GKR and PHY_INTERFACE_MODE_SGMII depending on
what it has negotiated.

     Andrew

^ permalink raw reply

* [PATCH 2/2] ARM: multi_v7_defconfig: Enable missing drivers for supported Exynos boards
From: Krzysztof Kozlowski @ 2017-11-30 18:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130091004.22971-2-m.szyprowski@samsung.com>

On Thu, Nov 30, 2017 at 10:10:04AM +0100, Marek Szyprowski wrote:
> Enable following drivers for recently merged devices:
> - CEC and S5P CEC driver for all Exynos4 and Exynos5 boards with HDMI
> - Sii9234 DRM HDMI-MHL bridge for Trats2
> - dedicated Odroid ASoC machine driver for Odroid XU3/XU4
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  arch/arm/configs/multi_v7_defconfig | 5 +++++
>  1 file changed, 5 insertions(+)
> 

Thanks, applied.

Best regards,
Krzysztof

^ permalink raw reply

* [PATCH 1/2] ARM: exynos_defconfig: Enable missing drivers for supported Exynos boards
From: Krzysztof Kozlowski @ 2017-11-30 18:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130091004.22971-1-m.szyprowski@samsung.com>

On Thu, Nov 30, 2017 at 10:10:03AM +0100, Marek Szyprowski wrote:
> Enable following drivers for recently merged devices:
> - perf events and ARM PMU (Performance Measurement Unit) driver for all
>   Exynos boards
> - CEC and S5P CEC driver for all Exynos4 and Exynos5 boards with HDMI
> - Sii9234 DRM HDMI-MHL bridge for Trats2
> - dedicated Odroid ASoC machine driver for Odroid XU3/XU4
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  arch/arm/configs/exynos_defconfig | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Thanks, applied.

Best regards,
Krzysztof

^ permalink raw reply

* [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: Russell King - ARM Linux @ 2017-11-30 18:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130174127.GA28828@lunn.ch>

On Thu, Nov 30, 2017 at 06:41:27PM +0100, Andrew Lunn wrote:
> SGMII supports passing auto-negotiation results from the PHY to the
> MAC. 1000BASE-X does not.
> 
> SGMII supports the PHY running at 10, 100, and 1000 Mbps. But to
> support this, the MAC needs to replicate the bits 100, or 10 times
> when the PHY is running in 10 or 100Mbps mode.
> 
> So with your 2.5G SGMII, you need to replicate the bits 250, 25, or
> 2.5 times if they PHY is running at lower speeds. This last one is
> interesting.

That's not what I've read so far - but I don't know about the PHY
in this exact case because the docs are only available under NDA
(which makes it incredibly difficult to have this discussion.)

However, from what I can ascertain from a Xilinx document, 2.5G is
1G SGMII clocked 2.5x faster.  When in 2.5G mode, the other modes
are unavailable.  There's also no 250M or 25M as the speed bits
are not relevant.

The Xilinx doc does talk about a "2.5G SGMII standard" but I haven't
been able to locate such a thing - maybe someone can provide some
pointers?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

^ permalink raw reply

* [PATCH v2] ARM: dts: imx7d-pico-pi: Separate into cpu and baseboard dts
From: Vanessa Maegima @ 2017-11-30 17:55 UTC (permalink / raw)
  To: linux-arm-kernel

Separate the old imx7d-pico into cpu (imx7d-pico.dtsi) and baseboard
(imx7d-pico-pi.dts) dts so the same cpu dtsi can be used in different
baseboards variants.

Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
---
Changes since v1:
- Use imx/dt branch
- Remove sai1 node from imx7d-pico.dtsi and add to imx7d-pico-pi.dts

 arch/arm/boot/dts/Makefile                         |   2 +-
 arch/arm/boot/dts/imx7d-pico-pi.dts                | 182 +++++++++++++++++++++
 .../boot/dts/{imx7d-pico.dts => imx7d-pico.dtsi}   | 133 ---------------
 3 files changed, 183 insertions(+), 134 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx7d-pico-pi.dts
 rename arch/arm/boot/dts/{imx7d-pico.dts => imx7d-pico.dtsi} (71%)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b5ba7ad..73dd719 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -521,7 +521,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
 	imx7d-cl-som-imx7.dtb \
 	imx7d-colibri-eval-v3.dtb \
 	imx7d-nitrogen7.dtb \
-	imx7d-pico.dtb \
+	imx7d-pico-pi.dtb \
 	imx7d-sbc-imx7.dtb \
 	imx7d-sdb.dtb \
 	imx7d-sdb-sht11.dtb \
diff --git a/arch/arm/boot/dts/imx7d-pico-pi.dts b/arch/arm/boot/dts/imx7d-pico-pi.dts
new file mode 100644
index 0000000..6c67ef8
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-pico-pi.dts
@@ -0,0 +1,182 @@
+/*
+ * Copyright 2017 NXP
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx7d-pico.dtsi"
+
+/ {
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,name = "imx7-sgtl5000";
+		simple-audio-card,format = "i2s";
+		simple-audio-card,bitclock-master = <&dailink_master>;
+		simple-audio-card,frame-master = <&dailink_master>;
+		simple-audio-card,cpu {
+			sound-dai = <&sai1>;
+		};
+
+		dailink_master: simple-audio-card,codec {
+			sound-dai = <&codec>;
+			clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+		};
+	};
+};
+
+&fec1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet1>;
+	assigned-clocks = <&clks IMX7D_ENET1_TIME_ROOT_SRC>,
+			  <&clks IMX7D_ENET1_TIME_ROOT_CLK>;
+	assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
+	assigned-clock-rates = <0>, <100000000>;
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy0>;
+	fsl,magic-packet;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy0: ethernet-phy at 1 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <1>;
+			status = "okay";
+		};
+	};
+};
+
+&i2c1 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+
+	codec: sgtl5000 at a {
+		#sound-dai-cells = <0>;
+		reg = <0x0a>;
+		compatible = "fsl,sgtl5000";
+		clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
+		VDDA-supply = <&reg_2p5v>;
+		VDDIO-supply = <&reg_vref_1v8>;
+	};
+};
+
+
+&sai1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_sai1>;
+	assigned-clocks = <&clks IMX7D_SAI1_ROOT_SRC>,
+			  <&clks IMX7D_SAI1_ROOT_CLK>;
+	assigned-clock-parents = <&clks IMX7D_PLL_AUDIO_POST_DIV>;
+	assigned-clock-rates = <0>, <24576000>;
+	status = "okay";
+};
+
+&uart5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart5>;
+	assigned-clocks = <&clks IMX7D_UART5_ROOT_SRC>;
+	assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+	status = "okay";
+};
+
+&usbotg1 {
+	vbus-supply = <&reg_usb_otg1_vbus>;
+	status = "okay";
+};
+
+&usbotg2 {
+	vbus-supply = <&reg_usb_otg2_vbus>;
+	dr_mode = "host";
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_enet1: enet1grp {
+		fsl,pins = <
+			MX7D_PAD_SD2_CD_B__ENET1_MDIO			0x3
+			MX7D_PAD_SD2_WP__ENET1_MDC			0x3
+			MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC	0x1
+			MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0	0x1
+			MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1	0x1
+			MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2	0x1
+			MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3	0x1
+			MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL	0x1
+			MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC	0x1
+			MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0	0x1
+			MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1	0x1
+			MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2	0x1
+			MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3	0x1
+			MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL	0x1
+		>;
+	};
+
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins = <
+			MX7D_PAD_UART1_TX_DATA__I2C1_SDA	0x4000007f
+			MX7D_PAD_UART1_RX_DATA__I2C1_SCL	0x4000007f
+		>;
+	};
+
+	pinctrl_sai1: sai1grp {
+		fsl,pins = <
+			MX7D_PAD_ENET1_RX_CLK__SAI1_TX_BCLK	0x1f
+			MX7D_PAD_ENET1_CRS__SAI1_TX_SYNC	0x1f
+			MX7D_PAD_ENET1_COL__SAI1_TX_DATA0	0x30
+			MX7D_PAD_ENET1_TX_CLK__SAI1_RX_DATA0	0x1f
+		>;
+	};
+
+	pinctrl_uart5: uart5grp {
+		fsl,pins = <
+			MX7D_PAD_I2C4_SDA__UART5_DCE_TX		0x79
+			MX7D_PAD_I2C4_SCL__UART5_DCE_RX		0x79
+		>;
+	};
+
+	pinctrl_usbotg1_pwr: usbotg_pwr {
+		fsl,pins = <
+			MX7D_PAD_UART3_TX_DATA__GPIO4_IO5	0x14
+		>;
+	};
+};
+
diff --git a/arch/arm/boot/dts/imx7d-pico.dts b/arch/arm/boot/dts/imx7d-pico.dtsi
similarity index 71%
rename from arch/arm/boot/dts/imx7d-pico.dts
rename to arch/arm/boot/dts/imx7d-pico.dtsi
index 508328b..e307462 100644
--- a/arch/arm/boot/dts/imx7d-pico.dts
+++ b/arch/arm/boot/dts/imx7d-pico.dtsi
@@ -100,62 +100,6 @@
 		regulator-min-microvolt = <1800000>;
 		regulator-max-microvolt = <1800000>;
 	};
-
-	sound {
-		compatible = "simple-audio-card";
-		simple-audio-card,name = "imx7-sgtl5000";
-		simple-audio-card,format = "i2s";
-		simple-audio-card,bitclock-master = <&dailink_master>;
-		simple-audio-card,frame-master = <&dailink_master>;
-		simple-audio-card,cpu {
-			sound-dai = <&sai1>;
-		};
-
-		dailink_master: simple-audio-card,codec {
-			sound-dai = <&codec>;
-			clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
-		};
-	};
-};
-
-&fec1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet1>;
-	assigned-clocks = <&clks IMX7D_ENET1_TIME_ROOT_SRC>,
-			  <&clks IMX7D_ENET1_TIME_ROOT_CLK>;
-	assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
-	assigned-clock-rates = <0>, <100000000>;
-	phy-mode = "rgmii";
-	phy-handle = <&ethphy0>;
-	fsl,magic-packet;
-	status = "okay";
-
-	mdio {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		ethphy0: ethernet-phy at 1 {
-			compatible = "ethernet-phy-ieee802.3-c22";
-			reg = <1>;
-			status = "okay";
-		};
-	};
-};
-
-&i2c1 {
-	clock-frequency = <100000>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_i2c1>;
-	status = "okay";
-
-	codec: sgtl5000 at a {
-		#sound-dai-cells = <0>;
-		reg = <0x0a>;
-		compatible = "fsl,sgtl5000";
-		clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
-		VDDA-supply = <&reg_2p5v>;
-		VDDIO-supply = <&reg_vref_1v8>;
-	};
 };
 
 &i2c4 {
@@ -253,35 +197,6 @@
 	};
 };
 
-&sai1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_sai1>;
-	assigned-clocks = <&clks IMX7D_SAI1_ROOT_SRC>,
-			  <&clks IMX7D_SAI1_ROOT_CLK>;
-	assigned-clock-parents = <&clks IMX7D_PLL_AUDIO_POST_DIV>;
-	assigned-clock-rates = <0>, <24576000>;
-	status = "okay";
-};
-
-&uart5 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart5>;
-	assigned-clocks = <&clks IMX7D_UART5_ROOT_SRC>;
-	assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
-	status = "okay";
-};
-
-&usbotg1 {
-	vbus-supply = <&reg_usb_otg1_vbus>;
-	status = "okay";
-};
-
-&usbotg2 {
-	vbus-supply = <&reg_usb_otg2_vbus>;
-	dr_mode = "host";
-	status = "okay";
-};
-
 &usdhc2 { /* Wifi SDIO */
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usdhc2>;
@@ -315,32 +230,6 @@
 };
 
 &iomuxc {
-	pinctrl_enet1: enet1grp {
-		fsl,pins = <
-			MX7D_PAD_SD2_CD_B__ENET1_MDIO			0x3
-			MX7D_PAD_SD2_WP__ENET1_MDC			0x3
-			MX7D_PAD_ENET1_RGMII_TXC__ENET1_RGMII_TXC	0x1
-			MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0	0x1
-			MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1	0x1
-			MX7D_PAD_ENET1_RGMII_TD2__ENET1_RGMII_TD2	0x1
-			MX7D_PAD_ENET1_RGMII_TD3__ENET1_RGMII_TD3	0x1
-			MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL	0x1
-			MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC	0x1
-			MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0	0x1
-			MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1	0x1
-			MX7D_PAD_ENET1_RGMII_RD2__ENET1_RGMII_RD2	0x1
-			MX7D_PAD_ENET1_RGMII_RD3__ENET1_RGMII_RD3	0x1
-			MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL	0x1
-		>;
-	};
-
-	pinctrl_i2c1: i2c1grp {
-		fsl,pins = <
-			MX7D_PAD_UART1_TX_DATA__I2C1_SDA	0x4000007f
-			MX7D_PAD_UART1_RX_DATA__I2C1_SCL	0x4000007f
-		>;
-	};
-
 	pinctrl_i2c4: i2c4grp {
 		fsl,pins = <
 			MX7D_PAD_SAI1_RX_BCLK__I2C4_SDA		0x4000007f
@@ -354,28 +243,6 @@
 		>;
 	};
 
-	pinctrl_sai1: sai1grp {
-		fsl,pins = <
-			MX7D_PAD_ENET1_RX_CLK__SAI1_TX_BCLK	0x1f
-			MX7D_PAD_ENET1_CRS__SAI1_TX_SYNC	0x1f
-			MX7D_PAD_ENET1_COL__SAI1_TX_DATA0	0x30
-			MX7D_PAD_ENET1_TX_CLK__SAI1_RX_DATA0	0x1f
-		>;
-	};
-
-	pinctrl_uart5: uart5grp {
-		fsl,pins = <
-			MX7D_PAD_I2C4_SDA__UART5_DCE_TX		0x79
-			MX7D_PAD_I2C4_SCL__UART5_DCE_RX		0x79
-		>;
-	};
-
-	pinctrl_usbotg1_pwr: usbotg_pwr {
-		fsl,pins = <
-			MX7D_PAD_UART3_TX_DATA__GPIO4_IO5	0x14
-		>;
-	};
-
 	pinctrl_usdhc2: usdhc2grp {
 		fsl,pins = <
 			MX7D_PAD_SD2_CMD__SD2_CMD		0x59
-- 
1.9.1

^ permalink raw reply related

* [PATCH v2] usb: xhci: allow imod-interval to be configurable
From: Adam Wallis @ 2017-11-30 17:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <ffa34aa3-0a1f-ba85-e7ba-356bdffa4e5a@linux.intel.com>

On 11/30/2017 3:41 AM, Mathias Nyman wrote:
[..]
> I do however mind that I don't get any default imod interval value for my
> pci based xhci host after this patch.
> That needs to be fixed
> 

Thanks Mathias, good catch. Where do you think I should initialize imod default
in PCI subsytem? I was thinking about in xhci_pci_setup but would like to hear
your thoughts since I deal much less often with USB PCI.

> Thanks
> -Mathias
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Adam

-- 
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply

* [PATCH 6/7] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold
From: Sami Tolvanen @ 2017-11-30 17:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKwvOdnhdHKvkLsG+3D5KDJ+jzXeWFPd9X+eDphA4xf5NZoDnQ@mail.gmail.com>

On Wed, Nov 29, 2017 at 04:30:33PM -0800, Nick Desaulniers wrote:
> Rather than:
> 
> if CONFIG_ARM64_ERRATUM_843419 == y:
>   ...
> if CONFIG_ARM64_ERRATUM_843419 == '':
>   ...
> 
> could this be:
> 
> if CONFIG_ARM64_ERRATUM_843419 == y:
>   ...
> else
>   ...
> 
> ?

Sure. I'll clean this up in v2.

Sami

^ permalink raw reply

* [PATCH 5/7] arm64: keep .altinstructions and .altinstr_replacement
From: Sami Tolvanen @ 2017-11-30 17:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171130115827.709f1818@roar.ozlabs.ibm.com>

On Thu, Nov 30, 2017 at 11:58:27AM +1000, Nicholas Piggin wrote:
> So yes please if it's not too much trouble, could you remove
> the "gold" name from the generic patch and put it at the front
> of the series with this arm64 patch.

Sure, I'll do this in v2.

> Possibly then you could also do a 3rd patch to allow arm64 to
> select it if it's working with gcc?

These patches only fix the issues I ran into with clang and gold
when testing on a single device.  I feel like more testing would
be needed before enabling this by default for arm64.

Sami

^ permalink raw reply


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