* [PATCH] ARM: dts: AM571x-IDK Initial Support
From: Lokesh Vutla @ 2016-11-21 5:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Schuyler Patton <spatton@ti.com>
The AM571x-IDK board is a board based on TI's AM5718 SOC
which has a single core 1.5GHz A15 processor. This board is a
development platform for the Industrial market with:
- 1GB of DDR3L
- Dual 1Gbps Ethernet
- HDMI,
- PRU-ICSS
- uSD
- 16GB eMMC
- CAN
- RS-485
- PCIe
- USB3.0
- Video Input Port
- Industrial IO port and expansion connector
The link to the data sheet and TRM can be found here:
http://www.ti.com/product/AM5718
Initial support is only for basic peripherals.
Signed-off-by: Schuyler Patton <spatton@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
Logs: http://pastebin.ubuntu.com/23510390/
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/am571x-idk.dts | 82 ++++++++++++++++++++++
3 files changed, 86 insertions(+)
create mode 100644 arch/arm/boot/dts/am571x-idk.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index f53e2ee..647ffd3 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -175,6 +175,9 @@ Boards:
- AM5728 IDK
compatible = "ti,am5728-idk", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
+- AM5718 IDK
+ compatible = "ti,am5718-idk", "ti,am5728", "ti,dra722", "ti,dra72", "ti,dra7"
+
- DRA742 EVM: Software Development Board for DRA742
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..c298078 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -588,6 +588,7 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
am57xx-cl-som-am57x.dtb \
am57xx-sbc-am57x.dtb \
am572x-idk.dtb \
+ am571x-idk.dtb \
dra7-evm.dtb \
dra72-evm.dtb \
dra72-evm-revc.dtb
diff --git a/arch/arm/boot/dts/am571x-idk.dts b/arch/arm/boot/dts/am571x-idk.dts
new file mode 100644
index 0000000..a6a743e
--- /dev/null
+++ b/arch/arm/boot/dts/am571x-idk.dts
@@ -0,0 +1,82 @@
+/*
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "dra72x.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "am57xx-idk-common.dtsi"
+
+/ {
+ model = "TI AM5718 IDK";
+ compatible = "ti,am5718-idk", "ti,am5718", "ti,dra722",
+ "ti,dra72", "ti,dra7";
+
+ memory at 0 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x40000000>;
+ };
+
+ status-leds {
+ compatible = "gpio-leds";
+ cpu0-led {
+ label = "status0:red:cpu0";
+ gpios = <&gpio2 25 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "cpu0";
+ };
+
+ usr0-led {
+ label = "status0:green:usr";
+ gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ heartbeat-led {
+ label = "status0:blue:heartbeat";
+ gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "heartbeat";
+ };
+
+ usr1-led {
+ label = "status1:red:usr";
+ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ usr2-led {
+ label = "status1:green:usr";
+ gpios = <&gpio2 21 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ mmc0-led {
+ label = "status1:blue:mmc0";
+ gpios = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+ extcon_usb2: extcon_usb2 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&gpio5 7 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&ldo1_reg>;
+ bus-width = <4>;
+ cd-gpios = <&gpio6 27 0>; /* gpio 219 */
+};
+
+&omap_dwc3_2 {
+ extcon = <&extcon_usb2>;
+};
--
2.10.1
^ permalink raw reply related
* [PATCH v2 4/4] spi: spi-fsl-dspi: Minor code cleanup and error path fixes
From: Sanchayan Maity @ 2016-11-21 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479706671.git.maitysanchayan@gmail.com>
Code cleanup for improving code readability and error path fixes
and cleanup removing use of devm_kfree.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 08882f7..2987a16 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -226,8 +226,10 @@ static void dspi_rx_dma_callback(void *arg)
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
for (i = 0; i < dma->curr_xfer_len; i++) {
d = dspi->dma->rx_dma_buf[i];
- rx_word ? (*(u16 *)dspi->rx = d) :
- (*(u8 *)dspi->rx = d);
+ if (rx_word)
+ *(u16 *)dspi->rx = d;
+ else
+ *(u8 *)dspi->rx = d;
dspi->rx += rx_word + 1;
}
}
@@ -247,14 +249,20 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
tx_word = is_double_byte_mode(dspi);
for (i = 0; i < dma->curr_xfer_len - 1; i++) {
- val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
+ if (tx_word)
+ val = *(u16 *) dspi->tx;
+ else
+ val = *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] =
SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
dspi->tx += tx_word + 1;
}
- val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
+ if (tx_word)
+ val = *(u16 *) dspi->tx;
+ else
+ val = *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
SPI_PUSHR_PCS(dspi->cs) |
SPI_PUSHR_CTAS(0);
@@ -430,9 +438,11 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr)
return 0;
err_slave_config:
- devm_kfree(dev, dma->rx_dma_buf);
+ dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
+ dma->rx_dma_buf, dma->rx_dma_phys);
err_rx_dma_buf:
- devm_kfree(dev, dma->tx_dma_buf);
+ dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
+ dma->tx_dma_buf, dma->tx_dma_phys);
err_tx_dma_buf:
dma_release_channel(dma->chan_tx);
err_tx_channel:
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/4] spi: spi-fsl-dspi: Fix incorrect DMA setup
From: Sanchayan Maity @ 2016-11-21 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479706671.git.maitysanchayan@gmail.com>
Currently dmaengine_prep_slave_single was being called with length
set to the complete DMA buffer size. This resulted in unwanted bytes
being transferred to the SPI register leading to clock and MOSI lines
having unwanted data even after chip select got deasserted and the
required bytes having been transferred.
While at it also clean up the use of curr_xfer_len which is central
to the DMA setup, from bytes to DMA transfers for every use.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 35 ++++++++++++++++++-----------------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 41422cd..08882f7 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -151,6 +151,7 @@ static const struct fsl_dspi_devtype_data ls2085a_data = {
};
struct fsl_dspi_dma {
+ /* Length of transfer in words of DSPI_FIFO_SIZE */
u32 curr_xfer_len;
u32 *tx_dma_buf;
@@ -217,15 +218,13 @@ static void dspi_rx_dma_callback(void *arg)
struct fsl_dspi *dspi = arg;
struct fsl_dspi_dma *dma = dspi->dma;
int rx_word;
- int i, len;
+ int i;
u16 d;
rx_word = is_double_byte_mode(dspi);
- len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
- for (i = 0; i < len; i++) {
+ for (i = 0; i < dma->curr_xfer_len; i++) {
d = dspi->dma->rx_dma_buf[i];
rx_word ? (*(u16 *)dspi->rx = d) :
(*(u8 *)dspi->rx = d);
@@ -242,14 +241,12 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
struct device *dev = &dspi->pdev->dev;
int time_left;
int tx_word;
- int i, len;
+ int i;
u16 val;
tx_word = is_double_byte_mode(dspi);
- len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
- for (i = 0; i < len - 1; i++) {
+ for (i = 0; i < dma->curr_xfer_len - 1; i++) {
val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] =
SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
@@ -267,7 +264,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->tx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -283,7 +282,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
dma->rx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->rx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -330,17 +331,17 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
struct device *dev = &dspi->pdev->dev;
int curr_remaining_bytes;
int bytes_per_buffer;
- int tx_word;
+ int word = 1;
int ret = 0;
- tx_word = is_double_byte_mode(dspi);
+ if (is_double_byte_mode(dspi))
+ word = 2;
curr_remaining_bytes = dspi->len;
+ bytes_per_buffer = DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE;
while (curr_remaining_bytes) {
/* Check if current transfer fits the DMA buffer */
- dma->curr_xfer_len = curr_remaining_bytes;
- bytes_per_buffer = DSPI_DMA_BUFSIZE /
- (DSPI_FIFO_SIZE / (tx_word ? 2 : 1));
- if (curr_remaining_bytes > bytes_per_buffer)
+ dma->curr_xfer_len = curr_remaining_bytes / word;
+ if (dma->curr_xfer_len > bytes_per_buffer)
dma->curr_xfer_len = bytes_per_buffer;
ret = dspi_next_xfer_dma_submit(dspi);
@@ -349,7 +350,7 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
goto exit;
} else {
- curr_remaining_bytes -= dma->curr_xfer_len;
+ curr_remaining_bytes -= dma->curr_xfer_len * word;
if (curr_remaining_bytes < 0)
curr_remaining_bytes = 0;
dspi->len = curr_remaining_bytes;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/4] spi: spi-fsl-dspi: Fix continuous selection format
From: Sanchayan Maity @ 2016-11-21 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479706671.git.maitysanchayan@gmail.com>
Current DMA implementation was not handling the continuous selection
format viz. SPI chip select would be deasserted even between sequential
serial transfers. Use the cs_change variable and correctly set or
reset the CONT bit accordingly for case where peripherals require
the chip select to be asserted between sequential transfers.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index b1ee1f5..41422cd 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -261,6 +261,8 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
SPI_PUSHR_PCS(dspi->cs) |
SPI_PUSHR_CTAS(0);
+ if (!dspi->cs_change)
+ dspi->dma->tx_dma_buf[i] |= SPI_PUSHR_CONT;
dspi->tx += tx_word + 1;
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
From: Sanchayan Maity @ 2016-11-21 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479706671.git.maitysanchayan@gmail.com>
Current DMA implementation had a bug where the DMA transfer would
exit the loop in dspi_transfer_one_message after the completion of
a single transfer. This results in a multi message transfer submitted
with SPI_IOC_MESSAGE to terminate incorrectly without an error.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
---
drivers/spi/spi-fsl-dspi.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index bc64700..b1ee1f5 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -714,7 +714,7 @@ static int dspi_transfer_one_message(struct spi_master *master,
SPI_RSER_TFFFE | SPI_RSER_TFFFD |
SPI_RSER_RFDFE | SPI_RSER_RFDFD);
status = dspi_dma_xfer(dspi);
- goto out;
+ break;
default:
dev_err(&dspi->pdev->dev, "unsupported trans_mode %u\n",
trans_mode);
@@ -722,9 +722,13 @@ static int dspi_transfer_one_message(struct spi_master *master,
goto out;
}
- if (wait_event_interruptible(dspi->waitq, dspi->waitflags))
- dev_err(&dspi->pdev->dev, "wait transfer complete fail!\n");
- dspi->waitflags = 0;
+ if (trans_mode != DSPI_DMA_MODE) {
+ if (wait_event_interruptible(dspi->waitq,
+ dspi->waitflags))
+ dev_err(&dspi->pdev->dev,
+ "wait transfer complete fail!\n");
+ dspi->waitflags = 0;
+ }
if (transfer->delay_usecs)
udelay(transfer->delay_usecs);
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/4] Fixes for Vybrid SPI DMA implementation
From: Sanchayan Maity @ 2016-11-21 5:54 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
The following set of patches have fixes for Vybrid SPI DMA
implementation along with some minor clean ups requested
at time when v3 version of SPI DMA support patch was accepted.
This series of patches is based on top of branch topic/fsl-dspi.
http://git.kernel.org/cgit/linux/kernel/git/broonie/spi.git/log/?h=topic/fsl-dspi
The patches have been tested on a Toradex Colibri Vybrid VF61 module
and now incoporate feedback from Stefan on version 1 of patchset.
Changes since v1:
1. Place the continuous selection format patch second in order and remove
code duplication
2. Improve the use of curr_xfer_len and instead of converting from bytes
to DMA transfers in every use, do it at a single place. Accordingly change
it's use at other places
3. Code cleanup patch has less to clean with change above
v1:
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1274632.html
Thanks & Regards,
Sanchayan.
Sanchayan Maity (4):
spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
spi: spi-fsl-dspi: Fix continuous selection format
spi: spi-fsl-dspi: Fix incorrect DMA setup
spi: spi-fsl-dspi: Minor code cleanup and error path fixes
drivers/spi/spi-fsl-dspi.c | 71 ++++++++++++++++++++++++++++------------------
1 file changed, 44 insertions(+), 27 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH v3] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Wenyou Yang @ 2016-11-21 5:14 UTC (permalink / raw)
To: linux-arm-kernel
The sama5d36ek CMP board is the variant of sama5d3xek board.
It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
some power rail. Its main purpose is used to measure the power
consumption.
The difference of the sama5d36ek CMP dts from sama5d36ek dts is
listed as below.
1. The USB host nodes are removed, that is, the USB host is disabled.
2. The gpio_keys node is added to wake up from the sleep.
3. The LCD isn't supported due to the pins for LCD are conflicted
with gpio_keys.
4. The adc0 node support the pinctrl sleep state to fix the over
consumption on VDDANA.
As said in errata, "When the USB host ports are used in high speed
mode (EHCI), it is not possible to suspend the ports if no device is
attached on each port. This leads to increased power consumption even
if the system is in a low power mode." That is why the the USB host
is disabled.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
Changes in v3:
- Use a dual license scheme for DT files.
- Use the proper model name and the compatible string to reflect
the nature of this new "CMP" board.
- Change name of wakeup property to "wakeup-source".
- Remove unnecessary comments.
- Remove bootargs.
Changes in v2:
- Add the pinctrl sleep state for adc0 node to fix the over
consumption on VDDANA.
- Improve the commit log.
arch/arm/boot/dts/sama5d36ek_cmp.dts | 87 ++++++++++
arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 201 +++++++++++++++++++++++
arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 301 ++++++++++++++++++++++++++++++++++
3 files changed, 589 insertions(+)
create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
new file mode 100644
index 0000000..b632143
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
@@ -0,0 +1,87 @@
+/*
+ * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+#include "sama5d36.dtsi"
+#include "sama5d3xmb_cmp.dtsi"
+
+/ {
+ model = "Atmel SAMA5D36EK-CMP";
+ compatible = "atmel,sama5d36ek-cmp", "atmel,sama5d3xmb-cmp", "atmel,sama5d3xcm-cmp", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ spi0: spi at f0004000 {
+ status = "okay";
+ };
+
+ ssc0: ssc at f0008000 {
+ status = "okay";
+ };
+
+ can0: can at f000c000 {
+ status = "okay";
+ };
+
+ i2c0: i2c at f0014000 {
+ status = "okay";
+ };
+
+ i2c1: i2c at f0018000 {
+ status = "okay";
+ };
+
+ macb0: ethernet at f0028000 {
+ status = "okay";
+ };
+
+ macb1: ethernet at f802c000 {
+ status = "okay";
+ };
+ };
+ };
+
+ sound {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
new file mode 100644
index 0000000..dc7572b
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
@@ -0,0 +1,201 @@
+/*
+ * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/ {
+ compatible = "atmel,sama5d3xcm-cmp", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x20000000>;
+ };
+
+ clocks {
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <12000000>;
+ };
+ };
+
+ ahb {
+ apb {
+ spi0: spi at f0004000 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
+ };
+
+ macb0: ethernet at f0028000 {
+ phy-mode = "rgmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy at 1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+
+ ethernet-phy at 7 {
+ reg = <0x7>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+ };
+
+ i2c1: i2c at f0018000 {
+ pmic: act8865 at 5b {
+ compatible = "active-semi,act8865";
+ reg = <0x5b>;
+ status = "disabled";
+
+ regulators {
+ vcc_1v8_reg: DCDC_REG1 {
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vcc_1v2_reg: DCDC_REG2 {
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ };
+
+ vcc_3v3_reg: DCDC_REG3 {
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddana_reg: LDO_REG1 {
+ regulator-name = "VDDANA";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddfuse_reg: LDO_REG2 {
+ regulator-name = "FUSE_2V5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ };
+ };
+ };
+ };
+
+ nand0: nand at 60000000 {
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+ status = "okay";
+
+ at91bootstrap at 0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ bootloader at 40000 {
+ label = "bootloader";
+ reg = <0x40000 0x80000>;
+ };
+
+ bootloaderenv at c0000 {
+ label = "bootloader env";
+ reg = <0xc0000 0xc0000>;
+ };
+
+ dtb at 180000 {
+ label = "device tree";
+ reg = <0x180000 0x80000>;
+ };
+
+ kernel at 200000 {
+ label = "kernel";
+ reg = <0x200000 0x600000>;
+ };
+
+ rootfs at 800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ d2 {
+ label = "d2";
+ gpios = <&pioE 25 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
new file mode 100644
index 0000000..252e0d3
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
@@ -0,0 +1,301 @@
+/*
+ * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include "sama5d3xcm_cmp.dtsi"
+
+/ {
+ compatible = "atmel,sama5d3xmb-cmp", "atmel,sama5d3xcm-cmp", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ mmc0: mmc at f0000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ spi0: spi at f0004000 {
+ dmas = <0>, <0>; /* Do not use DMA for spi0 */
+
+ m25p80 at 0 {
+ compatible = "atmel,at25df321a";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ };
+ };
+
+ ssc0: ssc at f0008000 {
+ atmel,clk-from-rk-pin;
+ };
+
+ /*
+ * i2c0 conflicts with ISI:
+ * disable it to allow the use of ISI
+ * can not enable audio when i2c0 disabled
+ */
+ i2c0: i2c at f0014000 {
+ wm8904: wm8904 at 1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck0>;
+ clock-names = "mclk";
+ };
+ };
+
+ i2c1: i2c at f0018000 {
+ ov2640: camera at 0x30 {
+ compatible = "ovti,ov2640";
+ reg = <0x30>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
+ resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
+ pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
+ /* use pck1 for the master clock of ov2640 */
+ clocks = <&pck1>;
+ clock-names = "xvclk";
+ assigned-clocks = <&pck1>;
+ assigned-clock-rates = <25000000>;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = <&isi_0>;
+ bus-width = <8>;
+ };
+ };
+ };
+ };
+
+ usart1: serial at f0020000 {
+ dmas = <0>, <0>; /* Do not use DMA for usart1 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+ status = "okay";
+ };
+
+ isi: isi at f0034000 {
+ port {
+ isi_0: endpoint {
+ remote-endpoint = <&ov2640_0>;
+ bus-width = <8>;
+ vsync-active = <1>;
+ hsync-active = <1>;
+ };
+ };
+ };
+
+ mmc1: mmc at f8000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ adc0: adc at f8018000 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ >;
+ pinctrl-1 = <
+ &pinctrl_adc0_adtrg_sleep
+ &pinctrl_adc0_ad0_sleep
+ &pinctrl_adc0_ad1_sleep
+ &pinctrl_adc0_ad2_sleep
+ &pinctrl_adc0_ad3_sleep
+ &pinctrl_adc0_ad4_sleep
+ >;
+ status = "okay";
+ };
+
+ macb1: ethernet at f802c000 {
+ phy-mode = "rmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy at 1 {
+ /*interrupt-parent = <&pioE>;*/
+ /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
+ reg = <1>;
+ };
+ };
+
+ pinctrl at fffff200 {
+ adc0 {
+ pinctrl_adc0_adtrg_sleep: adc0_adtrg_1 {
+ atmel,pins =
+ <AT91_PIOD 19 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
+ };
+ pinctrl_adc0_ad0_sleep: adc0_ad0_1 {
+ atmel,pins =
+ <AT91_PIOD 20 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
+ };
+ pinctrl_adc0_ad1_sleep: adc0_ad1_1 {
+ atmel,pins =
+ <AT91_PIOD 21 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
+ };
+ pinctrl_adc0_ad2_sleep: adc0_ad2_1 {
+ atmel,pins =
+ <AT91_PIOD 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
+ };
+ pinctrl_adc0_ad3_sleep: adc0_ad3_1 {
+ atmel,pins =
+ <AT91_PIOD 23 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
+ };
+ pinctrl_adc0_ad4_sleep: adc0_ad4_1 {
+ atmel,pins =
+ <AT91_PIOD 24 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
+ };
+ };
+
+ board {
+ pinctrl_gpio_keys: gpio_keys {
+ atmel,pins =
+ <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+ };
+
+ pinctrl_mmc1_cd: mmc1_cd {
+ atmel,pins =
+ <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+ };
+
+ pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
+ atmel,pins =
+ <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
+ atmel,pins =
+ <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_sensor_reset: sensor_reset-0 {
+ atmel,pins =
+ <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_sensor_power: sensor_power-0 {
+ atmel,pins =
+ <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+ };
+ };
+
+ dbgu: serial at ffffee00 {
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+ status = "okay";
+ };
+
+ watchdog at fffffe40 {
+ status = "okay";
+ };
+ };
+
+ usb0: gadget at 00500000 {
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ status = "okay";
+ };
+ };
+
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
+
+ atmel,model = "wm8904 @ SAMA5D3EK";
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8904>;
+
+ status = "disabled";
+ };
+
+ /* Conflict with LCD pins */
+ gpio_keys {
+ compatible = "gpio-keys";
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ pb_user1 {
+ label = "pb_user1";
+ gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
+ linux,code = <0x100>;
+ wakeup-source;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* Summary of LPC guest MSI discussion in Santa Fe
From: Jon Masters @ 2016-11-21 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108024559.GA20591@arm.com>
On 11/07/2016 07:45 PM, Will Deacon wrote:
> I figured this was a reasonable post to piggy-back on for the LPC minutes
> relating to guest MSIs on arm64.
Thanks for this Will. I'm still digging out post-LPC and SC16, but the
summary was much appreciated, and I'm glad the conversation is helping.
> 1. The physical memory map is not standardised (Jon pointed out that
> this is something that was realised late on)
Just to note, we discussed this one about 3-4 years ago. I recall making
a vigorous slideshow at a committee meeting in defense of having a
single memory map for ARMv8 servers and requiring everyone to follow it.
I was weak. I listened to the comments that this was "unreasonable".
Instead, I consider it was unreasonable of me to not get with the other
OS vendors and force things to be done one way. The lack of a "map at
zero" RAM location on ARMv8 has been annoying enough for 32-bit DMA only
devices on 64-bit (behind an SMMU but in passthrough mode it doesn't
help) and other issues beyond fixing the MSI doorbell regions. If I ever
have a time machine, I tried harder.
> Jon pointed out that most people are pretty conservative about hardware
> choices when migrating between them -- that is, they may only migrate
> between different revisions of the same SoC, or they know ahead of time
> all of the memory maps they want to support and this could be communicated
> by way of configuration to libvirt.
I think it's certainly reasonable to assume this in an initial
implementation and fix it later. Currently, we're very conservative
about host CPU passthrough anyway and can't migrate from one microarch
to another revision of the same microarch even. And on x86, nobody
really supports e.g. Intel to AMD and back again. I've always been of
the mind that we should ensure the architecture can handle this, but
then cautiously approach this with a default to not doing it.
> Alex asked if there was a security
> issue with DMA bypassing the SMMU, but there aren't currently any systems
> where that is known to happen. Such a system would surely not be safe for
> passthrough.
There are other potential security issues that came up but don't need to
be noted here (yet). I have wanted to clarify the SBSA for a long time
when it comes to how IOMMUs should be implemented. It's past time that
we went back and had a few conversations about that. I've poked.
> Ben mused that a way to handle conflicts dynamically might be to hotplug
> on the entire host bridge in the guest, passing firmware tables describing
> the new reserved regions as a property of the host bridge. Whilst this
> may well solve the issue, it was largely considered future work due to
> its invasive nature and dependency on firmware tables (and guest support)
> that do not currently exist.
Indeed. It's an elegant solution (thanks Ben) that I gather POWER
already does (good for them). We've obviously got a few things to clean
up after we get the basics in place. Again, I think we can consider it
reasonable that the MSI doorbell regions are predetermined on system A
well ahead of any potential migration (that may or may not then work)
for the moment. Vendors will want to loosen this later, and they can
drive the work to do that, for example by hotplugging a host bridge.
Jon.
^ permalink raw reply
* [PATCH] ARM: davinci: Allocate spare interrupts
From: David Lechner @ 2016-11-21 4:20 UTC (permalink / raw)
To: linux-arm-kernel
This allocates spare interrupts for mach-davinci. These extra interrupts
are need for things like IIO triggers that define software interrupts.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/mach-davinci/include/mach/irqs.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/include/mach/irqs.h b/arch/arm/mach-davinci/include/mach/irqs.h
index edb2ca6..2b56bb2 100644
--- a/arch/arm/mach-davinci/include/mach/irqs.h
+++ b/arch/arm/mach-davinci/include/mach/irqs.h
@@ -403,7 +403,9 @@
/* da850 currently has the most gpio pins (144) */
#define DAVINCI_N_GPIO 144
+/* Extra IRQs for things like IIO triggers */
+#define DAVINCI_N_SPARE_IRQ 16
/* da850 currently has the most irqs so use DA850_N_CP_INTC_IRQ */
-#define NR_IRQS (DA850_N_CP_INTC_IRQ + DAVINCI_N_GPIO)
+#define NR_IRQS (DA850_N_CP_INTC_IRQ + DAVINCI_N_GPIO + DAVINCI_N_SPARE_IRQ)
#endif /* __ASM_ARCH_IRQS_H */
--
2.7.4
^ permalink raw reply related
* [PATCH V8 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only
From: Chunyan Zhang @ 2016-11-21 3:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118114523.70b9583f@gandalf.local.home>
On 19 November 2016 at 00:45, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 18 Nov 2016 16:57:53 +0200
> Alexander Shishkin <alexander.shishkin@linux.intel.com> wrote:
>
>> Steven Rostedt <rostedt@goodmis.org> writes:
>>
>> > This looks good to me, although I would like this to go through my tree
>> > (to make sure it gets all my testing). I understand the next two
>> > patches depend on this, how would you want to go about that?
>> >
>> > One is that I can pull it in the next merge window, and the rest go in
>> > after that. Or I can take the other two patches with the proper acks as
>> > well.
>>
>> I just asked for the last patch be split 4 ways, but otherwise, they
>> have my acks. If Chunyan can do that, you can take all of them into your
>> tree.
>>
>
> OK, I'll wait for the split then.
OK, I will split that and send another patch-set with Alex's acks.
Many thanks for the reviews from you two,
Chunyan
>
> Thanks,
>
> -- Steve
^ permalink raw reply
* [PATCH] reset: hisilicon: add a polarity cell for reset line specifier
From: Jiancheng Xue @ 2016-11-21 2:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db839cba-a105-fa8e-8633-c98999cd7316@hisilicon.com>
Hi Philipp,
On 2016/11/16 11:17, Jiancheng Xue wrote:
> Hi Philipp,
>
> On 2016/11/15 18:43, Philipp Zabel wrote:
>> Hi Jiancheng,
>>
>> Am Dienstag, den 15.11.2016, 15:09 +0800 schrieb Jiancheng Xue:
>>> Add a polarity cell for reset line specifier. If the reset line
>>> is asserted when the register bit is 1, the polarity is
>>> normal. Otherwise, it is inverted.
>>>
>>> Signed-off-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
>>> ---
> Thank you very much for replying so soon.
>
> Please allow me to decribe the reason why this patch exists first.
> All bits in the reset controller were designed to be active-high.
> But in a recent chip only one bit was implemented to be active-low :(
>
>>> .../devicetree/bindings/clock/hisi-crg.txt | 11 ++++---
>>> arch/arm/boot/dts/hi3519.dtsi | 2 +-
>>> drivers/clk/hisilicon/reset.c | 36 ++++++++++++++++------
>>> 3 files changed, 33 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/hisi-crg.txt b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>>> index e3919b6..fcbb4f3 100644
>>> --- a/Documentation/devicetree/bindings/clock/hisi-crg.txt
>>> +++ b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>>> @@ -25,19 +25,20 @@ to specify the clock which they consume.
>>>
>>> All these identifier could be found in <dt-bindings/clock/hi3519-clock.h>.
>>>
>>> -- #reset-cells: should be 2.
>>> +- #reset-cells: should be 3.
>>>
>>> A reset signal can be controlled by writing a bit register in the CRG module.
>>> -The reset specifier consists of two cells. The first cell represents the
>>> +The reset specifier consists of three cells. The first cell represents the
>>> register offset relative to the base address. The second cell represents the
>>> -bit index in the register.
>>> +bit index in the register. The third cell represents the polarity of the reset
>>> +line (0 for normal, 1 for inverted).
>>
#reset-cells: Should be 2 if compatilbe string is "hisilicon,hi3519-crg". Should be 3 otherwise.
A reset signal can be controlled by writing a bit register in the CRG module.
The reset specifier consists of two or three cells. The first cell represents the
register offset relative to the base address. The second cell represents the
bit index in the register.The third cell represents the polarity of the reset
line (0 for active-high, 1 for active-low).
If I change the binding like this, can it be accepted?
Regards,
Jiancheng
>> What is normal and what is inverted? Please specify which is active-high
>> and which is active-low.
>>
> OK. I'll use active-high and active-low instead.
>
>>>
>>> Example: CRG nodes
>>> CRG: clock-reset-controller at 12010000 {
>>> compatible = "hisilicon,hi3519-crg";
>>> reg = <0x12010000 0x10000>;
>>> #clock-cells = <1>;
>>> - #reset-cells = <2>;
>>> + #reset-cells = <3>;
>>> };
>>>
>>> Example: consumer nodes
>>> @@ -45,5 +46,5 @@ i2c0: i2c at 12110000 {
>>> compatible = "hisilicon,hi3519-i2c";
>>> reg = <0x12110000 0x1000>;
>>> clocks = <&CRG HI3519_I2C0_RST>;
>>> - resets = <&CRG 0xe4 0>;
>>> + resets = <&CRG 0xe4 0 0>;
>>> };
>>> diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
>>> index 5729ecf..b7cb182 100644
>>> --- a/arch/arm/boot/dts/hi3519.dtsi
>>> +++ b/arch/arm/boot/dts/hi3519.dtsi
>>> @@ -50,7 +50,7 @@
>>> crg: clock-reset-controller at 12010000 {
>>> compatible = "hisilicon,hi3519-crg";
>>> #clock-cells = <1>;
>>> - #reset-cells = <2>;
>>> + #reset-cells = <3>;
>>
>> That is a backwards incompatible change. Which I think in this case
>> could be tolerated, because there are no users yet of the reset
>> controller. Or are there any hi3519 based device trees that use the
>> resets out in the wild? If there are, the driver must continue to
>> support old device trees with two reset-cells. Which would not be
>> trivial because currently the core checks in reset_control_get that
>> rcdev->of_n_reset_cells is equal to the #reset-cells value from DT.
>
^ permalink raw reply
* [PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
From: Caesar Wang @ 2016-11-21 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10151352.zSDKCnp23A@phil>
? 2016?11?15? 00:05, Heiko Stuebner ??:
> Am Mittwoch, 9. November 2016, 21:21:55 CET schrieb Caesar Wang:
>> From: Mark Yao <mark.yao@rock-chips.com>
>>
>> Add the core display-subsystem node and the two display controllers
>> available on the rk3399.
>>
>> Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
>> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
>> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
>> ---
>>
>> Changes in v2: None
>>
>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58
>> ++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index e5b5b3d..f1d289a 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -1290,6 +1290,64 @@
>> status = "disabled";
>> };
>>
>> + vopl: vop at ff8f0000 {
>> + compatible = "rockchip,rk3399-vop-lit";
>> + reg = <0x0 0xff8f0000 0x0 0x3efc>;
>> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> we're usig 4 irq elements nowadays to accomodate the pmus for separate
> clusters, see
>
> https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=210bbd38bb88989ce19208f98e530ff0468f38bd
>
> Same for the edp node.
Ah! Sorry.
>
> Also, sadly the rockchip drm seems to need some tweaks still, as I wasn't
> able to get any display output yet.
>
> To make the vop at least compile I needed to forward-port
> https://github.com/mmind/linux-rockchip/commit/05ad856e54fc1aa1939ad1057897036cedc7fb0b
> https://github.com/mmind/linux-rockchip/commit/0edb1f7e1ac77437a17d7966121ee6e10ab5db67
>
> [full branch is https://github.com/mmind/linux-rockchip/commits/tmp/testing_20161109 ]
Pls allow me to have a look at it and bring up with ChromeOs, the
upstream maybe miss some patches for upstream. (DRM or IOMMU or ....)
I will resend the other patches if I bring up and show display with
upstream on
https://github.com/Caesar-github/rockchip/commits/rk3399/tmp-test
-Caesar
> but I'm not sure if I did that correctly yet and am also still seeing
> nothing on the display and get iommu errors when starting X11
>
>
> Heiko
>
>> + clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
>> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
>> + resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>;
>> + reset-names = "axi", "ahb", "dclk";
>> + iommus = <&vopl_mmu>;
>> + status = "disabled";
>> +
>> + vopl_out: port {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> + };
>> +
>> + vopl_mmu: iommu at ff8f3f00 {
>> + compatible = "rockchip,iommu";
>> + reg = <0x0 0xff8f3f00 0x0 0x100>;
>> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "vopl_mmu";
>> + #iommu-cells = <0>;
>> + status = "disabled";
>> + };
>> +
>> + vopb: vop at ff900000 {
>> + compatible = "rockchip,rk3399-vop-big";
>> + reg = <0x0 0xff900000 0x0 0x3efc>;
>> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
>> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
>> + resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>;
>> + reset-names = "axi", "ahb", "dclk";
>> + iommus = <&vopb_mmu>;
>> + status = "disabled";
>> +
>> + vopb_out: port {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> + };
>> +
>> + vopb_mmu: iommu at ff903f00 {
>> + compatible = "rockchip,iommu";
>> + reg = <0x0 0xff903f00 0x0 0x100>;
>> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "vopb_mmu";
>> + #iommu-cells = <0>;
>> + status = "disabled";
>> + };
>> +
>> + display_subsystem: display-subsystem {
>> + compatible = "rockchip,display-subsystem";
>> + ports = <&vopl_out>, <&vopb_out>;
>> + status = "disabled";
>> + };
>> +
>> pinctrl: pinctrl {
>> compatible = "rockchip,rk3399-pinctrl";
>> rockchip,grf = <&grf>;
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [PATCH v3 10/10] ARM: dts: da850: add usb device node
From: David Lechner @ 2016-11-21 2:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107203948.28324-11-ahaslam@baylibre.com>
On 11/07/2016 02:39 PM, Axel Haslam wrote:
> This adds the ohci device node for the da850 soc.
> It also enables it for the omapl138 hawk board.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
> 2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index 7b8ab21..aaf533e 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -86,6 +86,14 @@
> };
> };
>
> +&usb_phy {
> + status = "okay";
> +};
> +
> +&ohci {
> + status = "okay";
> +};
> +
> &serial2 {
> pinctrl-names = "default";
> pinctrl-0 = <&serial2_rxtx_pins>;
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 2534aab..50e86da 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -405,6 +405,14 @@
> >;
> status = "disabled";
> };
> + ohci: usb at 0225000 {
In commit 2957e36e76c836b167e5e0c1edb578d8a9bd7af6 in the linux-davinci
tree, the alias for the musb device is usb0. So, I think we should use
usb1 here instead of ohci - or change the usb0 alias to musb.
https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/commit/?h=v4.10/dt&id=2957e36e76c836b167e5e0c1edb578d8a9bd7af6
> + compatible = "ti,da830-ohci";
> + reg = <0x225000 0x1000>;
> + interrupts = <59>;
> + phys = <&usb_phy 1>;
> + phy-names = "usb-phy";
> + status = "disabled";
> + };
> gpio: gpio at 226000 {
> compatible = "ti,dm6441-gpio";
> gpio-controller;
>
^ permalink raw reply
* [PATCH V8 3/3] stm: Mark the functions of writing buffer with notrace
From: Chunyan Zhang @ 2016-11-21 2:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <871sy8g83q.fsf@ashishki-desk.ger.corp.intel.com>
On 18 November 2016 at 22:45, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> Chunyan Zhang <zhang.chunyan@linaro.org> writes:
>
>> If CONFIG_STM_SOURCE_FTRACE is selected, Function trace data can be writen
>> to sink via STM, all functions that related to writing data packets to
>> STM should be marked 'notrace' to avoid being traced by Ftrace, otherwise
>> the program would stall into an endless loop.
>>
>> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
>> Acked-by: Steven Rostedt <rostedt@goodmis.org>
>> ---
>> drivers/hwtracing/coresight/coresight-stm.c | 2 +-
>> drivers/hwtracing/intel_th/sth.c | 11 +++++++----
>> drivers/hwtracing/stm/core.c | 7 ++++---
>> drivers/hwtracing/stm/dummy_stm.c | 2 +-
>> include/linux/stm.h | 4 ++--
>> 5 files changed, 15 insertions(+), 11 deletions(-)
>
> Quick nit: can you please split this one in 4: one for Coresight, one
> for Intel TH, one for stm/dummy and one for stm/core?
Sure, will do.
>
> I'd like to keep the bisectability. Otherwise, this is fine by me:
>
> Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Thanks,
Chunyan
>
> Regards,
> --
> Alex
^ permalink raw reply
* [PATCH v2.1 7/9] arm64: dts: rockchip: add pd_edp node for rk3399
From: Caesar Wang @ 2016-11-21 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: zhangqing <zhangqing@rock-chips.com>
This patch adds the below pd_edp information for rk3399.
1. add pd_edp node for RK3399 SoC
2. add the pd support for edp
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
---
Changes in v2.1: (Hope the v3 will fix the display stuff with upstream)
- change the commit message as Doug comments on
https://patchwork.kernel.org/patch/9419241
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index db72033..7354c63 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -838,6 +838,10 @@
};
/* These power domains are grouped by VD_LOGIC */
+ pd_edp at RK3399_PD_EDP {
+ reg = <RK3399_PD_EDP>;
+ clocks = <&cru PCLK_EDP_CTRL>;
+ };
pd_emmc at RK3399_PD_EMMC {
reg = <RK3399_PD_EMMC>;
clocks = <&cru ACLK_EMMC>;
@@ -1388,6 +1392,7 @@
status = "disabled";
pinctrl-names = "default";
pinctrl-0 = <&edp_hpd>;
+ power-domains = <&power RK3399_PD_EDP>;
ports {
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support
From: Ondřej Jirman @ 2016-11-21 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479641523.git.moinejf@free.fr>
Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
> This patchset series adds HDMI video support to the Allwinner
> sun8i SoCs which include the display engine 2 (DE2).
> The driver contains the code for the A83T and H3, but it could be
> used/extended for other SoCs as the A64, H2 and H5.
Hi,
I'm trying to test your patches on Orange Pi PC, and I've run into a few
issues: (I'm using sunxi-ng with the same patches as last time, to make
it work with your driver)
1] I just get pink output on the monitor - there's some signal, but it's
pink (or more like magenta).
dmesg ouput indicates no error:
[ 1.887823] [drm] Initialized
[ 1.888503] sun8i-de2 1000000.de-controller: bound
1c0c000.lcd-controller (ops 0xc0a63894)
[ 2.057298] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops
0xc0a63b54)
[ 2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.057307] [drm] No driver support for vblank timestamp query.
[ 2.690862] Console: switching to colour frame buffer device 240x67
[ 2.723059] sun8i-de2 1000000.de-controller: fb0: frame buffer device
>
> v6:
> - remove audio support (other patchset to come)
> - use DRM modeset data for HDMI configuration
> (thanks to Jernej ?krabec)
> - more meaningfull register names
> - use a mutex for DE I/O protection
> - merge DE and plane into one file
> - don't activate the video hardware when video not started
> (Maxime Ripard)
> - remove 'type = "video" in DT graph ports
> (Rob Herring)
> - change the I/O accesses by #define instead of struct
> (Maxime Ripard, Andr? Przywara)
> - remove pm functions (Maxime Ripard)
> - set the pll-de/de clocks in the DT (Maxime Ripard)
This change triggers this dmesg output I suppose:
[ 0.000000] bad: scheduling from the idle thread!
[ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.9.0-rc6-00045-g5347f96 #29
[ 0.000000] Hardware name: Allwinner sun8i Family
[ 0.000000] [<c010dc64>] (unwind_backtrace) from [<c010ae7c>]
(show_stack+0x10/0x14)
[ 0.000000] [<c010ae7c>] (show_stack) from [<c04d3ce0>]
(dump_stack+0x84/0x98)
[ 0.000000] [<c04d3ce0>] (dump_stack) from [<c0149984>]
(dequeue_task_idle+0x34/0x40)
[ 0.000000] [<c0149984>] (dequeue_task_idle) from [<c0950b54>]
(__schedule+0x244/0x52c)
[ 0.000000] [<c0950b54>] (__schedule) from [<c0950eac>]
(schedule+0x44/0x9c)
[ 0.000000] [<c0950eac>] (schedule) from [<c0953e58>]
(schedule_hrtimeout_range_clock+0xc4/0x138)
[ 0.000000] [<c0953e58>] (schedule_hrtimeout_range_clock) from
[<c0953ee4>] (schedule_hrtimeout_range+0x18/0x20)
[ 0.000000] [<c0953ee4>] (schedule_hrtimeout_range) from [<c0953c40>]
(usleep_range+0x4c/0x54)
[ 0.000000] [<c0953c40>] (usleep_range) from [<c052c4f0>]
(ccu_helper_wait_for_lock+0x58/0xc8)
[ 0.000000] [<c052c4f0>] (ccu_helper_wait_for_lock) from [<c052dd10>]
(ccu_nm_set_rate+0x124/0x148)
[ 0.000000] [<c052dd10>] (ccu_nm_set_rate) from [<c052547c>]
(clk_change_rate+0x194/0x248)
[ 0.000000] [<c052547c>] (clk_change_rate) from [<c0525598>]
(clk_core_set_rate_nolock+0x68/0xb0)
[ 0.000000] [<c0525598>] (clk_core_set_rate_nolock) from [<c0525b58>]
(clk_set_rate+0x20/0x30)
[ 0.000000] [<c0525b58>] (clk_set_rate) from [<c0529f84>]
(of_clk_set_defaults+0x1fc/0x334)
[ 0.000000] [<c0529f84>] (of_clk_set_defaults) from [<c0526dac>]
(of_clk_add_hw_provider+0x74/0x9c)
[ 0.000000] [<c0526dac>] (of_clk_add_hw_provider) from [<c052c608>]
(sunxi_ccu_probe+0xa8/0x130)
[ 0.000000] [<c052c608>] (sunxi_ccu_probe) from [<c0c197dc>]
(of_clk_init+0x15c/0x1e8)
[ 0.000000] [<c0c197dc>] (of_clk_init) from [<c0c08390>]
(sun6i_timer_init+0xc/0x18)
[ 0.000000] [<c0c08390>] (sun6i_timer_init) from [<c0c00bb8>]
(start_kernel+0x248/0x398)
[ 0.000000] [<c0c00bb8>] (start_kernel) from [<4000807c>] (0x4000807c)
[ 0.000000] arm_arch_timer: Architected cp15 timer(s) running at
24.00MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:179
sched_clock_register+0x44/0x1dc
[ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.9.0-rc6-00045-g5347f96 #29
[ 0.000000] Hardware name: Allwinner sun8i Family
[ 0.000000] [<c010dc64>] (unwind_backtrace) from [<c010ae7c>]
(show_stack+0x10/0x14)
[ 0.000000] [<c010ae7c>] (show_stack) from [<c04d3ce0>]
(dump_stack+0x84/0x98)
[ 0.000000] [<c04d3ce0>] (dump_stack) from [<c012087c>]
(__warn+0xe0/0xfc)
[ 0.000000] [<c012087c>] (__warn) from [<c0120948>]
(warn_slowpath_null+0x20/0x28)
[ 0.000000] [<c0120948>] (warn_slowpath_null) from [<c0c0be20>]
(sched_clock_register+0x44/0x1dc)
[ 0.000000] [<c0c0be20>] (sched_clock_register) from [<c0c23be4>]
(arch_timer_common_init+0x204/0x22c)
[ 0.000000] [<c0c23be4>] (arch_timer_common_init) from [<c0c23ef0>]
(arch_timer_of_init+0x2e4/0x310)
[ 0.000000] [<c0c23ef0>] (arch_timer_of_init) from [<c0c232c0>]
(clocksource_probe+0x58/0xac)
[ 0.000000] [<c0c232c0>] (clocksource_probe) from [<c0c00bb8>]
(start_kernel+0x248/0x398)
[ 0.000000] [<c0c00bb8>] (start_kernel) from [<4000807c>] (0x4000807c)
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000004] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps
every 4398046511097ns
[ 0.000010] Switching to timer-based delay loop, resolution 41ns
[ 0.000139] clocksource: timer: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 79635851949 ns
[ 0.000244] ------------[ cut here ]------------
[ 0.000253] WARNING: CPU: 0 PID: 0 at init/main.c:576
start_kernel+0x27c/0x398
[ 0.000255] Interrupts were enabled early
[ 0.000261] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W
4.9.0-rc6-00045-g5347f96 #29
[ 0.000263] Hardware name: Allwinner sun8i Family
[ 0.000273] [<c010dc64>] (unwind_backtrace) from [<c010ae7c>]
(show_stack+0x10/0x14)
[ 0.000283] [<c010ae7c>] (show_stack) from [<c04d3ce0>]
(dump_stack+0x84/0x98)
[ 0.000290] [<c04d3ce0>] (dump_stack) from [<c012087c>]
(__warn+0xe0/0xfc)
[ 0.000296] [<c012087c>] (__warn) from [<c01208d0>]
(warn_slowpath_fmt+0x38/0x48)
[ 0.000303] [<c01208d0>] (warn_slowpath_fmt) from [<c0c00bec>]
(start_kernel+0x27c/0x398)
[ 0.000309] [<c0c00bec>] (start_kernel) from [<4000807c>] (0x4000807c)
[ 0.000314] ---[ end trace f68728a0d3053b52 ]---
[ 0.000383] Console: colour dummy device 80x30
[ 0.000395] console [tty1] enabled
Which can be fixed by:
diff --git a/drivers/clk/sunxi-ng/ccu_common.c
b/drivers/clk/sunxi-ng/ccu_common.c
index 51d4bac..9dc970f 100644
--- a/drivers/clk/sunxi-ng/ccu_common.c
+++ b/drivers/clk/sunxi-ng/ccu_common.c
@@ -30,8 +30,8 @@ void ccu_helper_wait_for_lock(struct ccu_common
*common, u32 lock)
if (!lock)
return;
- WARN_ON(readl_relaxed_poll_timeout(common->base + common->reg, reg,
- reg & lock, 100, 70000));
+ WARN_ON(readl_relaxed_poll_timeout_atomic(common->base + common->reg, reg,
+ reg & lock, 5, 70000));
}
int sunxi_ccu_probe(struct device_node *node, void __iomem *reg,
But I'm not sure that's a good approach in general. This is a sunxi-ng
ccu issue, rather than an issue with your patches. Maxime, any ideas?
regards,
Ondrej
> - use platform_get_irq instead of irq_of_parse_and_map
> (Maxime Ripard)
> - rename sunxi to sun8i (Maxime Ripard)
> - fix coding style errors (Maxime Ripard)
> - subclass the drm structure in private data (Daniel Vetter)
> - move drm_dev_register at end of init (Daniel Vetter)
> v5:
> - add overlay plane
> - add audio support
> - add support for the A83T
> - add back the HDMI driver
> - many bug fixes
> v4:
> - drivers/clk/sunxi/Makefile was missing (Emil Velikov)
> v3:
> - add the hardware cursor
> - simplify and fix the DE2 init sequences
> - generation for all SUNXI SoCs (Andre Przywara)
> v2:
> - remove the HDMI driver
> - remarks from Chen-Yu Tsai and Russell King
> - DT documentation added
>
> Jean-Francois Moine (5):
> drm: sun8i: Add a basic DRM driver for Allwinner DE2
> drm: sunxi: add HDMI video support to A83T and H3
> ARM: dts: sun8i-h3: add HDMI video nodes
> ARM: dts: sun8i-h3: Add HDMI video to the Banana Pi M2+
> ARM: dts: sun8i-h3: Add HDMI video to the Orange PI 2
>
> .../devicetree/bindings/display/sunxi/hdmi.txt | 53 ++
> .../bindings/display/sunxi/sun8i-de2.txt | 83 ++
> arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 13 +
> arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 13 +
> arch/arm/boot/dts/sun8i-h3.dtsi | 51 ++
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/sun8i/Kconfig | 26 +
> drivers/gpu/drm/sun8i/Makefile | 9 +
> drivers/gpu/drm/sun8i/de2_crtc.c | 440 +++++++++++
> drivers/gpu/drm/sun8i/de2_crtc.h | 50 ++
> drivers/gpu/drm/sun8i/de2_drm.h | 48 ++
> drivers/gpu/drm/sun8i/de2_drv.c | 379 ++++++++++
> drivers/gpu/drm/sun8i/de2_hdmi.c | 394 ++++++++++
> drivers/gpu/drm/sun8i/de2_hdmi.h | 51 ++
> drivers/gpu/drm/sun8i/de2_hdmi_io.c | 839 +++++++++++++++++++++
> drivers/gpu/drm/sun8i/de2_plane.c | 712 +++++++++++++++++
> 17 files changed, 3164 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
> create mode 100644 drivers/gpu/drm/sun8i/Kconfig
> create mode 100644 drivers/gpu/drm/sun8i/Makefile
> create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.h
> create mode 100644 drivers/gpu/drm/sun8i/de2_drm.h
> create mode 100644 drivers/gpu/drm/sun8i/de2_drv.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.h
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi_io.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_plane.c
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/cc391cb7/attachment.sig>
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-20 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87h974apmd.fsf@free-electrons.com>
Hello Gregory,
On Fri, Nov 18, 2016 at 02:23:22PM +0100, Gregory CLEMENT wrote:
> What is the status for this patch?
>
> I see that there is still email about the RFC version.
right, I'm preparing a v3, so don't pick up v2.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161120/51c93337/attachment.sig>
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-20 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479586147.10840.0@smtp.gmail.com>
Hello Tomas,
On Sat, Nov 19, 2016 at 09:09:07PM +0100, tomas.hlavacek at nic.cz wrote:
> On Mon, Nov 14, 2016 at 9:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > Interrupts don't seem to work very well with the nxp,pca9538. Which
> > is probably why it is disabled by default.
>
> I was thinking about this issue and I can remember that there was an earlier
> prototype that had a shared interrupt line from PHY (88E1514) and from the
> PCA9538. In this case we needed to specifically disable the interrupt of the
> PHY to release the interrupt line (which needed a hack into PHY driver
> code). The IRQ from PHY is connected as an ordinary input to PCA9538 in
> later board prototype. And the same holds for the production version.
That would explain why I see an "irq but nobody cared" message when
booting the original system.
This isn't the problem I meant though. When adding interrupt-parent =
<&pcawan>; interrupts = <7 IRQ_TYPE_LEVEL_LOW>; to the phy node I get an
error saying that there is no irq domain associated with this device.
> Do you have CZ11NIC13 or older board revision?
CZ11NIC12 is indicated on my board.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161120/6ded9bfe/attachment.sig>
^ permalink raw reply
* [PATCH] arm: spin one more cycle in timer-based delays
From: Mason @ 2016-11-20 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120194439.GY1041@n2100.armlinux.org.uk>
On 20/11/2016 20:44, Russell King - ARM Linux wrote:
> On Sun, Nov 20, 2016 at 11:18:48AM -0800, Doug Anderson wrote:
>
>> On Sat, Nov 19, 2016 at 10:29 AM, Mason <slash.tmp@free.fr> wrote:
>>
>>> OK, so loop-based delays are known to be short. Would you or Linus
>>> accept a patch that adds a X% cushion *in the implementation* ?
>>>
>>> You are saying "people shouldn't expect udelay(10) to delay at least
>>> 10 ?s, thus they should write udelay(10+N)".
>>>
>>> Why not hide that implementation detail inside the implementation,
>>> so as not to force the pessimization on every other implementation
>>> behind the udelay/ndelay wrapper?
>
> Try sending Linus a patch for it.
OK, I will.
BTW, any reason why you replied to me via Doug's reply?
Are my messages not reaching your server?
Regards.
^ permalink raw reply
* [RFC PATCH v2 2/2] macb: Enable 1588 support in SAMA5D2 platform.
From: Richard Cochran @ 2016-11-20 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479478912-14067-2-git-send-email-andrei.pistirica@microchip.com>
On Fri, Nov 18, 2016 at 03:21:52PM +0100, Andrei Pistirica wrote:
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index d975882..eb66b76 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -697,6 +697,8 @@ static void macb_tx_interrupt(struct macb_queue *queue)
>
> /* First, update TX stats if needed */
> if (skb) {
> + macb_ptp_do_txstamp(bp, skb);
This is in the hot path, and so you should have an inline wrapper that
tests (bp->hwts_tx_en) and THEN calls into macb_ptp.c
In case PTP isn't configured, then the inline wrapper should be empty.
> netdev_vdbg(bp->dev, "skb %u (data %p) TX complete\n",
> macb_tx_ring_wrap(tail), skb->data);
> bp->stats.tx_packets++;
> @@ -853,6 +855,8 @@ static int gem_rx(struct macb *bp, int budget)
> GEM_BFEXT(RX_CSUM, ctrl) & GEM_RX_CSUM_CHECKED_MASK)
> skb->ip_summed = CHECKSUM_UNNECESSARY;
>
> + macb_ptp_do_rxstamp(bp, skb);
Same here.
> bp->stats.rx_packets++;
> bp->stats.rx_bytes += skb->len;
>
> @@ -1946,6 +1950,8 @@ static int macb_open(struct net_device *dev)
>
> netif_tx_start_all_queues(dev);
>
> + macb_ptp_init(dev);
This leaks PHC instances starting the second time that the interface goes up!
> return 0;
> }
>
> @@ -2204,7 +2210,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
> .get_regs_len = macb_get_regs_len,
> .get_regs = macb_get_regs,
> .get_link = ethtool_op_get_link,
> - .get_ts_info = ethtool_op_get_ts_info,
> + .get_ts_info = macb_get_ts_info,
You enable the time stamping logic unconditionally here ...
> .get_ethtool_stats = gem_get_ethtool_stats,
> .get_strings = gem_get_ethtool_strings,
> .get_sset_count = gem_get_sset_count,
> @@ -2221,7 +2227,14 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> if (!phydev)
> return -ENODEV;
>
> - return phy_mii_ioctl(phydev, rq, cmd);
> + switch (cmd) {
> + case SIOCSHWTSTAMP:
> + return macb_hwtst_set(dev, rq, cmd);
> + case SIOCGHWTSTAMP:
> + return macb_hwtst_get(dev, rq);
and here.
Is that logic always available on every MACB device? If so, is the
implementation also identical?
Thanks,
Richard
^ permalink raw reply
* [PATCH] arm: spin one more cycle in timer-based delays
From: Russell King - ARM Linux @ 2016-11-20 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WQCfpvVrn64LjxfeG2S7peU5ZWKVGsRyU83-zNCVZmxg@mail.gmail.com>
On Sun, Nov 20, 2016 at 11:18:48AM -0800, Doug Anderson wrote:
> Hi,
>
> On Sat, Nov 19, 2016 at 10:29 AM, Mason <slash.tmp@free.fr> wrote:
> >> Exactly - and the reason for that (as I've explained several times in
> >> the past) the "standard" software delay loop calibrated against the
> >> timer interrupt is _always_ going to be short.
> >
> > OK, so loop-based delays are known to be short. Would you or Linus
> > accept a patch that adds a X% cushion *in the implementation* ?
> >
> > You are saying "people shouldn't expect udelay(10) to delay at least
> > 10 ?s, thus they should write udelay(10+N)".
> >
> > Why not hide that implementation detail inside the implementation,
> > so as not to force the pessimization on every other implementation
> > behind the udelay/ndelay wrapper?
Try sending Linus a patch for it.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFC PATCH v2 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-11-20 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479478912-14067-1-git-send-email-andrei.pistirica@microchip.com>
On Fri, Nov 18, 2016 at 03:21:51PM +0100, Andrei Pistirica wrote:
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> +void macb_ptp_init(struct net_device *ndev);
> +#else
> +void macb_ptp_init(struct net_device *ndev) { }
static inline ^^^
> +#endif
> +void macb_ptp_init(struct net_device *ndev)
> +{
> + struct macb *bp = netdev_priv(ndev);
> + struct timespec64 now;
> + u32 rem = 0;
> +
> + if (!(bp->caps | MACB_CAPS_GEM_HAS_PTP)){
> + netdev_vdbg(bp->dev, "Platform does not support PTP!\n");
> + return;
> + }
You would have needed '&' and not '|' here.
Also, using a flag limits the code to your platform. This works for
you, but it is short sighted. The other MACB PTP blocks have
different register layouts, and this patch does not lay the ground
work for the others.
The driver needs to be designed to support the other platforms.
Thanks,
Richard
^ permalink raw reply
* [PATCH v2 5/5] ARM: s5pv210_defconfig: Remove old MACHs
From: Krzysztof Kozlowski @ 2016-11-20 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479669895-19124-1-git-send-email-krzk@kernel.org>
Remove non-existing MACH symbols from S5PV210 defconfig.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/configs/s5pv210_defconfig | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/configs/s5pv210_defconfig b/arch/arm/configs/s5pv210_defconfig
index fa989902236d..c51f0f02012b 100644
--- a/arch/arm/configs/s5pv210_defconfig
+++ b/arch/arm/configs/s5pv210_defconfig
@@ -9,10 +9,6 @@ CONFIG_ARCH_S5PV210=y
CONFIG_S3C_LOWLEVEL_UART_PORT=1
CONFIG_S3C_DEV_FB=y
CONFIG_S5PV210_SETUP_FB_24BPP=y
-CONFIG_MACH_AQUILA=y
-CONFIG_MACH_GONI=y
-CONFIG_MACH_SMDKC110=y
-CONFIG_MACH_SMDKV210=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_VMSPLIT_2G=y
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/5] ASoC: samsung: Enable COMPILE_TEST for entire Samsung ASoc
From: Krzysztof Kozlowski @ 2016-11-20 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479669895-19124-1-git-send-email-krzk@kernel.org>
Instead of build time, Samsung ASoC drivers have rather runtime
dependency on Exynos or other Samsung platforms. For building they
require Common Clock Framework. If it is provided they could be compile
tested to increase build coverage.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
sound/soc/samsung/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 426ef1c7b265..a6cc6ca93fa7 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -1,6 +1,7 @@
menuconfig SND_SOC_SAMSUNG
tristate "ASoC support for Samsung"
- depends on (PLAT_SAMSUNG || ARCH_EXYNOS)
+ depends on PLAT_SAMSUNG || ARCH_EXYNOS || COMPILE_TEST
+ depends on COMMON_CLK
select SND_SOC_GENERIC_DMAENGINE_PCM
---help---
Say Y or M if you want to add support for codecs attached to
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/5] ASoC: samsung: Enable COMPILE_TEST for SmartQ and WM8580
From: Krzysztof Kozlowski @ 2016-11-20 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479669895-19124-1-git-send-email-krzk@kernel.org>
The I2S sound drivers for SmartQ board and WM8580 codec can be compile
tested to increase build coverage.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
sound/soc/samsung/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index ea0fa9971a0c..426ef1c7b265 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -49,7 +49,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750
config SND_SOC_SAMSUNG_SMDK_WM8580
tristate "SoC I2S Audio support for WM8580 on SMDK"
- depends on MACH_SMDK6410
+ depends on MACH_SMDK6410 || COMPILE_TEST
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_I2S
@@ -109,7 +109,8 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380
config SND_SOC_SMARTQ
tristate "SoC I2S Audio support for SmartQ board"
- depends on MACH_SMARTQ && I2C
+ depends on MACH_SMARTQ || COMPILE_TEST
+ depends on I2C
select SND_SAMSUNG_I2S
select SND_SOC_WM8750
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox