Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [RESEND PATCH v3 2/2] ARM: dts: imx6ul: Add DTS for liteBoard
From: Marcin Niestroj @ 2016-09-30  9:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160930093626.3843-1-m.niestroj@grinn-global.com>

liteBoard is a development board which uses liteSOM as its base.

Hardware specification:
 * liteSOM (i.MX6UL, DRAM, eMMC)
 * Ethernet PHY (id 0)
 * USB host (usb_otg1)
 * MicroSD slot (uSDHC1)

Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes v2 -> v3: none

Changes v1 -> v2:
 * Use dual license
 * Fix typo "defaullt" -> "default"

 arch/arm/boot/dts/Makefile             |   1 +
 arch/arm/boot/dts/imx6ul-liteboard.dts | 153 +++++++++++++++++++++++++++++++++
 2 files changed, 154 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6ul-liteboard.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index faacd52..b149313 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
 	imx6sx-sdb.dtb
 dtb-$(CONFIG_SOC_IMX6UL) += \
 	imx6ul-14x14-evk.dtb \
+	imx6ul-liteboard.dtb \
 	imx6ul-pico-hobbit.dtb \
 	imx6ul-tx6ul-0010.dtb \
 	imx6ul-tx6ul-0011.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-liteboard.dts b/arch/arm/boot/dts/imx6ul-liteboard.dts
new file mode 100644
index 0000000..f2e04f2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-liteboard.dts
@@ -0,0 +1,153 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.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 file 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.
+ *
+ *     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 , 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 "imx6ul-litesom.dtsi"
+
+/ {
+	model = "Grinn i.MX6UL liteBoard";
+	compatible = "grinn,imx6ul-liteboard", "grinn,imx6ul-litesom",
+		     "fsl,imx6ul";
+
+	chosen {
+		stdout-path = &uart1;
+	};
+
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		reg_usb_otg1_vbus: usb_otg1_regulator {
+			compatible = "regulator-fixed";
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_usb_otg1_vbus>;
+			regulator-name = "usb_otg1_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			gpio = <&gpio2 8 GPIO_ACTIVE_LOW>;
+		};
+	};
+};
+
+&iomuxc {
+	pinctrl_enet1: enet1grp {
+		fsl,pins = <
+			MX6UL_PAD_GPIO1_IO07__ENET1_MDC		0x1b0b0
+			MX6UL_PAD_GPIO1_IO06__ENET1_MDIO	0x1b0b0
+			MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN	0x1b0b0
+			MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER	0x1b0b0
+			MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+			MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+			MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN	0x1b0b0
+			MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+			MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+			MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1	0x4001b031
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX	0x1b0b1
+			MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX	0x1b0b1
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX6UL_PAD_UART1_RTS_B__GPIO1_IO19	0x17059
+			MX6UL_PAD_SD1_CMD__USDHC1_CMD		0x17059
+			MX6UL_PAD_SD1_CLK__USDHC1_CLK		0x10071
+			MX6UL_PAD_SD1_DATA0__USDHC1_DATA0	0x17059
+			MX6UL_PAD_SD1_DATA1__USDHC1_DATA1	0x17059
+			MX6UL_PAD_SD1_DATA2__USDHC1_DATA2	0x17059
+			MX6UL_PAD_SD1_DATA3__USDHC1_DATA3	0x17059
+		>;
+	};
+
+	pinctrl_usb_otg1_vbus: usb_otg1_vbus {
+		fsl,pins = <
+			MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08	0x79
+		>;
+	};
+};
+
+&fec1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet1>;
+	phy-mode = "rmii";
+	phy-handle = <&ethphy0>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy0: ethernet-phy at 0 {
+			reg = <0>;
+		};
+	};
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&usbotg1 {
+	vbus-supply = <&reg_usb_otg1_vbus>;
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+	no-1-8-v;
+	keep-power-in-suspend;
+	wakeup-source;
+	status = "okay";
+};
-- 
2.10.0

^ permalink raw reply related

* [PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution
From: Bartosz Golaszewski @ 2016-09-30  9:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160929185805.q2pdihajikgzo4lm@gobelin>

2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> Hi,
>
> On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
>> Add svga timings for 1024x768 resolution to the da850-lcdk
>> device tree.
>>
>

[snip]

>
> Why do you also call 1024x768 svga ?
>

Thanks, should have been xga. will fix in v2.

> I don't think the LCDK can cope with this resolution at this frequency
> (in terms of mem bandwidth), at least that's what I observed back in
> August. If confirmed I think it is worth mentioning in the log at least,
> but then I doubt adding this config would be useful.
>

Thanks for the heads up. How would that manifest itself? This seems to
work fine for me - I'm not getting any warnings on a simple system -
maybe if I added some additional memory load it would complain.

Thanks,
Bartosz

^ permalink raw reply

* [PATCH 6/6] ARM: da850: adjust memory settings for tilcdc
From: Karl Beldan @ 2016-09-30  9:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMpxmJVQwQPa6FK+UGe1f7n5LdWUQyN9g+hO3OHB7PFqWrNY=w@mail.gmail.com>

On Fri, Sep 30, 2016 at 9:31 AM, Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> 2016-09-29 21:07 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
>> Hi,
>>
>> On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote:
>>> Default memory settings of da850 do not meet the throughput/latency
>>> requirements of tilcdc. This results in the image displayed being
>>> incorrect and the following warning being displayed by the LCDC
>>> drm driver:
>>>
>>>   tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>>>
>>> Reconfigure the LCDC priority to the highest. This is a workaround
>>> for the da850-lcdk board which has the LCD controller enabled in
>>> the device tree, but a long-term, system-wide fix is needed for
>>> all davinci boards.
>>>
>>> This patch has been modified for mainline linux. It comes from a
>>> downstream TI release for da850[1].
>>>
>>> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>>>
>>> [1] http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=commitdiff;h=b9bd39a34cc02c3ba2fc15539a2f0bc2b68d25da;hp=6f6c795faa6366a4ebc1037a0235edba6018a991
>>>
>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>> ---
>>
>> FWIW, the quirks could be applied conditionnally depending on the lcdc
>> node presence in the DT, a bit like:
>> https://github.com/kbeldan/linux/commit/cf15572ffef8e8a0d8110b3f6b29bd401d0538be
>> https://github.com/kbeldan/linux/commit/07e4fff9958bc1625a96791dce284c163fbe9c43
>>
>>
>> Regards,
>> Karl
>
> Hi Karl,
>
> I decided to post the simplest possible way of this to get the lcdc
> working upstream. In parallel I'm working on a system-wide way of
> applying such quirks not only limited to device tree nodes' presence.

Ok, that'd be a good thing, apparently people have been looking
to do such a thing for the am335x as well.

Regards,
Karl

> Thanks for the info!
>
> Best regards,
> Bartosz Golaszewski

^ permalink raw reply

* [PATCH v4 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
From: Hillf Danton @ 2016-09-30  9:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475227569-63446-2-git-send-email-xieyisheng1@huawei.com>

On Friday, September 30, 2016 5:26 PM Yisheng Xie
> 
> Avoid making ifdef get pretty unwieldy if many ARCHs support gigantic page.
> No functional change with this patch.
> 
> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
> Suggested-by: Michal Hocko <mhocko@suse.com>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> ---
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>

^ permalink raw reply

* [PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller
From: Bartosz Golaszewski @ 2016-09-30  9:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160929184001.yooxkwulqgioak6a@gobelin>

2016-09-29 20:40 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> Hi,
>
> On Thu, Sep 29, 2016 at 06:31:52PM +0200, Bartosz Golaszewski wrote:
>> From: Karl Beldan <kbeldan@baylibre.com>
>>
>> This adds the pins used by the LCD controller, and uses 'tilcdc,panel'
>> with some default timings for 800x600.
>>
>> Tested on an LCDK connected on the VGA port (the LCDC is connected to
>> this port via a THS8135).
>>
>> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
>> [Bartosz:
>>   - fixed whitespace errors
>>   - tweaked the description
>
> The description tweak you mention is the removal of an erratum which is
> in the mentioned commit I put on github @
> (https://github.com/kbeldan/linux/commit/b7720bc983c00a083dece119f68ea9d2f522c6c4)
> it included an erratum wrt FIFO threshold I think is worth keeping:
> {
> There is an erratum (fifo-th) "LCDC: Underflow During Initialization":
> [...]
> "This problem may occur if the LCDC FIFO threshold size (
> LCDDMA_CTRL[TH_FIFO_READY]) is left at its default value after reset.
> Increasing the FIFO threshold size will reduce or eliminate underflows.
> Setting the threshold size to 256 double words or larger is
> recommended."
> }

Isn't this the issue that is fixed by changing the memory priority for lcdc?

>
>>   - fixed the incorrect hback-porch value
>
> It can't be a fix, this value depends on the monitor connected.
>

Thanks, I'm new to drm. From reading the datasheet it seemed to me
that this depends on the resolution. FWIW it seems that most LCDs are
able to adjust to this themselves - I tested with two different
displays and the value I introduced worked on both while the previous
one shifted the image to the right. I'll look into that.

>>   - other minor tweaks]
>
> I didn't see any other change while diffing.
>

Dropped the refresh rate from the timings node name.

Thanks,
Bartosz

^ permalink raw reply

* [PATCH v4 2/2] arm64 Kconfig: Select gigantic page
From: Hillf Danton @ 2016-09-30  9:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475227569-63446-3-git-send-email-xieyisheng1@huawei.com>

On Friday, September 30, 2016 5:26 PM Yisheng Xie wrote
> 
> Arm64 supports gigantic page after
> commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
> however, it can only be allocated at boottime and can't be freed.
> 
> This patch selects ARCH_HAS_GIGANTIC_PAGE to make gigantic pages
> can be allocated and freed at runtime for arch arm64.
> 
> Acked-by: Michal Hocko <mhocko@suse.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
> ---
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com> 

^ permalink raw reply

* [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
From: Horng-Shyang Liao @ 2016-09-30  9:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475226691.13398.35.camel@mtksdaap41>

On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
> Hi, HS:
> 
> One comment inline
> 
> On Fri, 2016-09-30 at 16:56 +0800, Horng-Shyang Liao wrote:
> > Hi CK,
> > 
> > Please see my inline reply.
> > 
> > On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> > > Hi, HS:
> > > 
> > > On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > > > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > > > CMDQ is used to help write registers with critical time limitation,
> > > > such as updating display configuration during the vblank. It controls
> > > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > > Currently, CMDQ only supports display related hardwares, but we expect
> > > > it can be extended to other hardwares for future requirements.
> > > > 
> > > > Signed-off-by: HS Liao <hs.liao@mediatek.com>
> > > > Signed-off-by: CK Hu <ck.hu@mediatek.com>
> > > > ---
> > > 
> > > [snip...]
> > > 
> > > > +
> > > > +struct cmdq_task {
> > > > +	struct cmdq		*cmdq;
> > > > +	struct list_head	list_entry;
> > > > +	void			*va_base;
> > > > +	dma_addr_t		pa_base;
> > > > +	size_t			cmd_buf_size; /* command occupied size */
> > > > +	size_t			buf_size; /* real buffer size */
> > > > +	bool			finalized;
> > > > +	struct cmdq_thread	*thread;
> > > 
> > > I think thread info could be removed from cmdq_task. Only
> > > cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> > > task->thread and caller of both function has the thread info. So you
> > > could just pass thread info into these two function and remove thread
> > > info in cmdq_task.
> > 
> > This modification will remove 1 pointer but add 2 pointers. Moreover,
> > more pointers will need to be delivered between functions for future
> > extension. IMHO, it would be better to keep thread pointer inside
> > cmdq_task.
> > 
> > > > +	struct cmdq_task_cb	cb;
> > > 
> > > I think this callback function is equal to mailbox client tx_done
> > > callback. It's better to use already-defined interface rather than
> > > creating your own.
> > 
> > This is because CMDQ driver allows different callback functions for
> > different tasks, but mailbox only allows one callback function per
> > channel. But, I think I can add a wrapper for tx_done to call CMDQ
> > callback functions. So, I will use tx_done in CMDQ v15.
> 
> Up to now, one callback function for one channel is enough for DRM. So
> 'different callback function for different sent-message' looks like an
> advanced function. Maybe you should not include it in first patch. 
> 
> Regards,
> CK

Hi CK,

OK. I will do it.

Thanks,
HS

[snip...]

^ permalink raw reply

* [PATCH v3 1/9] mtd:fsl-quadspi:use the property fields of SPI-NOR
From: Cyrille Pitchen @ 2016-09-30 10:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1471505884-33996-1-git-send-email-B56489@freescale.com>

Hi Yunhui,

Indeed it's a really good thing to update the Freescale QSPI controller driver
so it relies more on the settings chosen in spi-nor.c: it avoids duplicating
the code. spi-nor.c is supposed to select all the instruction codes and memory
settings according to both the (Q)SPI memory and the controller capabilities.
The controller driver should only be responsible for sending the SPI commands
but should neither modify those commands nor be aware of the actual memory
connected to it.

So the idea of this patch is great :)

Best regards,

Cyrille

Le 18/08/2016 ? 09:37, Yunhui Cui a ?crit :
> We can get the read/write/erase opcode from the spi nor framework
> directly. This patch uses the information stored in the SPI-NOR to
> remove the hardcode in the fsl_qspi_init_lut().
> 
> Signed-off-by: Yunhui Cui <B56489@freescale.com>
> Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
Reviewed-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> ---
>  drivers/mtd/spi-nor/fsl-quadspi.c | 40 ++++++++++++---------------------------
>  1 file changed, 12 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 5c82e4e..5ad6402 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -373,9 +373,13 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
>  	void __iomem *base = q->iobase;
>  	int rxfifo = q->devtype_data->rxfifo;
>  	u32 lut_base;
> -	u8 cmd, addrlen, dummy;
>  	int i;
>  
> +	struct spi_nor *nor = &q->nor[0];
> +	u8 addrlen = (nor->addr_width == 3) ? ADDR24BIT : ADDR32BIT;
> +	u8 read_op = nor->read_opcode;
> +	u8 read_dm = nor->read_dummy;
> +
>  	fsl_qspi_unlock_lut(q);
>  
>  	/* Clear all the LUT table */
> @@ -385,20 +389,10 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
>  	/* Quad Read */
>  	lut_base = SEQID_QUAD_READ * 4;
>  
> -	if (q->nor_size <= SZ_16M) {
> -		cmd = SPINOR_OP_READ_1_1_4;
> -		addrlen = ADDR24BIT;
> -		dummy = 8;
> -	} else {
> -		/* use the 4-byte address */
> -		cmd = SPINOR_OP_READ_1_1_4;
> -		addrlen = ADDR32BIT;
> -		dummy = 8;
> -	}
> -
> -	qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
> +	qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
>  			base + QUADSPI_LUT(lut_base));
> -	qspi_writel(q, LUT0(DUMMY, PAD1, dummy) | LUT1(FSL_READ, PAD4, rxfifo),
> +	qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
> +		    LUT1(FSL_READ, PAD4, rxfifo),
>  			base + QUADSPI_LUT(lut_base + 1));
>  
>  	/* Write enable */
> @@ -409,16 +403,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
>  	/* Page Program */
>  	lut_base = SEQID_PP * 4;
>  
> -	if (q->nor_size <= SZ_16M) {
> -		cmd = SPINOR_OP_PP;
> -		addrlen = ADDR24BIT;
> -	} else {
> -		/* use the 4-byte address */
> -		cmd = SPINOR_OP_PP;
> -		addrlen = ADDR32BIT;
> -	}
> -
> -	qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
> +	qspi_writel(q, LUT0(CMD, PAD1, nor->program_opcode) |
> +		    LUT1(ADDR, PAD1, addrlen),
>  			base + QUADSPI_LUT(lut_base));
>  	qspi_writel(q, LUT0(FSL_WRITE, PAD1, 0),
>  			base + QUADSPI_LUT(lut_base + 1));
> @@ -432,10 +418,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
>  	/* Erase a sector */
>  	lut_base = SEQID_SE * 4;
>  
> -	cmd = q->nor[0].erase_opcode;
> -	addrlen = q->nor_size <= SZ_16M ? ADDR24BIT : ADDR32BIT;
> -
> -	qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
> +	qspi_writel(q, LUT0(CMD, PAD1, nor->erase_opcode) |
> +		    LUT1(ADDR, PAD1, addrlen),
>  			base + QUADSPI_LUT(lut_base));
>  
>  	/* Erase the whole chip */
> 

^ permalink raw reply

* [PATCH] arm64: add support for SHA256 using NEON instructions
From: Andy Polyakov @ 2016-09-30 10:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475189503-9175-1-git-send-email-ard.biesheuvel@linaro.org>

> This is a port of the ARMv7 implementation in arch/arm/crypto. For a Cortex-A57
> (r2p1), the performance numbers are listed below. In summary, 40% - 50% speedup
> where it counts, i.e., block sizes over 256 bytes with few updates.

Cool! Great! Just in case for reference. You compare generic, new NEON
and hardware-assisted implementations. I assume that first one refers to
C compiler-generated code. But there is another option, i.e. non-NEON
assembly. Now to the "for reference" part. The reason for why NEON is
not utilized in OpenSSL is because it's deemed that it doesn't provide
"extraordinary" improvement over non-NEON assembly code, especially on
less sophisticated processors such as Cortex-A53. Note that I'm not
saying that NEON SHA256 subroutine is not faster, it is, only that it's
not "extraordinarily" faster in most relevant cases(*). In other words
it's reckoned that non-NEON assembly provides adequate *all-round*
performance, taking into consideration that it does it without being
dependent on optional NEON. Non-NEON assembly should also be interesting
in kernel context, because there are situations when you can't call NEON
procedure, be it suggested one or hardware-assisted, which itself relies
on NEON. And of course another nice quality about SHA2 module in OpenSSL
is that it emits both SHA256 and SHA512 codes ;-) On related note it
should be noted that NEON-izing SHA512 on ARM64 makes lesser sense, it's
bound to provide lesser improvement than SHA256 [if any at all in some
cases]. This is because in SHA256 you engage 4 lanes of NEON registers,
while in SHA512 case you have only 2.

(*) Well, this is also question of priorities. My rationale is that
there is a lot of Cortex-A53 and A57 phones out there that don't have
crypto-extensions, I refer to Qualcomm SoCs, where NEON gives less than
10% improvement [over non-NEON assembly]. Yes, it gives more on X-Gene,
but X-Gene is not wide-spread, and the rest (including upcoming X-Gene)
have crypto-extensions, so alternative code path doesn't matter.

^ permalink raw reply

* [PATCHv4 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Richard Genoud @ 2016-09-30 11:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160930091230.qzd42qnelylmkqxe@pengutronix.de>

2016-09-30 11:12 GMT+02:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hello Richard,
>
> On Fri, Sep 30, 2016 at 10:58:00AM +0200, Richard Genoud wrote:
>> Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
>> hardware handshake is enabled") broke the hardware handshake when GPIOs
>> were used.
>>
>> Hardware handshake with GPIOs used to work before this commit because
>> the CRTSCTS flag (termios->c_cflag) was set, but not the
>> ATMEL_US_USMODE_HWHS flag (controller register) ; so hardware handshake
>> enabled, but not handled by the controller.
>
> What does the HWHS flag control? What if only RTS is a gpio and CTS is
> not? Or the other way round?
First, HWHS flag is used only in SAMA5D2. (if I correctly understood
Atmel HW guys,
all other platforms (sam9, sam9x5, sama5d3...) have this flag, but it
is unusable,
because they don't have Fifos nor PDC).
So, on SAMA5D2, the HWHS flag tells the controller to drive the RTS
pin according to
the number of char present in the rx fifo (cf Figure 44-29 ?44.7.3.15 p.1438 of
 http://www.atmel.com/Images/Atmel-11267-32-bit-Cortex-A5-Microcontroller-SAMA5D2_Datasheet.pdf).
The controller will also start/stop the transmission on CTS changes.
But, as I haven't got this hard, I couldn't test it. (but Cyrille did I guess).
With this flag set, It's mandatory to have CTS and RTS not handled via
GPIO, because if
they were, the controller couldn't, well, control them.

The NORMAL flag, on the contrary, just tell the controller not to mess
with RTS/CTS,
and in this case, the driver will handle CTS changes and drive the RTS
pin, via GPIO or
via the CR register.

It's not a problem to have CTS as a GPIO and RTS controlled via the CR register
(or CTS changes read in CSR register and RTS as a GPIO).
I just gave it a quick try, works the same.
( But I don't know if it will work with FIFOs

> What is the problematic setup? I guess it's RTS and CTS are gpios and
> with that setting ATMEL_US_USMODE_HWHS is wrong? What happens if that
> happens?

Yes, CTS/RTS as GPIOs + HWHS flag is clearly wrong.
If that happens, well, the controller will try to drive an RTS pin
that won't have been muxed
as RTS. It does not seems to be a problem, but instructing the
controller do drive pins it doesn't
have access doesn't really make sense.
And in the case of the SAMA5D2, well I don't know what the result will
be, but it could stop transmission
from the "ghost" CTS signal I guess.

Anyway, the problematics setups are all the setups with USMODE_HWHS
enabled on platform without Fifos or PDC,
i.e. all platforms but sama5d2 (Cyrille, correct me if I'm wrong).

For instance, on sam9x5, if DMA is used, USMODE_HWHS enabled and
RTS/CTS NOT muxed as GPIOS,
it's like there was no flow control at all (the CTS pin doesn't
disable the transmitter).

Since atmel HW guys said that USMODE_HWHS is broken for platforms !sama5d2,
(cfhttps://lkml.org/lkml/2016/9/7/598 ),  I honestly didn't dig any
further into that flag.


Regards,
Richard

^ permalink raw reply

* [PATCHv4 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Alexandre Belloni @ 2016-09-30 11:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACQ1gAgE+BvteH9y62PcRx_tA9_e2X11RCJ12PC98FK+5z98QQ@mail.gmail.com>

On 30/09/2016 at 13:04:28 +0200, Richard Genoud wrote :
> Anyway, the problematics setups are all the setups with USMODE_HWHS
> enabled on platform without Fifos or PDC,
> i.e. all platforms but sama5d2 (Cyrille, correct me if I'm wrong).
> 

This is a wrong assumption, at91rm9200 to at91sam9g45 all have a pdc.
Please, don't break those platforms.

The only affected platforms are sam9x5, sama5d3 and sama5d4.

> For instance, on sam9x5, if DMA is used, USMODE_HWHS enabled and
> RTS/CTS NOT muxed as GPIOS,
> it's like there was no flow control at all (the CTS pin doesn't
> disable the transmitter).
> 
> Since atmel HW guys said that USMODE_HWHS is broken for platforms !sama5d2,
> (cfhttps://lkml.org/lkml/2016/9/7/598 ),  I honestly didn't dig any
> further into that flag.
> 
> 
> Regards,
> Richard

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

^ permalink raw reply

* [PATCH v2 1/1] arm64: Add DTS support for FSL's LS1012A SoC
From: Bhaskar U @ 2016-09-30 11:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160829095239.GM30790@tiger>



>-----Original Message-----
>From: Shawn Guo [mailto:shawnguo at kernel.org]
>Sent: Monday, August 29, 2016 3:23 PM
>To: Bhaskar U <bhaskar.upadhaya@nxp.com>
>Cc: devicetree at vger.kernel.org; Stuart Yoder <stuart.yoder@nxp.com>;
>oss at buserror.net; Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
>devel at gforge.freescale.net; Pratiyush Srivastava
><pratiyush.srivastava@nxp.com>; linux-arm-kernel at lists.infradead.org
>Subject: Re: [PATCH v2 1/1] arm64: Add DTS support for FSL's LS1012A SoC
>
>On Fri, Aug 26, 2016 at 03:57:21PM +0530, Bhaskar Upadhaya wrote:
>> Add the device tree support for FSL LS1012A SoC.
>> Following levels of DTSI/DTS files have been created for the LS1012A
>> SoC family:
>>
>>         - fsl-ls1012a.dtsi:
>>                 DTS-Include file for FSL LS1012A SoC.
>>
>>         - fsl-ls1012a-frdm.dts:
>>                 DTS file for FSL LS1012A FRDM board.
>>
>>         - fsl-ls1012a-qds.dts:
>>                 DTS file for FSL LS1012A QDS board.
>>
>>         - fsl-ls1012a-rdb.dts:
>>                 DTS file for FSL LS1012A RDB board.
>>
>> Changes vs version1:
>> 	- Consistent Licensing for dts files
>> 	- Removed the PFE node
>> 	- Update reset node with reboot node
>> 	- Update clocks property in codec node
>> 	- Update regulators node
>> 	- Update timer node
>> 	- Update compatible property of clockgen with "fsl,ls1012a-clockgen"
>only
>> 	- Update compatible property of scfg with "fsl,ls1012a-scfg" only
>> 	- Update compatible property with proper ordering in tmu node
>>
>> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
>> Signed-off-by: Pratiyush Mohan Srivastava
>> <pratiyush.srivastava@nxp.com>
>> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
>> ---
>>  arch/arm64/boot/dts/freescale/Makefile             |   3 +
>>  arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts | 150 +++++++
>> arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts  | 180 ++++++++
>> arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts  |  79 ++++
>>  arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi     | 480
>+++++++++++++++++++++
>>  5 files changed, 892 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
>>  create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
>>  create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
>>  create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/freescale/Makefile
>> b/arch/arm64/boot/dts/freescale/Makefile
>> index 1b7783d..3503c46 100644
>> --- a/arch/arm64/boot/dts/freescale/Makefile
>> +++ b/arch/arm64/boot/dts/freescale/Makefile
>> @@ -1,3 +1,6 @@
>> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-qds.dtb
>> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-rdb.dtb
>> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frdm.dtb
>
>Please try to keep the list sort alphabetically.

Ok will make the sequence like below
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frdm.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-rdb.dtb

>
>>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-qds.dtb
>>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-rdb.dtb
>>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb diff --git
>> a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
>> b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
>> new file mode 100644
>> index 0000000..dc6df47
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
>> @@ -0,0 +1,150 @@
>> +/*
>> + * Device Tree file for Freescale Layerscape-1012A family SoC.
>> + *
>> + * Copyright 2016, Freescale Semiconductor
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPLv2 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 "fsl-ls1012a.dtsi"
>> +
>> +/ {
>> +	model = "LS1012A Freedom Board";
>> +	compatible = "fsl,ls1012a-frdm", "fsl,ls1012a";
>> +
>> +	aliases {
>> +		crypto = &crypto;
>> +	};
>> +
>> +	sys_mclk: clock-mclk {
>> +		compatible = "fixed-clock";
>> +		#clock-cells = <0>;
>> +		clock-frequency = <25000000>;
>> +	};
>> +
>> +	sound {
>> +		compatible = "simple-audio-card";
>> +		simple-audio-card,format = "i2s";
>> +		simple-audio-card,widgets =
>> +			"Microphone", "Microphone Jack",
>> +			"Headphone", "Headphone Jack",
>> +			"Speaker", "Speaker Ext",
>> +			"Line", "Line In Jack";
>> +		simple-audio-card,routing =
>> +			"MIC_IN", "Microphone Jack",
>> +			"Microphone Jack", "Mic Bias",
>> +			"LINE_IN", "Line In Jack",
>> +			"Headphone Jack", "HP_OUT",
>> +			"Speaker Ext", "LINE_OUT";
>> +
>> +		simple-audio-card,cpu {
>> +			sound-dai = <&sai2>;
>> +			frame-master;
>> +			bitclock-master;
>> +		};
>> +
>> +		simple-audio-card,codec {
>> +			sound-dai = <&codec>;
>> +			frame-master;
>> +			bitclock-master;
>> +			system-clock-frequency = <25000000>;
>> +		};
>> +	};
>> +};
>> +
>> +&qspi {
>> +	num-cs = <2>;
>> +	bus-num = <0>;
>> +	status = "disabled";
>
>Why is it being disabled?

Ok, will change like below.
status = "okay";

>
>> +	fsl,ddr-sampling-point = <4>;
>
>I do not find the bindings for this property, neither how driver supports it.

Yes the QSPI DDR mode is not yet up-streamed, so  I will remove this property as of now.

>
>> +
>> +	qflash0: s25fs512s at 0 {
>> +		compatible = "spansion,m25p80";
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		spi-max-frequency = <20000000>;
>> +		m25p,fast-read;
>> +		reg = <0>;
>> +	};
>> +};
>> +
>> +&i2c0 {
>> +	status = "okay";
>> +
>> +	codec: sgtl5000 at a {
>> +		#sound-dai-cells = <0>;
>> +		compatible = "fsl,sgtl5000";
>> +		reg = <0xa>;
>> +		VDDA-supply = <&reg_1p8v>;
>> +		VDDIO-supply = <&reg_1p8v>;
>> +		clocks = <&sys_mclk>;
>> +	};
>> +};
>> +
>> +&duart0 {
>> +	status = "okay";
>> +};
>> +
>> +&esdhc0 {
>> +	status = "disabled";
>
>We prefer to disable devices which have board level options by default in
><soc>.dtsi, and enable them per availability in <board>.dts.

Ok , will make the status as okay i.e. status = "okay";

>
>> +};
>> +
>> +&esdhc1 {
>> +	status = "disabled";
>> +};
>> +
>> +&sai2 {
>> +	status = "disabled";
>> +};
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
>> b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
>> new file mode 100644
>> index 0000000..382d070
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
>> @@ -0,0 +1,180 @@
>> +/*
>> + * Device Tree file for Freescale Layerscape-1012A family SoC.
>> + *
>> + * Copyright 2016, Freescale Semiconductor
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPLv2 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 "fsl-ls1012a.dtsi"
>> +
>> +/ {
>> +	model = "LS1012A QDS Board";
>> +	compatible = "fsl,ls1012a-qds", "fsl,ls1012a";
>> +
>> +	aliases {
>> +		crypto = &crypto;
>> +	};
>> +
>> +	sys_mclk: clock-mclk {
>> +		compatible = "fixed-clock";
>> +		#clock-cells = <0>;
>> +		clock-frequency = <24576000>;
>> +	};
>> +
>> +	regulators {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		reg_3p3v: regulator at 0 {
>> +			compatible = "regulator-fixed";
>> +			reg = <0x0>;
>> +			regulator-name = "3P3V";
>> +			regulator-min-microvolt = <3300000>;
>> +			regulator-max-microvolt = <3300000>;
>> +			regulator-always-on;
>> +		};
>> +	};
>> +
>> +	sound {
>> +		compatible = "simple-audio-card";
>> +		simple-audio-card,format = "i2s";
>> +		simple-audio-card,widgets =
>> +			"Microphone", "Microphone Jack",
>> +			"Headphone", "Headphone Jack",
>> +			"Speaker", "Speaker Ext",
>> +			"Line", "Line In Jack";
>> +		simple-audio-card,routing =
>> +			"MIC_IN", "Microphone Jack",
>> +			"Microphone Jack", "Mic Bias",
>> +			"LINE_IN", "Line In Jack",
>> +			"Headphone Jack", "HP_OUT",
>> +			"Speaker Ext", "LINE_OUT";
>> +
>> +		simple-audio-card,cpu {
>> +			sound-dai = <&sai2>;
>> +			frame-master;
>> +			bitclock-master;
>> +		};
>> +
>> +		simple-audio-card,codec {
>> +			sound-dai = <&codec>;
>> +			frame-master;
>> +			bitclock-master;
>> +			system-clock-frequency = <24576000>;
>> +		};
>> +	};
>> +};
>> +
>> +&dspi0 {
>> +	bus-num = <0>;
>> +	status = "okay";
>> +
>> +	flash at 0 {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		compatible = "n25q128a11", "jedec,spi-nor";  /* 16MB */
>> +		reg = <0>;
>> +		spi-max-frequency = <10000000>; /* input clock */
>> +	};
>> +
>> +	flash at 1 {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		compatible = "sst,sst25wf040b", "jedec,spi-nor";  /* 512KB */
>> +		reg = <1>;
>> +		spi-max-frequency = <35000000>; /* input clock */
>> +	};
>> +
>> +	flash at 2 {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		compatible = "eon,en25s64", "jedec,spi-nor";   /* 8MB */
>> +		reg = <2>;
>> +		spi-max-frequency = <35000000>; /* input clock */
>> +	};
>> +};
>> +
>> +&qspi {
>> +	num-cs = <2>;
>> +	bus-num = <0>;
>> +	status = "disabled";
>> +
>> +	qflash0: s25fs512s at 0 {
>> +		compatible = "spansion,m25p80";
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		spi-max-frequency = <20000000>;
>> +		m25p,fast-read;
>> +		reg = <0>;
>> +	};
>> +};
>> +
>> +&i2c0 {
>> +	status = "okay";
>
>Please have a newline between property list and sub-node.

OK

>
>> +	pca9547 at 77 {
>> +		compatible = "nxp,pca9547";
>> +		reg = <0x77>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		i2c at 4 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <0x4>;
>> +
>> +			codec: sgtl5000 at a {
>> +				#sound-dai-cells = <0>;
>> +				compatible = "fsl,sgtl5000";
>> +				reg = <0xa>;
>> +				VDDA-supply = <&reg_3p3v>;
>> +				VDDIO-supply = <&reg_3p3v>;
>> +				clocks = <&sys_mclk>;
>> +			};
>> +		};
>> +	};
>> +};
>> +
>> +&duart0 {
>> +	status = "okay";
>> +};
>> +
>> +&sai2 {
>> +	status = "disabled";
>> +};
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
>> b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
>> new file mode 100644
>> index 0000000..b609032
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
>> @@ -0,0 +1,79 @@
>> +/*
>> + * Device Tree file for Freescale Layerscape-1012A family SoC.
>> + *
>> + * Copyright 2016, Freescale Semiconductor
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPLv2 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 "fsl-ls1012a.dtsi"
>> +
>> +/ {
>> +	model = "LS1012A RDB Board";
>> +	compatible = "fsl,ls1012a-rdb", "fsl,ls1012a";
>> +
>> +	aliases {
>> +		crypto = &crypto;
>> +	};
>> +};
>> +
>> +&qspi {
>> +	num-cs = <2>;
>> +	bus-num = <0>;
>> +	status = "disabled";
>> +	fsl,ddr-sampling-point = <4>;
>> +
>> +	qflash0: s25fs512s at 0 {
>> +		compatible = "spansion,m25p80";
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		spi-max-frequency = <20000000>;
>> +		m25p,fast-read;
>> +		reg = <0>;
>> +	};
>> +};
>> +
>> +&i2c0 {
>> +	status = "okay";
>> +};
>> +
>> +&duart0 {
>> +	status = "okay";
>> +};
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>> b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>> new file mode 100644
>> index 0000000..80fe028
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>> @@ -0,0 +1,480 @@
>> +/*
>> + * Device Tree Include file for Freescale Layerscape-1012A family SoC.
>> + *
>> + * Copyright 2016, Freescale Semiconductor
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPLv2 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.
>> + */
>> +
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +/ {
>> +	compatible = "fsl,ls1012a";
>> +	interrupt-parent = <&gic>;
>> +	#address-cells = <2>;
>> +	#size-cells = <2>;
>> +
>> +	cpus {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		cpu0: cpu at 0 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a53";
>> +			reg = <0x0 0x0>;
>
>This doesn't match the #address-cells property of 'cpus' node.


Ok will make as reg = <0x0>;

>
>> +			clocks = <&clockgen 1 0>;
>> +			#cooling-cells = <2>;
>> +		};
>> +	};
>> +
>> +	sysclk: sysclk {
>> +		compatible = "fixed-clock";
>> +		#clock-cells = <0>;
>> +		clock-frequency = <100000000>;
>> +		clock-output-names = "sysclk";
>> +	};
>> +
>> +	timer {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts = <1 13 0x1>, /* Physical Secure PPI */
>> +			     <1 14 0x1>, /* Physical Non-Secure PPI */
>> +			     <1 11 0x1>, /* Virtual PPI */
>> +			     <1 10 0x1>; /* Hypervisor PPI */
>
>Can we use the constant defined in
>dt-bindings/interrupt-controller/irq.h to make them a bit more readable?

OK, will include the #include <dt-bindings/interrupt-controller/irq.h> in fsl-ls1012a.dtsi and edit the interrupts like below
	interrupts = <1 13 IRQ_TYPE_EDGE_RISING>, /* Physical Secure PPI */
	               <1 14 IRQ_TYPE_EDGE_RISING>, /* Physical Non-Secure PPI */
                             <1 11 IRQ_TYPE_EDGE_RISING>, /* Virtual PPI */
                             <1 10 IRQ_TYPE_EDGE_RISING>; /* Hypervisor PPI */
>
>> +	};
>> +
>> +	pmu {
>> +		compatible = "arm,armv8-pmuv3";
>> +		interrupts = <0 106 0x4>;
>> +	};
>> +
>> +	gic: interrupt-controller at 1400000 {
>> +		compatible = "arm,gic-400";
>> +		#interrupt-cells = <3>;
>> +		interrupt-controller;
>> +		reg = <0x0 0x1401000 0 0x1000>, /* GICD */
>> +		      <0x0 0x1402000 0 0x2000>, /* GICC */
>> +		      <0x0 0x1404000 0 0x2000>, /* GICH */
>> +		      <0x0 0x1406000 0 0x2000>; /* GICV */
>> +		interrupts = <1 9 0xf08>;
>> +	};
>> +
>> +	soc {
>> +		compatible = "simple-bus";
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
>> +
>> +		clockgen: clocking at 1ee1000 {
>> +			compatible = "fsl,ls1012a-clockgen";
>
>The compatible cannot be found in binding docs.

Still not clear whether we need to  add "compatible = "fsl,ls1012a-clockgen";" in Documentation/devicetree/bindings/clock/qoriq-clock.txt as there are contradictory thoughts that whether we need to add each compatible string in the bindings or not ?

>
>> +			reg = <0x0 0x1ee1000 0x0 0x1000>;
>> +			#clock-cells = <2>;
>> +			clocks = <&sysclk>;
>> +		};
>> +
>> +		scfg: scfg at 1570000 {
>> +			compatible = "fsl,ls1012a-scfg", "syscon";
>
>Ditto

Same clarification needed that whether we need to add each compatible string in the bindings or not ?
If we need to add I will  add [compatible = "fsl,ls1012a-scfg", "syscon";] in Documentation/devicetree/bindings/arm/fsl.txt

>
>> +			reg = <0x0 0x1570000 0x0 0x10000>;
>> +			big-endian;
>> +		};
>> +
>> +		dcfg: dcfg at 1ee0000 {
>> +			compatible = "fsl,ls1012a-dcfg",
>> +				     "fsl,ls1043a-dcfg",
>
>If these compatibles are not documented or used, we can drop them?  I guess we
>only need "syscon" to get it work?

 
Will remove "fsl,ls1043a-dcfg" from here.

>
>> +				     "syscon";
>> +			reg = <0x0 0x1ee0000 0x0 0x10000>;
>> +			big-endian;
>> +		};
>> +
>> +		crypto: crypto at 1700000 {
>> +			compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
>> +				     "fsl,sec-v4.0";
>> +			fsl,sec-era = <8>;
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			ranges = <0x0 0x00 0x1700000 0x100000>;
>> +			reg = <0x00 0x1700000 0x0 0x100000>;
>> +			interrupts = <0 75 0x4>;
>> +
>> +			sec_jr0: jr at 10000 {
>> +				compatible = "fsl,sec-v5.4-job-ring",
>> +					     "fsl,sec-v5.0-job-ring",
>> +					     "fsl,sec-v4.0-job-ring";
>> +				reg	   = <0x10000 0x10000>;
>> +				interrupts = <0 71 0x4>;
>> +			};
>> +
>> +			sec_jr1: jr at 20000 {
>> +				compatible = "fsl,sec-v5.4-job-ring",
>> +					     "fsl,sec-v5.0-job-ring",
>> +					     "fsl,sec-v4.0-job-ring";
>> +				reg	   = <0x20000 0x10000>;
>> +				interrupts = <0 72 0x4>;
>> +			};
>> +
>> +			sec_jr2: jr at 30000 {
>> +				compatible = "fsl,sec-v5.4-job-ring",
>> +					     "fsl,sec-v5.0-job-ring",
>> +					     "fsl,sec-v4.0-job-ring";
>> +				reg	   = <0x30000 0x10000>;
>> +				interrupts = <0 73 0x4>;
>> +			};
>> +
>> +			sec_jr3: jr at 40000 {
>> +				compatible = "fsl,sec-v5.4-job-ring",
>> +					     "fsl,sec-v5.0-job-ring",
>> +					     "fsl,sec-v4.0-job-ring";
>> +				reg	   = <0x40000 0x10000>;
>> +				interrupts = <0 74 0x4>;
>> +			};
>> +		};
>> +
>> +		reboot {
>> +			compatible ="syscon-reboot";
>> +			regmap = <&dcfg>;
>> +			offset = <0xb0>;
>> +			mask = <0x02>;
>> +		};
>
>It might make more sense to put it directly under root like what fsl-ls1043a.dtsi
>does.

Ok, will follow the way fsl-ls1043a.dtsi does.

>
>> +
>> +		rcpm: rcpm at 1ee2000 {
>> +			compatible = "fsl,ls1012a-rcpm";
>
>Undocumented/unsupported bindings?

That again need confirmation that whether we need to add each compatible string in bindings ?. If we need to add, I will add in 
Documentation/devicetree/bindings/soc/fsl/rcpm.txt

>
>> +			reg = <0x0 0x1ee2000 0x0 0x10000>;
>> +		};
>> +
>> +		esdhc0: esdhc at 1560000 {
>> +			compatible = "fsl,ls1012a-esdhc0", "fsl,esdhc";
>> +			reg = <0x0 0x1560000 0x0 0x10000>;
>> +			interrupts = <0 62 0x4>;
>> +			clock-frequency = <0>;
>
>What does a zero of clock-frequency mean?

The u-boot will fix up the clock-frequency property with the correct value. So we can drop this property. 
 
>
>> +			voltage-ranges = <1800 1800 3300 3300>;
>> +			sdhci,auto-cmd12;
>> +			big-endian;
>> +			bus-width = <4>;
>> +		};
>> +
>> +		esdhc1: esdhc at 1580000 {
>> +			compatible = "fsl,ls1012a-esdhc1", "fsl,esdhc";
>> +			reg = <0x0 0x1580000 0x0 0x10000>;
>> +			interrupts = <0 65 0x4>;
>> +			clock-frequency = <0>;
>> +			voltage-ranges = <1800 1800 3300 3300>;
>> +			sdhci,auto-cmd12;
>> +			big-endian;
>> +			bus-width = <4>;
>> +		};
>> +
>> +		dspi0: dspi at 2100000 {
>> +			compatible = "fsl,ls1012a-dspi",
>> +				     "fsl,ls1043a-dspi",
>> +				     "fsl,ls1021a-v1.0-dspi";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <0x0 0x2100000 0x0 0x10000>;
>> +			interrupts = <0 64 0x4>;
>> +			clock-names = "dspi";
>> +			clocks = <&clockgen 4 0>;
>> +			spi-num-chipselects = <5>;
>> +			big-endian;
>> +			status = "enabled";
>> +		};
>> +
>> +		qspi: quadspi at 1550000 {
>> +			compatible =  "fsl,ls1012a-qspi",
>> +				      "fsl,ls1043a-qspi",
>> +				      "fsl,ls1021a-qspi";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <0x0 0x1550000 0x0 0x10000>,
>> +				<0x0 0x40000000 0x0 0x4000000>;
>> +			reg-names = "QuadSPI", "QuadSPI-memory";
>> +			interrupts = <0 99 0x4>;
>> +			clock-names = "qspi_en", "qspi";
>> +			clocks = <&clockgen 4 0>, <&clockgen 4 0>;
>> +			big-endian;
>> +			amba-base = <0x42000000>;
>
>I can not find this property in any bindings doc.

Amba-base is no longer used for QSPI driver in kernel, So I will remove this property.
 
>
>> +		};
>> +
>> +		tmu: tmu at 1f00000 {
>> +			compatible = "fsl,ls1012a-tmu", "fsl,qoriq-tmu";
>> +			reg = <0x0 0x1f00000 0x0 0x10000>;
>> +			interrupts = <0 33 0x4>;
>> +			fsl,tmu-range = <0xb0000 0x9002a 0x6004c 0x30062>;
>> +			fsl,tmu-calibration = <0x00000000 0x00000026
>> +					       0x00000001 0x0000002d
>> +					       0x00000002 0x00000032
>> +					       0x00000003 0x00000039
>> +					       0x00000004 0x0000003f
>> +					       0x00000005 0x00000046
>> +					       0x00000006 0x0000004d
>> +					       0x00000007 0x00000054
>> +					       0x00000008 0x0000005a
>> +					       0x00000009 0x00000061
>> +					       0x0000000a 0x0000006a
>> +					       0x0000000b 0x00000071
>> +
>
>Drop the newline.

Ok

>
>> +					       0x00010000 0x00000025
>> +					       0x00010001 0x0000002c
>> +					       0x00010002 0x00000035
>> +					       0x00010003 0x0000003d
>> +					       0x00010004 0x00000045
>> +					       0x00010005 0x0000004e
>> +					       0x00010006 0x00000057
>> +					       0x00010007 0x00000061
>> +					       0x00010008 0x0000006b
>> +					       0x00010009 0x00000076
>> +
>
>Ditto

OK

>
>> +					       0x00020000 0x00000029
>> +					       0x00020001 0x00000033
>> +					       0x00020002 0x0000003d
>> +					       0x00020003 0x00000049
>> +					       0x00020004 0x00000056
>> +					       0x00020005 0x00000061
>> +					       0x00020006 0x0000006d
>> +
>
>Ditto

OK

>
>> +					       0x00030000 0x00000021
>> +					       0x00030001 0x0000002a
>> +					       0x00030002 0x0000003c
>> +					       0x00030003 0x0000004e>;
>> +			big-endian;
>> +			#thermal-sensor-cells = <1>;
>> +		};
>> +
>> +		thermal-zones {
>> +			cpu_thermal: cpu-thermal {
>> +				polling-delay-passive = <1000>;
>> +				polling-delay = <5000>;
>> +
>
>Ditto


OK

>
>> +				thermal-sensors = <&tmu 0>;
>> +
>> +				trips {
>> +					cpu_alert: cpu-alert {
>> +						temperature = <85000>;
>> +						hysteresis = <2000>;
>> +						type = "passive";
>> +					};
>
>Have a newline between nodes.

OK

>
>> +					cpu_crit: cpu-crit {
>> +						temperature = <95000>;
>> +						hysteresis = <2000>;
>> +						type = "critical";
>> +					};
>> +				};
>> +
>> +				cooling-maps {
>> +					map0 {
>> +						trip = <&cpu_alert>;
>> +						cooling-device =
>> +							<&cpu0
>THERMAL_NO_LIMIT
>> +							THERMAL_NO_LIMIT>;
>> +					};
>> +				};
>> +			};
>> +		};
>> +
>> +		i2c0: i2c at 2180000 {
>> +			compatible = "fsl,vf610-i2c";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <0x0 0x2180000 0x0 0x10000>;
>> +			interrupts = <0 56 0x4>;
>> +			clock-names = "i2c";
>
>This property is not needed.

Ok, will remove this

>
>> +			clocks = <&clockgen 4 0>;
>> +			status = "disabled";
>> +		};
>> +
>> +		i2c1: i2c at 2190000 {
>> +			compatible = "fsl,vf610-i2c";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <0x0 0x2190000 0x0 0x10000>;
>> +			interrupts = <0 57 0x4>;
>> +			clock-names = "i2c";
>
>Ditto

Ok, will remove this

>
>> +			clocks = <&clockgen 4 0>;
>> +			status = "disabled";
>> +		};
>> +
>> +
>> +		duart0: serial at 21c0500 {
>> +			compatible = "fsl,ns16550", "ns16550a";
>> +			reg = <0x00 0x21c0500 0x0 0x100>;
>> +			interrupts = <0 54 0x4>;
>> +			clocks = <&clockgen 4 0>;
>> +		};
>> +
>> +		duart1: serial at 21c0600 {
>> +			compatible = "fsl,ns16550", "ns16550a";
>> +			reg = <0x00 0x21c0600 0x0 0x100>;
>> +			interrupts = <0 54 0x4>;
>> +			clocks = <&clockgen 4 0>;
>> +		};
>> +
>> +		gpio0: gpio at 2300000 {
>> +			compatible = "fsl,qoriq-gpio";
>> +			reg = <0x0 0x2300000 0x0 0x10000>;
>> +			interrupts = <0 66 0x4>;
>> +			gpio-controller;
>> +			#gpio-cells = <2>;
>> +			interrupt-controller;
>> +			#interrupt-cells = <2>;
>> +		};
>> +
>> +		gpio1: gpio at 2310000 {
>> +			compatible = "fsl,qoriq-gpio";
>> +			reg = <0x0 0x2310000 0x0 0x10000>;
>> +			interrupts = <0 67 0x4>;
>> +			gpio-controller;
>> +			#gpio-cells = <2>;
>> +			interrupt-controller;
>> +			#interrupt-cells = <2>;
>> +		};
>> +
>> +		wdog0: wdog at 2ad0000 {
>> +			compatible = "fsl,ls1012a-wdt",
>> +				     "fsl,ls1043a-wdt",
>> +				     "fsl,imx21-wdt";
>
>I understand "fsl,imx21-wdt" is the one that kernel driver matches, but why do we
>need "fsl,ls1043a-wdt" here?
 
OK, will remove "fsl,ls1043a-wdt",

>
>> +			reg = <0x0 0x2ad0000 0x0 0x10000>;
>> +			interrupts = <0 83 0x4>;
>> +			clocks = <&clockgen 4 0>;
>> +			clock-names = "wdog";
>
>clock-names is not required for fsl,imx21-wdt.

Ok , will remove clock-names = "wdog";
>
>> +			big-endian;
>> +		};
>> +
>> +		sai1: sai at 2b50000 {
>> +			#sound-dai-cells = <0>;
>> +			compatible = "fsl,vf610-sai";
>> +			reg = <0x0 0x2b50000 0x0 0x10000>;
>> +			interrupts = <0 148 0x4>;
>> +			clocks = <&clockgen 4 3>, <&clockgen 4 3>,
>> +				 <&clockgen 4 3>, <&clockgen 4 3>;
>> +			clock-names = "bus", "mclk1", "mclk2", "mclk3";
>> +			dma-names = "tx", "rx";
>> +			dmas = <&edma0 1 47>,
>> +			       <&edma0 1 46>;
>> +			status = "disabled";
>> +		};
>> +
>> +		sai2: sai at 2b60000 {
>> +			#sound-dai-cells = <0>;
>> +			compatible = "fsl,vf610-sai";
>> +			reg = <0x0 0x2b60000 0x0 0x10000>;
>> +			interrupts = <0 149 0x4>;
>> +			clocks = <&clockgen 4 3>, <&clockgen 4 3>,
>> +				 <&clockgen 4 3>, <&clockgen 4 3>;
>> +			clock-names = "bus", "mclk1", "mclk2", "mclk3";
>> +			dma-names = "tx", "rx";
>> +			dmas = <&edma0 1 45>,
>> +			       <&edma0 1 44>;
>> +			status = "disabled";
>> +		};
>> +
>> +		edma0: edma at 2c00000 {
>> +			#dma-cells = <2>;
>> +			compatible = "fsl,vf610-edma";
>> +			reg = <0x0 0x2c00000 0x0 0x10000>,
>> +			      <0x0 0x2c10000 0x0 0x10000>,
>> +			      <0x0 0x2c20000 0x0 0x10000>;
>> +			interrupts = <0 103 0x4>,
>> +				     <0 103 0x4>;
>> +			interrupt-names = "edma-tx", "edma-err";
>> +			dma-channels = <32>;
>> +			big-endian;
>> +			clock-names = "dmamux0", "dmamux1";
>> +			clocks = <&clockgen 4 3>,
>> +				 <&clockgen 4 3>;
>> +		};
>> +
>> +		sata: sata at 3200000 {
>> +			compatible = "fsl,ls1012a-ahci";
>> +			reg = <0x0 0x3200000 0x0 0x10000>;
>> +			interrupts = <0 69 0x4>;
>> +			clocks = <&clockgen 4 0>;
>> +		};
>> +
>> +		msi2: msi-controller2 at 1572000 {
>> +			compatible ="fsl,1s1012a-msi", "fsl,1s1021a-msi";
>> +			reg = <0x0 0x1572000 0x0 0x4>,
>> +			      <0x0 0x1572004 0x0 0x4>;
>> +			reg-names = "msiir", "msir";
>> +			msi-controller;
>> +			interrupts = <0 126 0x4>;
>> +		};
>> +
>> +		usb at 8600000 {
>> +			compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
>> +			reg = <0x0 0x8600000 0x0 0x1000>;
>> +			interrupts = <0 139 0x4>;
>> +			dr_mode = "host";
>> +			phy_type = "ulpi";
>> +			fsl,usb-erratum-a005697;
>
>It seems to me that fsl,usb-erratum-a005697 is neither documented or supported
>by kernel driver at all.

Yes the driver part using the erratum is not yet up-streamed, so will remove fsl,usb-erratum-a005697;

>
>> +		};
>> +
>> +		usb0: usb3 at 2f00000 {
>> +			compatible = "snps,dwc3";
>> +			reg = <0x0 0x2f00000 0x0 0x10000>;
>> +			interrupts = <0 60 0x4>;
>> +			dr_mode = "host";
>> +			configure-gfladj;

OK will remove this .

>
>Ditto
>
>Shawn
>
>> +			snps,dis_rxdet_inp3_quirk;
>> +		};
>> +
>> +		pcie at 3400000 {
>> +			compatible = "fsl,ls1012a-pcie",
>> +				     "fsl,ls1043a-pcie",
>> +				     "snps,dw-pcie";
>> +			reg = <0x00 0x03400000 0x0 0x00100000   /* controller
>registers */
>> +			       0x40 0x00000000 0x0 0x00002000>; /* configuration
>space */
>> +			reg-names = "regs", "config";
>> +			interrupts = <0 118 0x4>, /* controller interrupt */
>> +				     <0 117 0x4>; /* PME interrupt */
>> +			interrupt-names = "intr", "pme";
>> +			#address-cells = <3>;
>> +			#size-cells = <2>;
>> +			device_type = "pci";
>> +			num-lanes = <4>;
>> +			bus-range = <0x0 0xff>;
>> +			ranges = <0x81000000 0x0 0x00000000 0x40
>0x00010000 0x0 0x00010000   /* downstream I/O */
>> +				  0x82000000 0x0 0x40000000 0x40 0x40000000
>0x0 0x40000000>; /* non-prefetchable memory */
>> +			msi-parent = <&msi2>;
>> +			#interrupt-cells = <1>;
>> +			interrupt-map-mask = <0 0 0 7>;
>> +			interrupt-map = <0000 0 0 1 &gic 0 110 0x4>,
>> +					<0000 0 0 2 &gic 0 111 0x4>,
>> +					<0000 0 0 3 &gic 0 112 0x4>,
>> +					<0000 0 0 4 &gic 0 113 0x4>;
>> +		};
>> +	};
>> +};
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [linux-devel] [PATCH v2 1/1] arm64: Add DTS support for FSL's LS1012A SoC
From: Bhaskar U @ 2016-09-30 11:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <DB5PR0401MB1928BE0E1C08DD2FAC582FE191F90@DB5PR0401MB1928.eurprd04.prod.outlook.com>



>-----Original Message-----
>From: Scott Wood
>Sent: Tuesday, September 06, 2016 10:36 PM
>To: Shawn Guo <shawnguo@kernel.org>; Stuart Yoder <stuart.yoder@nxp.com>;
>Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>
>Cc: devicetree at vger.kernel.org; Bhaskar U <bhaskar.upadhaya@nxp.com>; Scott
>Wood <oss@buserror.net>; Prabhakar Kushwaha
><prabhakar.kushwaha@nxp.com>; linux-devel at gforge.freescale.net; Pratiyush
>Srivastava <pratiyush.srivastava@nxp.com>; linux-arm-
>kernel at lists.infradead.org
>Subject: Re: [linux-devel] [PATCH v2 1/1] arm64: Add DTS support for FSL's
>LS1012A SoC
>
>On 09/04/2016 08:47 PM, Shawn Guo wrote:
>> On Tue, Aug 30, 2016 at 02:07:17PM +0000, Stuart Yoder wrote:
>>>> On Mon, Aug 29, 2016 at 12:51:01PM -0500, Scott Wood wrote:
>>>>> On Mon, 2016-08-29 at 17:52 +0800, Shawn Guo wrote:
>>>>>> On Fri, Aug 26, 2016 at 03:57:21PM +0530, Bhaskar Upadhaya wrote:
>>>>>>>
>>>>>>> +		clockgen: clocking at 1ee1000 {
>>>>>>> +			compatible = "fsl,ls1012a-clockgen";
>>>>>> The compatible cannot be found in binding docs.
>>>>>
>>>>> From Documentation/devicetree/bindings/clock/qoriq-clock.txt:
>>>>>
>>>>> - compatible: Should contain a chip-specific clock block compatible
>>>>>         string and (if applicable) may contain a chassis-version clock
>>>>>         compatible string.
>>>>>
>>>>>         Chip-specific strings are of the form "fsl,<chip>-clockgen", such as:
>>>>>         * "fsl,p2041-clockgen"
>>>>>         * "fsl,p3041-clockgen"
>>>>>         * "fsl,p4080-clockgen"
>>>>>         * "fsl,p5020-clockgen"
>>>>>         * "fsl,p5040-clockgen"
>>>>>         * "fsl,t4240-clockgen"
>>>>>         * "fsl,b4420-clockgen"
>>>>>         * "fsl,b4860-clockgen"
>>>>>         * "fsl,ls1021a-clockgen"
>>>>>         Chassis-version clock strings include:
>>>>>         * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
>>>>>         * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
>>>>>
>>>>> I really hope we don't have to update every single
>>>>> fsl,<chip>-whatever binding every time a new chip comes out.  There
>>>>> are already other chips not listed, FWIW (e.g. t1040, t2080, ls1043a, and
>ls2080a).  That's why it says "such as".
>>>>
>>>> If I remember correctly, DT maintainers want every supported
>>>> compatible string explicitly listed in bindings doc.  And they even
>>>> added a check into checkpatch.pl with commit bff5da433525
>>>> ("checkpatch: add DT compatible string documentation checks").
>>>
>>> See Documentation/devicetree/bindings/submitting-patches.txt:
>>>
>>>   5) The wildcard "<chip>" may be used in compatible strings, as in
>>>      the following example:
>>>
>>>          - compatible: Must contain '"nvidia,<chip>-pcie",
>>>            "nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ...
>>>
>>>      As in the above example, the known values of "<chip>" should be
>>>      documented if it is used.
>>>
>>> It _is_ allowed to use the <chip> wildcard, and so you will not find
>>> all full compatible strings explicitly listed in bindings.  However,
>>> the chips themselves "should" be listed.
>>
>> + Rob and Mark
>>
>> Oops, I'm not aware of this DT document.  In that case, the DT
>> document and checkpatch is basically asking for conflicting thing.
>> Rob, Mark, can you guys please clarify?
>
>Checkpatch is a useful tool but it can't get everything right all the time.
>

So what should we do, shall I add "compatible = "fsl,ls1012a-clockgen";" in Documentation/devicetree/bindings/clock/qoriq-clock.txt ?

>-Scott

^ permalink raw reply

* [PATCHv4 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Richard Genoud @ 2016-09-30 11:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160930111606.zcain6i4nsujsg5s@piout.net>

2016-09-30 13:16 GMT+02:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> On 30/09/2016 at 13:04:28 +0200, Richard Genoud wrote :
>> Anyway, the problematics setups are all the setups with USMODE_HWHS
>> enabled on platform without Fifos or PDC,
>> i.e. all platforms but sama5d2 (Cyrille, correct me if I'm wrong).
>>
>
> This is a wrong assumption, at91rm9200 to at91sam9g45 all have a pdc.
> Please, don't break those platforms.
>
> The only affected platforms are sam9x5, sama5d3 and sama5d4.
Have you tested them ?

And why are you saying that rm9200 and g45 will be broken with this patch ?
If they have a pdc, they will fall in the case:
(atmel_use_pdc_rx(port) || atmel_use_fifo(port))
and thus use:
mode |= ATMEL_US_USMODE_HWHS;

won't they ?

^ permalink raw reply

* [PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution
From: Sekhar Nori @ 2016-09-30 11:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMpxmJVA+p1st7HzwoOJftArqpY-wUQb8WKbQFAEWnBOysxF6w@mail.gmail.com>

On Friday 30 September 2016 03:07 PM, Bartosz Golaszewski wrote:
> 2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
>> Hi,
>>
>> On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
>>> Add svga timings for 1024x768 resolution to the da850-lcdk
>>> device tree.
>>>
>>
> 
> [snip]
> 
>>
>> Why do you also call 1024x768 svga ?
>>
> 
> Thanks, should have been xga. will fix in v2.

When you send the v2, can you please include the driver folks too. I am
no expert on DRM and LCDC and would like to ensure they had a look at
the dts patches too.

Thanks,
Sekhar

^ permalink raw reply

* [PATCHv4 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Alexandre Belloni @ 2016-09-30 11:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACQ1gAg21UEeyT_yGed58HB1gkwfg4LA8u5AVMkKsY=d5-EbMQ@mail.gmail.com>

On 30/09/2016 at 13:45:47 +0200, Richard Genoud wrote :
> 2016-09-30 13:16 GMT+02:00 Alexandre Belloni
> <alexandre.belloni@free-electrons.com>:
> > On 30/09/2016 at 13:04:28 +0200, Richard Genoud wrote :
> >> Anyway, the problematics setups are all the setups with USMODE_HWHS
> >> enabled on platform without Fifos or PDC,
> >> i.e. all platforms but sama5d2 (Cyrille, correct me if I'm wrong).
> >>
> >
> > This is a wrong assumption, at91rm9200 to at91sam9g45 all have a pdc.
> > Please, don't break those platforms.
> >
> > The only affected platforms are sam9x5, sama5d3 and sama5d4.
> Have you tested them ?
> 
> And why are you saying that rm9200 and g45 will be broken with this patch ?
> If they have a pdc, they will fall in the case:
> (atmel_use_pdc_rx(port) || atmel_use_fifo(port))
> and thus use:
> mode |= ATMEL_US_USMODE_HWHS;
> 
> won't they ?

Well, this patch wouldn't have my ack if it was breaking them. However,
I'm still not sure about 3/3.

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

^ permalink raw reply

* [PATCH v4 0/5] drm: Add Support for Passive RGB to VGA bridges
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.

Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the screen if available (and if not,
fall back on XGA standards), set up the display pipeline to output on
the RGB bus with the proper timings, and you're done.

This serie also fixes a bunch of bugs uncovered when trying to
increase the resolution, and hence the pixel clock, of our
pipeline. It also fixes a few bugs in the DRM driver itself that went
unnoticed before.

Let me know what you think,
Maxime

Changes from v3:
  - Depends on OF in Kconfig
  - Fixed typos in the driver comments
  - Removed the mention of a "passive" bridge in the bindings doc
  - Made the strcuture const
  - Removed the nops and best_encoders implementations
  - Removed the call to drm_bridge_enable in the sun4i driver

Changes from v2:
  - Changed the compatible as suggested
  - Rebased on top 4.8

Changes from v1:
  - Switch to using a vga-connector
  - Use drm_encoder bridge pointer instead of doing our own
  - Report the connector status as unknown instead of connected by
    default, and as connected only if we can retrieve the EDID.
  - Switch to of_i2c_get_adapter by node, and put the reference when done
  - Rebased on linux-next	      

Maxime Ripard (5):
  drm/sun4i: rgb: Remove the bridge enable/disable functions
  drm/bridge: Add RGB to VGA bridge support
  ARM: sun5i: a13-olinuxino: Enable VGA bridge
  ARM: multi_v7: enable VGA bridge
  ARM: sunxi: Enable VGA bridge

 .../bindings/display/bridge/rgb-to-vga-bridge.txt  |  48 +++++
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts          |  54 +++++
 arch/arm/configs/multi_v7_defconfig                |   1 +
 arch/arm/configs/sunxi_defconfig                   |   1 +
 drivers/gpu/drm/bridge/Kconfig                     |   7 +
 drivers/gpu/drm/bridge/Makefile                    |   1 +
 drivers/gpu/drm/bridge/rgb-to-vga.c                | 239 +++++++++++++++++++++
 drivers/gpu/drm/sun4i/sun4i_rgb.c                  |   6 -
 8 files changed, 351 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
 create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c

-- 
2.9.3

^ permalink raw reply

* [PATCH v4 1/5] drm/sun4i: rgb: Remove the bridge enable/disable functions
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160930121352.30184-1-maxime.ripard@free-electrons.com>

The atomic helpers already call the drm_bridge_enable on our behalf,
there's no need to do it a second time.

Reported-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 4e4bea6f395c..d198ad7e5323 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -155,9 +155,6 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder *encoder)
 	if (!IS_ERR(tcon->panel))
 		drm_panel_prepare(tcon->panel);
 
-	/* encoder->bridge can be NULL; drm_bridge_enable checks for it */
-	drm_bridge_enable(encoder->bridge);
-
 	sun4i_tcon_channel_enable(tcon, 0);
 
 	if (!IS_ERR(tcon->panel))
@@ -177,9 +174,6 @@ static void sun4i_rgb_encoder_disable(struct drm_encoder *encoder)
 
 	sun4i_tcon_channel_disable(tcon, 0);
 
-	/* encoder->bridge can be NULL; drm_bridge_disable checks for it */
-	drm_bridge_disable(encoder->bridge);
-
 	if (!IS_ERR(tcon->panel))
 		drm_panel_unprepare(tcon->panel);
 }
-- 
2.9.3

^ permalink raw reply related

* [PATCH v4 2/5] drm/bridge: Add RGB to VGA bridge support
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160930121352.30184-1-maxime.ripard@free-electrons.com>

Some boards have an entirely passive RGB to VGA bridge, based on either
DACs or resistor ladders.

Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.

Add a bridge that doesn't do anything but expose the modes available on the
screen, either based on the EDIDs if available, or based on the XGA
standards.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 .../bindings/display/bridge/rgb-to-vga-bridge.txt  |  48 +++++
 drivers/gpu/drm/bridge/Kconfig                     |   7 +
 drivers/gpu/drm/bridge/Makefile                    |   1 +
 drivers/gpu/drm/bridge/rgb-to-vga.c                | 239 +++++++++++++++++++++
 4 files changed, 295 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
 create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c

diff --git a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
new file mode 100644
index 000000000000..a8375bc1f9cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
@@ -0,0 +1,48 @@
+Dumb RGB to VGA bridge
+----------------------
+
+This binding is aimed for dumb RGB to VGA bridges that do not require
+any configuration.
+
+Required properties:
+
+- compatible: Must be "rgb-to-vga-bridge"
+
+Required nodes:
+
+This device has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+
+Example
+-------
+
+bridge {
+	compatible = "rgb-to-vga-bridge";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port at 0 {
+			reg = <0>;
+
+			vga_bridge_in: endpoint {
+				remote-endpoint = <&tcon0_out_vga>;
+			};
+		};
+
+		port at 1 {
+			reg = <1>;
+
+			vga_bridge_out: endpoint {
+				remote-endpoint = <&vga_con_in>;
+			};
+		};
+	};
+};
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index b590e678052d..d690398c541c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -17,6 +17,13 @@ config DRM_ANALOGIX_ANX78XX
 	  the HDMI output of an application processor to MyDP
 	  or DisplayPort.
 
+config DRM_RGB_TO_VGA
+	tristate "Dumb RGB to VGA Bridge support"
+	depends on OF
+	select DRM_KMS_HELPER
+	help
+	  Support for passive RGB to VGA bridges
+
 config DRM_DW_HDMI
 	tristate
 	select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index efdb07e878f5..3bb8cbe09fe9 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
 ccflags-y := -Iinclude/drm
 
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
+obj-$(CONFIG_DRM_RGB_TO_VGA) += rgb-to-vga.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/rgb-to-vga.c b/drivers/gpu/drm/bridge/rgb-to-vga.c
new file mode 100644
index 000000000000..14843baa5d11
--- /dev/null
+++ b/drivers/gpu/drm/bridge/rgb-to-vga.c
@@ -0,0 +1,239 @@
+/*
+ * Copyright (C) 2015-2016 Free Electrons
+ * Copyright (C) 2015-2016 NextThing Co
+ *
+ * Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This program 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.
+ */
+
+#include <linux/module.h>
+#include <linux/of_graph.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+
+struct dumb_vga {
+	struct drm_bridge	bridge;
+	struct drm_connector	connector;
+
+	struct i2c_adapter	*ddc;
+};
+
+static inline struct dumb_vga *
+drm_bridge_to_dumb_vga(struct drm_bridge *bridge)
+{
+	return container_of(bridge, struct dumb_vga, bridge);
+}
+
+static inline struct dumb_vga *
+drm_connector_to_dumb_vga(struct drm_connector *connector)
+{
+	return container_of(connector, struct dumb_vga, connector);
+}
+
+static int dumb_vga_get_modes(struct drm_connector *connector)
+{
+	struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
+	struct edid *edid;
+	int ret;
+
+	if (IS_ERR(vga->ddc))
+		goto fallback;
+
+	edid = drm_get_edid(connector, vga->ddc);
+	if (!edid) {
+		DRM_INFO("EDID readout failed, falling back to standard modes\n");
+		goto fallback;
+	}
+
+	drm_mode_connector_update_edid_property(connector, edid);
+	return drm_add_edid_modes(connector, edid);
+
+fallback:
+	/*
+	 * In case we cannot retrieve the EDIDs (broken or missing i2c
+	 * bus), fallback on the XGA standards
+	 */
+	ret = drm_add_modes_noedid(connector, 1920, 1200);
+
+	/* And prefer a mode pretty much anyone can handle */
+	drm_set_preferred_mode(connector, 1024, 768);
+
+	return ret;
+}
+
+static struct drm_encoder *
+dumb_vga_best_encoder(struct drm_connector *connector)
+{
+	struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
+
+	return vga->bridge.encoder;
+}
+
+static const struct drm_connector_helper_funcs dumb_vga_con_helper_funcs = {
+	.get_modes	= dumb_vga_get_modes,
+};
+
+static enum drm_connector_status
+dumb_vga_connector_detect(struct drm_connector *connector, bool force)
+{
+	struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
+
+	/*
+	 * Even if we have an I2C bus, we can't assume that the cable
+	 * is disconnected if drm_probe_ddc fails. Some cables don't
+	 * wire the DDC pins, or the I2C bus might not be working at
+	 * all.
+	 */
+	if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
+		return connector_status_connected;
+
+	return connector_status_unknown;
+}
+
+static void
+dumb_vga_connector_destroy(struct drm_connector *connector)
+{
+	drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs dumb_vga_con_funcs = {
+	.dpms			= drm_atomic_helper_connector_dpms,
+	.detect			= dumb_vga_connector_detect,
+	.fill_modes		= drm_helper_probe_single_connector_modes,
+	.destroy		= dumb_vga_connector_destroy,
+	.reset			= drm_atomic_helper_connector_reset,
+	.atomic_duplicate_state	= drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state	= drm_atomic_helper_connector_destroy_state,
+};
+
+static int dumb_vga_attach(struct drm_bridge *bridge)
+{
+	struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+	int ret;
+
+	if (!bridge->encoder) {
+		DRM_ERROR("Missing encoder\n");
+		return -ENODEV;
+	}
+
+	drm_connector_helper_add(&vga->connector,
+				 &dumb_vga_con_helper_funcs);
+	ret = drm_connector_init(bridge->dev, &vga->connector,
+				 &dumb_vga_con_funcs, DRM_MODE_CONNECTOR_VGA);
+	if (ret) {
+		DRM_ERROR("Failed to initialize connector\n");
+		return ret;
+	}
+
+	drm_mode_connector_attach_encoder(&vga->connector,
+					  bridge->encoder);
+
+	return 0;
+}
+
+static void dumb_vga_nop(struct drm_bridge *bridge) {};
+
+static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
+	.attach		= dumb_vga_attach,
+};
+
+static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
+{
+	struct device_node *end_node, *phandle, *remote;
+	struct i2c_adapter *ddc;
+
+	end_node = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
+	if (!end_node) {
+		dev_err(dev, "Missing connector endpoint\n");
+		return ERR_PTR(-ENODEV);
+	}
+
+	remote = of_graph_get_remote_port_parent(end_node);
+	of_node_put(end_node);
+	if (!remote) {
+		dev_err(dev, "Enable to parse remote node\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
+	of_node_put(remote);
+	if (!phandle)
+		return ERR_PTR(-ENODEV);
+
+	ddc = of_get_i2c_adapter_by_node(phandle);
+	of_node_put(phandle);
+	if (!ddc)
+		return ERR_PTR(-EPROBE_DEFER);
+
+	return ddc;
+}
+
+static int dumb_vga_probe(struct platform_device *pdev)
+{
+	struct dumb_vga *vga;
+	int ret;
+
+	vga = devm_kzalloc(&pdev->dev, sizeof(*vga), GFP_KERNEL);
+	if (!vga)
+		return -ENOMEM;
+	platform_set_drvdata(pdev, vga);
+
+	vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
+	if (IS_ERR(vga->ddc)) {
+		if (PTR_ERR(vga->ddc) == -ENODEV) {
+			dev_info(&pdev->dev,
+				 "No i2c bus specified... Disabling EDID readout\n");
+		} else {
+			dev_err(&pdev->dev, "Couldn't retrieve i2c bus\n");
+			return PTR_ERR(vga->ddc);
+		}
+	}
+
+	vga->bridge.funcs = &dumb_vga_bridge_funcs;
+	vga->bridge.of_node = pdev->dev.of_node;
+
+	ret = drm_bridge_add(&vga->bridge);
+	if (ret && !IS_ERR(vga->ddc))
+		i2c_put_adapter(vga->ddc);
+
+	return ret;
+}
+
+static int dumb_vga_remove(struct platform_device *pdev)
+{
+	struct dumb_vga *vga = platform_get_drvdata(pdev);
+
+	drm_bridge_remove(&vga->bridge);
+
+	if (!IS_ERR(vga->ddc))
+		i2c_put_adapter(vga->ddc);
+
+	return 0;
+}
+
+static const struct of_device_id dumb_vga_match[] = {
+	{ .compatible = "rgb-to-vga-bridge" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, dumb_vga_match);
+
+struct platform_driver dumb_vga_driver = {
+	.probe	= dumb_vga_probe,
+	.remove	= dumb_vga_remove,
+	.driver		= {
+		.name		= "rgb-to-vga-bridge",
+		.of_match_table	= dumb_vga_match,
+	},
+};
+module_platform_driver(dumb_vga_driver);
+
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
+MODULE_DESCRIPTION("Dumb RGB to VGA bridge driver");
+MODULE_LICENSE("GPL");
-- 
2.9.3

^ permalink raw reply related

* [PATCH v4 3/5] ARM: sun5i: a13-olinuxino: Enable VGA bridge
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160930121352.30184-1-maxime.ripard@free-electrons.com>

Now that we have support for the VGA bridges using our DRM driver, enable
the display engine for the Olimex A13-Olinuxino.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index b3c234c65ea1..01ce7ea9032d 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -72,6 +72,47 @@
 			default-state = "on";
 		};
 	};
+
+	bridge {
+		compatible = "rgb-to-vga-bridge";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+
+				vga_bridge_in: endpoint {
+					remote-endpoint = <&tcon0_out_vga>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+
+				vga_bridge_out: endpoint {
+					remote-endpoint = <&vga_con_in>;
+				};
+			};
+		};
+	};
+
+	vga {
+		compatible = "vga-connector";
+
+		port {
+			vga_con_in: endpoint {
+				remote-endpoint = <&vga_bridge_out>;
+			};
+		};
+	};
+};
+
+&be0 {
+	status = "okay";
 };
 
 &ehci0 {
@@ -211,6 +252,19 @@
 	status = "okay";
 };
 
+&tcon0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&lcd_rgb666_pins>;
+	status = "okay";
+};
+
+&tcon0_out {
+	tcon0_out_vga: endpoint at 0 {
+		reg = <0>;
+		remote-endpoint = <&vga_bridge_in>;
+	};
+};
+
 &uart1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart1_pins_b>;
-- 
2.9.3

^ permalink raw reply related

* [PATCH v4 4/5] ARM: multi_v7: enable VGA bridge
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160930121352.30184-1-maxime.ripard@free-electrons.com>

Enable the RGB to VGA bridge driver in the defconfig

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 2c8665cd9dc5..22ef41afc658 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -567,6 +567,7 @@ CONFIG_DRM=y
 CONFIG_DRM_I2C_ADV7511=m
 # CONFIG_DRM_I2C_CH7006 is not set
 # CONFIG_DRM_I2C_SIL164 is not set
+CONFIG_DRM_RGB_TO_VGA=m
 CONFIG_DRM_NXP_PTN3460=m
 CONFIG_DRM_PARADE_PS8622=m
 CONFIG_DRM_NOUVEAU=m
-- 
2.9.3

^ permalink raw reply related

* [PATCH v4 5/5] ARM: sunxi: Enable VGA bridge
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160930121352.30184-1-maxime.ripard@free-electrons.com>

Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/configs/sunxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 714da336ec86..d830e258db59 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -98,6 +98,7 @@ CONFIG_MEDIA_RC_SUPPORT=y
 CONFIG_RC_DEVICES=y
 CONFIG_IR_SUNXI=y
 CONFIG_DRM=y
+CONFIG_DRM_RGB_TO_VGA=y
 CONFIG_DRM_SUN4I=y
 CONFIG_FB=y
 CONFIG_FB_SIMPLE=y
-- 
2.9.3

^ permalink raw reply related

* [PATCHv4 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Richard Genoud @ 2016-09-30 12:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160930115424.yhy6f72jomz5bknw@piout.net>

2016-09-30 13:54 GMT+02:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> On 30/09/2016 at 13:45:47 +0200, Richard Genoud wrote :
>> 2016-09-30 13:16 GMT+02:00 Alexandre Belloni
>> <alexandre.belloni@free-electrons.com>:
>> > On 30/09/2016 at 13:04:28 +0200, Richard Genoud wrote :
>> >> Anyway, the problematics setups are all the setups with USMODE_HWHS
>> >> enabled on platform without Fifos or PDC,
>> >> i.e. all platforms but sama5d2 (Cyrille, correct me if I'm wrong).
>> >>
>> >
>> > This is a wrong assumption, at91rm9200 to at91sam9g45 all have a pdc.
>> > Please, don't break those platforms.
>> >
>> > The only affected platforms are sam9x5, sama5d3 and sama5d4.
>> Have you tested them ?
>>
>> And why are you saying that rm9200 and g45 will be broken with this patch ?
>> If they have a pdc, they will fall in the case:
>> (atmel_use_pdc_rx(port) || atmel_use_fifo(port))
>> and thus use:
>> mode |= ATMEL_US_USMODE_HWHS;
>>
>> won't they ?
>
> Well, this patch wouldn't have my ack if it was breaking them.
It's not.
Read the code.

>However, I'm still not sure about 3/3.
As I said 2 weeks from now ( https://lkml.org/lkml/2016/9/14/263 ) the
only case where
we would want to drop the CRTSCTS flag is when there's no pin muxed
for CTS/RTS nor GPIOs.
Fell free to give a patch for that.

To be clear : this patch (2/3) unbreaks ALL platforms with GPIOs as CTS/RTS
and 3/3 unbreaks sam9x5 / sama5d3 / sama5d4 platform with CTS/RTS as !GPIOs.

^ permalink raw reply

* [PATCH v2 2/2] drm: zte: add initial vou drm driver
From: Emil Velikov @ 2016-09-30 12:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1474727185-24180-3-git-send-email-shawn.guo@linaro.org>

Hi Shawn,

A couple of fly-by suggestions, which I hope you'll find useful :-)

On 24 September 2016 at 15:26, Shawn Guo <shawn.guo@linaro.org> wrote:

> +
 > +       val = ((vm.hsync_len - 1) << SYNC_WIDE_SHIFT) & SYNC_WIDE_MASK;
To save some writing/minimise the chances to typos getting, in you can
have single/collection to static inline functions similar to msm [1].
On a similar note inline wrappers zte_read/write/mask (around
writel/readl) will provide quite useful for debugging/tracing :-)

[1] drivers/gpu/drm/msm/adreno/a4xx.xml.h


> +       if (IS_ERR(zcrtc->pixclk))
> +               return ERR_PTR(PTR_ERR(zcrtc->pixclk));
You might want to s/ERR_PTR(PTR_ERR// or s/ERR_PTR(PTR_ERR/ERR_CAST/
through the patch.


> +static int zx_drm_bind(struct device *dev)
> +{
> +       struct drm_device *drm;
> +       struct zx_drm_private *priv;
> +       int ret;
> +
> +       priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +       if (!priv)
> +               return -ENOMEM;
> +
> +       drm = drm_dev_alloc(&zx_drm_driver, dev);
> +       if (!drm)
> +               return -ENOMEM;
> +
> +       drm->dev_private = priv;
> +       dev_set_drvdata(dev, drm);
> +
> +       drm_mode_config_init(drm);
> +       drm->mode_config.min_width = 16;
> +       drm->mode_config.min_height = 16;
> +       drm->mode_config.max_width = 4096;
> +       drm->mode_config.max_height = 4096;
> +       drm->mode_config.funcs = &zx_drm_mode_config_funcs;
> +
> +       ret = drm_dev_register(drm, 0);
The documentation states that drm_dev_register() should be called
after the hardware is setup. which some drivers seems to interpret as
...

> +       if (ret)
> +               goto out_free;
> +
> +       ret = component_bind_all(dev, drm);
> +       if (ret) {
> +               DRM_ERROR("Failed to bind all components\n");
> +               goto out_unregister;
> +       }
> +
> +       ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> +       if (ret < 0) {
> +               DRM_ERROR("failed to initialise vblank\n");
> +               goto out_unbind;
> +       }
> +
> +       /*
> +        * We will manage irq handler on our own.  In this case, irq_enabled
> +        * need to be true for using vblank core support.
> +        */
> +       drm->irq_enabled = true;
> +
> +       drm_mode_config_reset(drm);
> +       drm_kms_helper_poll_init(drm);
> +
> +       priv->fbdev = drm_fbdev_cma_init(drm, 32, drm->mode_config.num_crtc,
> +                                        drm->mode_config.num_connector);
... calling it after these. If that's the correct case - perhaps we
can throw a WARN or similar within the above functions to catch
present/future misuse ?


> +       if (IS_ERR(priv->fbdev)) {
> +               ret = PTR_ERR(priv->fbdev);
> +               priv->fbdev = NULL;
> +               goto out_fini;
> +       }
> +
> +       return 0;
> +
> +out_fini:
> +       drm_kms_helper_poll_fini(drm);
> +       drm_mode_config_cleanup(drm);
> +       drm_vblank_cleanup(drm);
> +out_unbind:
> +       component_unbind_all(dev, drm);
> +out_unregister:
> +       drm_dev_unregister(drm);
> +out_free:
> +       dev_set_drvdata(dev, NULL);
> +       drm_dev_unref(drm);
> +       return ret;
> +}
> +
> +static void zx_drm_unbind(struct device *dev)
> +{
> +       struct drm_device *drm = dev_get_drvdata(dev);
> +       struct zx_drm_private *priv = drm->dev_private;
> +
> +       if (priv->fbdev) {
> +               drm_fbdev_cma_fini(priv->fbdev);
> +               priv->fbdev = NULL;
> +       }
> +       drm_kms_helper_poll_fini(drm);
> +       component_unbind_all(dev, drm);
> +       drm_vblank_cleanup(drm);
> +       drm_mode_config_cleanup(drm);
> +       drm_dev_unregister(drm);
> +       drm_dev_unref(drm);
> +       drm->dev_private = NULL;
> +       dev_set_drvdata(dev, NULL);
This and the teardown path in bind() are asymmetrical. Furthermore you
want to call drm_dev_unregister() first, according to its
documentation.
As mentioned above - perhaps it's worth providing feedback for drivers
which get the order wrong ?



> +static int zx_hdmi_bind(struct device *dev, struct device *master, void *data)
> +{


> +
> +       clk_prepare_enable(hdmi->cec_clk);
> +       clk_prepare_enable(hdmi->osc_clk);
> +       clk_prepare_enable(hdmi->xclk);
> +
> +       ret = zx_hdmi_register(drm, hdmi);
> +       if (ret)
> +               return ret;
> +

> +       return 0;
> +}
> +
> +static void zx_hdmi_unbind(struct device *dev, struct device *master,
> +                          void *data)
> +{
> +       struct zx_hdmi *hdmi = dev_get_drvdata(dev);
> +
> +       clk_disable_unprepare(hdmi->cec_clk);
> +       clk_disable_unprepare(hdmi->osc_clk);
> +       clk_disable_unprepare(hdmi->xclk);
Nit: you want the teardown to happen in reverse order of the setup. I
might have missed a few similar cases within the patch, so please
double-check.


> +static int zx_gl_get_fmt(uint32_t format)
> +{
> +       switch (format) {
> +       case DRM_FORMAT_ARGB8888:
> +       case DRM_FORMAT_XRGB8888:
> +               return GL_FMT_ARGB8888;
> +       case DRM_FORMAT_RGB888:
> +               return GL_FMT_RGB888;
> +       case DRM_FORMAT_RGB565:
> +               return GL_FMT_RGB565;
> +       case DRM_FORMAT_ARGB1555:
> +               return GL_FMT_ARGB1555;
> +       case DRM_FORMAT_ARGB4444:
> +               return GL_FMT_ARGB4444;
> +       default:
> +               WARN_ONCE(1, "invalid pixel format %d\n", format);
> +               return -EINVAL;
Afaics the only user of this is atomic_update() and that function
cannot fail. You might want to move this to the _check() function.
Same logic goes for the rest of the driver, in case I've missed any.


Regards,
Emil

^ permalink raw reply

* [PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution
From: Karl Beldan @ 2016-09-30 12:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMpxmJVA+p1st7HzwoOJftArqpY-wUQb8WKbQFAEWnBOysxF6w@mail.gmail.com>

On Fri, Sep 30, 2016 at 11:37:57AM +0200, Bartosz Golaszewski wrote:
> 2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> > Hi,
> >
> > On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
> >> Add svga timings for 1024x768 resolution to the da850-lcdk
> >> device tree.
> >>
> >
> 
> [snip]
> 
> >
> > Why do you also call 1024x768 svga ?
> >
> 
> Thanks, should have been xga. will fix in v2.
> 
> > I don't think the LCDK can cope with this resolution at this frequency
> > (in terms of mem bandwidth), at least that's what I observed back in
> > August. If confirmed I think it is worth mentioning in the log at least,
> > but then I doubt adding this config would be useful.
> >
> 
> Thanks for the heads up. How would that manifest itself? This seems to
> work fine for me - I'm not getting any warnings on a simple system -
> maybe if I added some additional memory load it would complain.
> 

A mere dmesg > /dev/tty0 (or repeatedly cat-ting a file to /dev/tty0)
should suffice to make the issue visible and trigger FIFO underflows.

Regards, 
Karl

^ 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