* [sample] A sample program for MRS emulation
From: Suzuki K Poulose @ 2016-11-30 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480518901-18544-1-git-send-email-suzuki.poulose@arm.com>
Here is a sample program which demonstrates how to use mrs
emulation to fetch the ID registers.
----8>----
/*
* Sample program to demonstrate the MRS emulation
* ABI.
* Copyright (C) 2015-2016, ARM Ltd
*
* Author: Suzuki K Poulose <suzuki.poulose@arm.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.
*
* This program 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.
* 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.
*
* This program 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.
*/
#include <stdio.h>
#define get_cpu_ftr(id) ({ \
unsigned long long __val; \
asm("mrs %0, "#id : "=r" (__val)); \
printf("%-20s: 0x%016lx\n", #id, __val); \
})
int main()
{
get_cpu_ftr(ID_AA64ISAR0_EL1);
get_cpu_ftr(ID_AA64ISAR1_EL1);
get_cpu_ftr(ID_AA64MMFR0_EL1);
get_cpu_ftr(ID_AA64MMFR1_EL1);
get_cpu_ftr(ID_AA64PFR0_EL1);
get_cpu_ftr(ID_AA64PFR1_EL1);
get_cpu_ftr(ID_AA64DFR0_EL1);
get_cpu_ftr(ID_AA64DFR1_EL1);
get_cpu_ftr(MIDR_EL1);
get_cpu_ftr(MPIDR_EL1);
get_cpu_ftr(REVIDR_EL1);
return 0;
}
^ permalink raw reply
* [PATCH v2 2/5] spi: armada-3700: Add support for the FIFO mode
From: Gregory CLEMENT @ 2016-11-30 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130094351.2748-3-romain.perier@free-electrons.com>
Hi Romain,
On mer., nov. 30 2016, Romain Perier <romain.perier@free-electrons.com> wrote:
> In FIFO mode, dedicated registers are used to store the instruction,
> the address, the read mode and the data. Write and Read FIFO are used
> to store the outcoming or incoming data. The CPU no longer has to assert
> each byte. The data FIFOs are accessible via DMA or by the CPU.
>
> This commit adds support for the FIFO mode with the CPU.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
>
> Changes in v2:
> - Removed a3700_spi_bytelen_set from the setup function, it was accidentally
> let here and not required, as it is configured in the prepare callback now
> (defaults to 4 for fifo mode). It solves unrecognized spi-nor flash memory
> detection with jedec.
>
> drivers/spi/spi-armada-3700.c | 409 ++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 399 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/spi/spi-armada-3700.c b/drivers/spi/spi-armada-3700.c
> index cc9e1b2..72f1818 100644
> --- a/drivers/spi/spi-armada-3700.c
> +++ b/drivers/spi/spi-armada-3700.c
> @@ -99,19 +99,28 @@
> /* A3700_SPI_IF_TIME_REG */
> #define A3700_SPI_CLK_CAPT_EDGE BIT(7)
>
> +/* Flags and macros for struct a3700_spi */
> +#define HAS_FIFO BIT(0)
> +#define A3700_INSTR_CNT 1
> +#define A3700_ADDR_CNT 3
> +#define A3700_DUMMY_CNT 1
> +
> struct a3700_spi {
> struct spi_master *master;
> void __iomem *base;
> struct clk *clk;
> unsigned int irq;
> unsigned int flags;
> - bool last_xfer;
> + bool xmit_data;
> const u8 *tx_buf;
> u8 *rx_buf;
> size_t buf_len;
> u8 byte_len;
> u32 wait_mask;
> struct completion done;
> + u32 addr_cnt;
> + u32 instr_cnt;
> + size_t hdr_cnt;
> };
>
> static u32 spireg_read(struct a3700_spi *a3700_spi, u32 offset)
> @@ -180,12 +189,15 @@ static int a3700_spi_pin_mode_set(struct a3700_spi *a3700_spi,
> return 0;
> }
>
> -static void a3700_spi_fifo_mode_unset(struct a3700_spi *a3700_spi)
> +static void a3700_spi_fifo_mode_set(struct a3700_spi *a3700_spi)
> {
> u32 val;
>
> val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> - val &= ~A3700_SPI_FIFO_MODE;
> + if (a3700_spi->flags & HAS_FIFO)
> + val |= A3700_SPI_FIFO_MODE;
> + else
> + val &= ~A3700_SPI_FIFO_MODE;
> spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> }
>
> @@ -255,11 +267,30 @@ static void a3700_spi_bytelen_set(struct a3700_spi *a3700_spi, unsigned int len)
> a3700_spi->byte_len = len;
> }
>
> +static int a3700_spi_fifo_flush(struct a3700_spi *a3700_spi)
> +{
> + int timeout = A3700_SPI_TIMEOUT;
> + u32 val;
> +
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val |= A3700_SPI_FIFO_FLUSH;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> +
> + while (--timeout) {
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + if (!(val & A3700_SPI_FIFO_FLUSH))
> + return 0;
> + udelay(1);
> + }
> +
> + return -ETIMEDOUT;
> +}
> +
> static int a3700_spi_init(struct a3700_spi *a3700_spi)
> {
> struct spi_master *master = a3700_spi->master;
> u32 val;
> - int i;
> + int i, ret = 0;
>
> /* Reset SPI unit */
> val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> @@ -278,10 +309,8 @@ static int a3700_spi_init(struct a3700_spi *a3700_spi)
> for (i = 0; i < master->num_chipselect; i++)
> a3700_spi_deactivate_cs(a3700_spi, i);
>
> - a3700_spi_pin_mode_set(a3700_spi, 0);
> -
> - /* Be sure that FIFO mode is disabled */
> - a3700_spi_fifo_mode_unset(a3700_spi);
> + /* Enable FIFO mode */
> + a3700_spi_fifo_mode_set(a3700_spi);
>
> /* Set SPI mode */
> a3700_spi_mode_set(a3700_spi, master->mode_bits);
> @@ -294,7 +323,7 @@ static int a3700_spi_init(struct a3700_spi *a3700_spi)
> spireg_write(a3700_spi, A3700_SPI_INT_MASK_REG, 0);
> spireg_write(a3700_spi, A3700_SPI_INT_STAT_REG, ~0U);
>
> - return 0;
> + return ret;
> }
>
> static irqreturn_t a3700_spi_interrupt(int irq, void *dev_id)
> @@ -380,14 +409,34 @@ static bool a3700_spi_transfer_wait(struct spi_device *spi,
> return a3700_spi_wait_completion(spi);
> }
>
> +static void a3700_spi_fifo_thres_set(struct a3700_spi *a3700_spi,
> + unsigned int bytes)
> +{
> + u32 val;
> +
> + if (a3700_spi->flags & HAS_FIFO) {
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val &= ~(A3700_SPI_FIFO_THRS_MASK << A3700_SPI_RFIFO_THRS_BIT);
> + val |= (bytes - 1) << A3700_SPI_RFIFO_THRS_BIT;
> + val &= ~(A3700_SPI_FIFO_THRS_MASK << A3700_SPI_WFIFO_THRS_BIT);
> + val |= (7 - bytes) << A3700_SPI_WFIFO_THRS_BIT;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> + }
> +}
> +
> static void a3700_spi_transfer_setup(struct spi_device *spi,
> struct spi_transfer *xfer)
> {
> struct a3700_spi *a3700_spi;
> + unsigned int byte_len;
>
> a3700_spi = spi_master_get_devdata(spi->master);
>
> a3700_spi_clock_set(a3700_spi, xfer->speed_hz, spi->mode);
> +
> + byte_len = xfer->bits_per_word >> 3;
> +
> + a3700_spi_fifo_thres_set(a3700_spi, byte_len);
> }
>
> static int a3700_spi_read_data(struct a3700_spi *a3700_spi)
> @@ -447,6 +496,168 @@ static void a3700_spi_set_cs(struct spi_device *spi, bool enable)
> a3700_spi_deactivate_cs(a3700_spi, spi->chip_select);
> }
>
> +static void a3700_spi_header_set(struct a3700_spi *a3700_spi)
> +{
> + u32 instr_cnt = 0, addr_cnt = 0, dummy_cnt = 0;
> + u32 val = 0;
> +
> + /* Clear the header registers */
> + spireg_write(a3700_spi, A3700_SPI_IF_INST_REG, 0);
> + spireg_write(a3700_spi, A3700_SPI_IF_ADDR_REG, 0);
> + spireg_write(a3700_spi, A3700_SPI_IF_RMODE_REG, 0);
> +
> + /* Set header counters */
> + if (a3700_spi->tx_buf) {
> + if (a3700_spi->buf_len <= a3700_spi->instr_cnt) {
> + instr_cnt = a3700_spi->buf_len;
> + } else if (a3700_spi->buf_len <= (a3700_spi->instr_cnt +
> + a3700_spi->addr_cnt)) {
> + instr_cnt = a3700_spi->instr_cnt;
> + addr_cnt = a3700_spi->buf_len - instr_cnt;
> + } else if (a3700_spi->buf_len <= a3700_spi->hdr_cnt) {
> + instr_cnt = a3700_spi->instr_cnt;
> + addr_cnt = a3700_spi->addr_cnt;
> + /* Need to handle the normal write case with 1 byte
> + * data
> + */
> + if (!a3700_spi->tx_buf[instr_cnt + addr_cnt])
> + dummy_cnt = a3700_spi->buf_len - instr_cnt -
> + addr_cnt;
> + }
> + val |= ((instr_cnt & A3700_SPI_INSTR_CNT_MASK)
> + << A3700_SPI_INSTR_CNT_BIT);
> + val |= ((addr_cnt & A3700_SPI_ADDR_CNT_MASK)
> + << A3700_SPI_ADDR_CNT_BIT);
> + val |= ((dummy_cnt & A3700_SPI_DUMMY_CNT_MASK)
> + << A3700_SPI_DUMMY_CNT_BIT);
> + }
> + spireg_write(a3700_spi, A3700_SPI_IF_HDR_CNT_REG, val);
> +
> + /* Update the buffer length to be transferred */
> + a3700_spi->buf_len -= (instr_cnt + addr_cnt + dummy_cnt);
> +
> + /* Set Instruction */
> + val = 0;
> + while (instr_cnt--) {
> + val = (val << 8) | a3700_spi->tx_buf[0];
> + a3700_spi->tx_buf++;
> + }
> + spireg_write(a3700_spi, A3700_SPI_IF_INST_REG, val);
> +
> + /* Set Address */
> + val = 0;
> + while (addr_cnt--) {
> + val = (val << 8) | a3700_spi->tx_buf[0];
> + a3700_spi->tx_buf++;
> + }
> + spireg_write(a3700_spi, A3700_SPI_IF_ADDR_REG, val);
> +}
> +
> +static int a3700_is_wfifo_full(struct a3700_spi *a3700_spi)
> +{
> + u32 val;
> +
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CTRL_REG);
> + return (val & A3700_SPI_WFIFO_FULL);
> +}
> +
> +static int a3700_spi_fifo_write(struct a3700_spi *a3700_spi)
> +{
> + u32 val;
> + int i = 0;
> +
> + while (!a3700_is_wfifo_full(a3700_spi) && a3700_spi->buf_len) {
> + val = 0;
> + if (a3700_spi->buf_len >= 4) {
> + val = cpu_to_le32(*(u32 *)a3700_spi->tx_buf);
> + spireg_write(a3700_spi, A3700_SPI_DATA_OUT_REG, val);
> +
> + a3700_spi->buf_len -= 4;
> + a3700_spi->tx_buf += 4;
> + } else {
> + /*
> + * If the remained buffer length is less than 4-bytes,
> + * we should pad the write buffer with all ones. So that
> + * it avoids overwrite the unexpected bytes following
> + * the last one.
> + */
> + val = GENMASK(31, 0);
> + while (a3700_spi->buf_len) {
> + val &= ~(0xff << (8 * i));
> + val |= *a3700_spi->tx_buf++ << (8 * i);
> + i++;
> + a3700_spi->buf_len--;
> +
> + spireg_write(a3700_spi, A3700_SPI_DATA_OUT_REG,
> + val);
> + }
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int a3700_is_rfifo_empty(struct a3700_spi *a3700_spi)
> +{
> + u32 val = spireg_read(a3700_spi, A3700_SPI_IF_CTRL_REG);
> +
> + return (val & A3700_SPI_RFIFO_EMPTY);
> +}
> +
> +static int a3700_spi_fifo_read(struct a3700_spi *a3700_spi)
> +{
> + u32 val;
> +
> + while (!a3700_is_rfifo_empty(a3700_spi) && a3700_spi->buf_len) {
> + val = spireg_read(a3700_spi, A3700_SPI_DATA_IN_REG);
> + if (a3700_spi->buf_len >= 4) {
> + u32 data = le32_to_cpu(val);
> + memcpy(a3700_spi->rx_buf, &data, 4);
> +
> + a3700_spi->buf_len -= 4;
> + a3700_spi->rx_buf += 4;
> + } else {
> + /*
> + * When remain bytes is not larger than 4, we should
> + * avoid memory overwriting and just write the left rx
> + * buffer bytes.
> + */
> + while (a3700_spi->buf_len) {
> + *a3700_spi->rx_buf = val & 0xff;
> + val >>= 8;
> +
> + a3700_spi->buf_len--;
> + a3700_spi->rx_buf++;
> + }
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void a3700_spi_transfer_abort_fifo(struct a3700_spi *a3700_spi)
> +{
> + int timeout = A3700_SPI_TIMEOUT;
> + u32 val;
> +
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val |= A3700_SPI_XFER_STOP;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> +
> + while (--timeout) {
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + if (!(val & A3700_SPI_XFER_START))
> + break;
> + udelay(1);
> + }
> +
> + a3700_spi_fifo_flush(a3700_spi);
> +
> + val &= ~A3700_SPI_XFER_STOP;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> +}
> +
> static int a3700_spi_prepare_message(struct spi_master *master,
> struct spi_message *message)
> {
> @@ -463,12 +674,28 @@ static int a3700_spi_prepare_message(struct spi_master *master,
> return 0;
> }
>
> +static int a3700_spi_prepare_fifo_message(struct spi_master *master,
> + struct spi_message *message)
> +{
> + struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
> + int ret;
> +
> + /* Flush the FIFOs */
> + ret = a3700_spi_fifo_flush(a3700_spi);
> + if (ret)
> + return ret;
> +
> + a3700_spi_bytelen_set(a3700_spi, 4);
> +
> + return 0;
> +}
> +
> static int a3700_spi_transfer_one(struct spi_master *master,
> struct spi_device *spi,
> struct spi_transfer *xfer)
> {
> struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
> - int ret = 0;
> + int ret;
>
> a3700_spi_transfer_setup(spi, xfer);
>
> @@ -505,6 +732,151 @@ static int a3700_spi_transfer_one(struct spi_master *master,
> return ret;
> }
>
> +static int a3700_spi_fifo_transfer_one(struct spi_master *master,
> + struct spi_device *spi,
> + struct spi_transfer *xfer)
> +{
> + struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
> + int ret = 0, timeout = A3700_SPI_TIMEOUT;
> + unsigned int nbits = 0;
> + u32 val;
> +
> + a3700_spi_transfer_setup(spi, xfer);
> +
> + a3700_spi->tx_buf = xfer->tx_buf;
> + a3700_spi->rx_buf = xfer->rx_buf;
> + a3700_spi->buf_len = xfer->len;
> +
> + /* SPI transfer headers */
> + a3700_spi_header_set(a3700_spi);
> +
> + if (xfer->tx_buf)
> + nbits = xfer->tx_nbits;
> + else if (xfer->rx_buf)
> + nbits = xfer->rx_nbits;
> +
> + a3700_spi_pin_mode_set(a3700_spi, nbits);
> +
> + if (xfer->rx_buf) {
> + /* Set read data length */
> + spireg_write(a3700_spi, A3700_SPI_IF_DIN_CNT_REG,
> + a3700_spi->buf_len);
> + /* Start READ transfer */
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val &= ~A3700_SPI_RW_EN;
> + val |= A3700_SPI_XFER_START;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> + } else if (xfer->tx_buf) {
> + /* Start Write transfer */
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val |= (A3700_SPI_XFER_START | A3700_SPI_RW_EN);
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> +
> + /*
> + * If there are data to be written to the SPI device, xmit_data
> + * flag is set true; otherwise the instruction in SPI_INSTR does
> + * not require data to be written to the SPI device, then
> + * xmit_data flag is set false.
> + */
> + a3700_spi->xmit_data = (a3700_spi->buf_len != 0);
> + }
> +
> + while (a3700_spi->buf_len) {
> + if (a3700_spi->tx_buf) {
> + /* Wait wfifo ready */
> + if (!a3700_spi_transfer_wait(spi,
> + A3700_SPI_WFIFO_RDY)) {
> + dev_err(&spi->dev,
> + "wait wfifo ready timed out\n");
> + ret = -ETIMEDOUT;
> + goto error;
> + }
> + /* Fill up the wfifo */
> + ret = a3700_spi_fifo_write(a3700_spi);
> + if (ret)
> + goto error;
> + } else if (a3700_spi->rx_buf) {
> + /* Wait rfifo ready */
> + if (!a3700_spi_transfer_wait(spi,
> + A3700_SPI_RFIFO_RDY)) {
> + dev_err(&spi->dev,
> + "wait rfifo ready timed out\n");
> + ret = -ETIMEDOUT;
> + goto error;
> + }
> + /* Drain out the rfifo */
> + ret = a3700_spi_fifo_read(a3700_spi);
> + if (ret)
> + goto error;
> + }
> + }
> +
> + /*
> + * Stop a write transfer in fifo mode:
> + * - wait all the bytes in wfifo to be shifted out
> + * - set XFER_STOP bit
> + * - wait XFER_START bit clear
> + * - clear XFER_STOP bit
> + * Stop a read transfer in fifo mode:
> + * - the hardware is to reset the XFER_START bit
> + * after the number of bytes indicated in DIN_CNT
> + * register
> + * - just wait XFER_START bit clear
> + */
> + if (a3700_spi->tx_buf) {
> + if (a3700_spi->xmit_data) {
> + /*
> + * If there are data written to the SPI device, wait
> + * until SPI_WFIFO_EMPTY is 1 to wait for all data to
> + * transfer out of write FIFO.
> + */
> + if (!a3700_spi_transfer_wait(spi,
> + A3700_SPI_WFIFO_EMPTY)) {
> + dev_err(&spi->dev, "wait wfifo empty timed out\n");
> + return -ETIMEDOUT;
> + }
> + } else {
> + /*
> + * If the instruction in SPI_INSTR does not require data
> + * to be written to the SPI device, wait until SPI_RDY
> + * is 1 for the SPI interface to be in idle.
> + */
> + if (!a3700_spi_transfer_wait(spi, A3700_SPI_XFER_RDY)) {
> + dev_err(&spi->dev, "wait xfer ready timed out\n");
> + return -ETIMEDOUT;
> + }
> + }
> +
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val |= A3700_SPI_XFER_STOP;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> + }
> +
> + while (--timeout) {
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + if (!(val & A3700_SPI_XFER_START))
> + break;
> + udelay(1);
> + }
> +
> + if (timeout == 0) {
> + dev_err(&spi->dev, "wait transfer start clear timed out\n");
> + ret = -ETIMEDOUT;
> + goto error;
> + }
> +
> + val &= ~A3700_SPI_XFER_STOP;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> + goto out;
> +
> +error:
> + a3700_spi_transfer_abort_fifo(a3700_spi);
> +out:
> + spi_finalize_current_transfer(master);
> +
> + return ret;
> +}
> +
> static int a3700_spi_unprepare_message(struct spi_master *master,
> struct spi_message *message)
> {
> @@ -592,6 +964,23 @@ static int a3700_spi_probe(struct platform_device *pdev)
> goto error;
> }
>
> + if (of_device_is_compatible(of_node, "marvell,armada-3700-spi"))
> {
I don't understand this test. Given the a3700_spi_dt_ids value, the
probe can only be called if the compatible is
"marvell,armada-3700-spi". So this test seems not needed and the "else"
part is never reached.
It seems you wanted to make the FIFO feature optional. But is there any
drawback with FIFO mode ? If not you can just make it the default mode
and remove the 3 functions: a3700_spi_prepare_message(),
a3700_spi_transfer_one() and a3700_spi_unprepare_message(). And if there
is an interest to have the non-FIFO mode then you should use a module
parameter for it.
Gregory
> + master->prepare_message = a3700_spi_prepare_fifo_message;
> + master->transfer_one = a3700_spi_fifo_transfer_one;
> +
> + spi->flags |= HAS_FIFO;
> + spi->instr_cnt = A3700_INSTR_CNT;
> + spi->addr_cnt = A3700_ADDR_CNT;
> + spi->hdr_cnt = A3700_INSTR_CNT + A3700_ADDR_CNT +
> + A3700_DUMMY_CNT;
> + master->mode_bits |= (SPI_RX_DUAL | SPI_RX_DUAL |
> + SPI_RX_QUAD | SPI_TX_QUAD);
> + } else {
> + master->prepare_message = a3700_spi_prepare_message;
> + master->transfer_one = a3700_spi_transfer_one;
> + master->unprepare_message = a3700_spi_unprepare_message;
> + }
> +
> ret = a3700_spi_init(spi);
> if (ret)
> goto error_clk;
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [git pull] soc_device_match() interface for matching against soc_bus attributes
From: Arnd Bergmann @ 2016-11-30 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479904376-12453-1-git-send-email-geert+renesas@glider.be>
On Wednesday, November 23, 2016 1:32:56 PM CET Geert Uytterhoeven wrote:
> soc_device_match() interface for matching against soc_bus attributes
>
> This provides core infrastructure as a dependency for several users
> (Freescale/NXP, Samsung, Renesas).
>
> Its core parts have been acked by Greg, and the fixes by Arnd and/or
> Greg (the last fix only received an informal ack, that's why I hadn't
> added the ack).
>
> This has already been pulled by Ulf, and is present in mmc/next, as a
> dependency for a Freescale/NXP driver update.
>
>
I've pulled this into next/drivers and also into a separate
next/socdevice-match that we can use for keeping track. Thanks,
Arnd
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC r8a7745 SYSC Driver Updates for v4.10
From: Arnd Bergmann @ 2016-11-30 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479929914.git.horms+renesas@verge.net.au>
On Wednesday, November 23, 2016 9:13:10 PM CET Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC r8a7745 SYSC Driver updates for
> v4.10.
>
> This pull request is based on v4.9-rc1.
>
> This pull request is broken out of an earlier pull request,
> "Second Round of Renesas ARM Based SoC Drivers Updates for v4.10".
> The motivation for breaking up the pull request is to provide
> branches with minimal dependencies.
>
> This pull request is targeted at the next/drivers branch of the arm-soc tree.
>
> It introduces some minor merge conflicts in:
> Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
> drivers/soc/renesas/Makefile
> drivers/soc/renesas/rcar-sysc.c
> drivers/soc/renesas/rcar-sysc.h
> The resolution is to take both sides. A sample merge resolution is
> provided in the renesas-next-20161123v2-v4.9-rc1 tag of the renesas tree.
>
Pulled into next/drivers, thanks!
Arnd
diff --cc Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
index c16ec18,1375758..d91715b
--- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
+++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
@@@ -7,7 -7,7 +7,8 @@@ and various coprocessors
Required properties:
- compatible: Must contain exactly one of the following:
+ - "renesas,r8a7743-sysc" (RZ/G1M)
+ - "renesas,r8a7745-sysc" (RZ/G1E)
- "renesas,r8a7779-sysc" (R-Car H1)
- "renesas,r8a7790-sysc" (R-Car H2)
- "renesas,r8a7791-sysc" (R-Car M2-W)
diff --cc drivers/soc/renesas/Makefile
index 9e0bb32,a25a628..e2249f0
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@@ -1,4 -1,4 +1,5 @@@
+obj-$(CONFIG_ARCH_R8A7743) += rcar-sysc.o r8a7743-sysc.o
+ obj-$(CONFIG_ARCH_R8A7745) += rcar-sysc.o r8a7745-sysc.o
obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
obj-$(CONFIG_ARCH_R8A7791) += rcar-sysc.o r8a7791-sysc.o
diff --cc drivers/soc/renesas/rcar-sysc.c
index 71acd45,a4e1bb0..225c35c
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@@ -275,9 -275,9 +275,12 @@@ finalize
}
static const struct of_device_id rcar_sysc_matches[] = {
+#ifdef CONFIG_ARCH_R8A7743
+ { .compatible = "renesas,r8a7743-sysc", .data = &r8a7743_sysc_info },
+#endif
+ #ifdef CONFIG_ARCH_R8A7745
+ { .compatible = "renesas,r8a7745-sysc", .data = &r8a7745_sysc_info },
+ #endif
#ifdef CONFIG_ARCH_R8A7779
{ .compatible = "renesas,r8a7779-sysc", .data = &r8a7779_sysc_info },
#endif
diff --cc drivers/soc/renesas/rcar-sysc.h
index 8ab9ca8,3048dd3..f6e842e
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@@ -50,7 -50,7 +50,8 @@@ struct rcar_sysc_info
unsigned int num_areas;
};
+extern const struct rcar_sysc_info r8a7743_sysc_info;
+ extern const struct rcar_sysc_info r8a7745_sysc_info;
extern const struct rcar_sysc_info r8a7779_sysc_info;
extern const struct rcar_sysc_info r8a7790_sysc_info;
extern const struct rcar_sysc_info r8a7791_sysc_info;
^ permalink raw reply
* [PATCH v6 2/4] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Gregory CLEMENT @ 2016-11-30 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130140017.26307-3-romain.perier@free-electrons.com>
Hi Romain,
On mer., nov. 30 2016, Romain Perier <romain.perier@free-electrons.com> wrote:
> The Armada 3700 has two I2C controllers that is compliant with the I2C
> Bus Specificiation 2.1, supports multi-master and different bus speed:
> Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
> High speed mode (up to 3.4 Mhz).
>
> This IP block has a lot of similarity with the PXA, except some register
> offsets and bitfield. This commits adds a basic support for this I2C
> unit.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
As the code had changed I tested it agin and it continues to work, so
you can keep my Tested-by.
However I have a small remark, see below:
> ---
>
> Changes in v6:
> - Revert back A3700_REGS, as asked by Wolfram and define fm_mask
> and hs_mask in the register layout. I moved the generic code
> for fm_mask and hs_mask to a seperated commit (1/4)
>
> Changes in v5:
> - Don't define registers for armada-3700, we can re-use the ones
> for PXA3XX.
> - Define registers mask when OF is not used, in probe_pdata.
>
> Changes in v4:
> - Replaced the type of hs_mask and fm_mask by u32, instead of
> unsigned int, As writel() take an u32 as first argument...
>
> Changes in v3:
> - Replaced the type of hs_mask and fm_mask by unsigned int,
> instead of unsigned long.
>
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/i2c/busses/i2c-pxa.c | 15 +++++++++++++++
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index d252276..2f56a26 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -763,7 +763,7 @@ config I2C_PUV3
>
> config I2C_PXA
> tristate "Intel PXA2XX I2C adapter"
> - depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
> + depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
> help
> If you have devices in the PXA I2C bus, say yes to this option.
> This driver can also be built as a module. If so, the module
Maybe you could add that this driver is no longer only for the PXA
family but also for the Armada 37xx.
Gregory
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index dc9d0a6..0ded4bc 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -57,8 +57,12 @@ enum pxa_i2c_types {
> REGS_PXA3XX,
> REGS_CE4100,
> REGS_PXA910,
> + REGS_A3700,
> };
>
> +#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
> +#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
> +
> /*
> * I2C registers definitions
> */
> @@ -93,6 +97,15 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
> .ilcr = 0x28,
> .iwcr = 0x30,
> },
> + [REGS_A3700] = {
> + .ibmr = 0x00,
> + .idbr = 0x04,
> + .icr = 0x08,
> + .isr = 0x0c,
> + .isar = 0x10,
> + .fm = ICR_BUSMODE_FM,
> + .hs = ICR_BUSMODE_HS,
> + },
> };
>
> static const struct platform_device_id i2c_pxa_id_table[] = {
> @@ -100,6 +113,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
> { "pxa3xx-pwri2c", REGS_PXA3XX },
> { "ce4100-i2c", REGS_CE4100 },
> { "pxa910-i2c", REGS_PXA910 },
> + { "armada-3700-i2c", REGS_A3700 },
> { },
> };
> MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
> @@ -1141,6 +1155,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
> { .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
> { .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
> { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
> + { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
> {}
> };
> MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 0/4] drm: Add support for the Amlogic Video Processing Unit
From: Neil Armstrong @ 2016-11-30 15:43 UTC (permalink / raw)
To: linux-arm-kernel
This a repost of the previous version at [2] with fixes, the following patches will
be sent via a PULL Request once the DT maintainers acks the DT bindings.
The Amlogic maintainer will take the arm64 DT patches to avoid merges conflicts.
The Amlogic Meson SoCs embeds a Video Processing Unit able to output at least
a Composite/CVBS Video with embedded VDAC and an HDMI Link with Embedded HDMI
Transceiver.
Thus, the current driver does not support HDMI yet.
The Video Processig Unit is composed of multiple modules like the Video
Input Unit and the Video Post Processing that can be associated to a
CRTC with Planes management.
The last Unit is the Venc that embeds at least 3 Encoders, ENCI for Interlace
Video used by CVBS or HDMI, ENCP for Progressive Video used by the HDMI
Transceiver and ENCL for LCD Display.
The LCD Display is not planned to be supported on the Meson GX Family.
This driver is a DRM/KMS driver using the following DRM components :
- GEM-CMA
- PRIME-CMA
- Atomic Modesetting
- FBDev-CMA
For the following SoCs :
- GXBB Family (S905)
- GXL Family (S905X, S905D)
- GXM Family (S912)
The current driver only supports the CVBS PAL/NTSC output modes, but the
CRTC/Planes management should support bigger modes.
But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
a second time.
The Device Tree bindings makes use of the endpoints video interface definitions
to connect to the optional CVBS and in the future the HDMI Connector nodes.
The driver has been tested with Xorg modesetting driver and Weston DRM backend.
Changes since v1 at [2] :
- Simplify bindings to have a "composite-video-connector" to represent the on-board composite connector
- Remove the component_match binding since it's unused for now
- Moved all DRM connector code back in the venc_cvbs file
- Check for port endpoints validity to detech connector existence
- Added Daniel Vetter's ack on non-dt patches commit messages
Changes since RFC at [1] :
- Add maintainers entry
- Move all Plane and CRTC code from backend to corresponding DRM code
- Keep only init and common code in backend source files
- Move the CVBS encoder out of the CVBS DT node, only keep the connector
- Various cleanups using DRM helpers
- Cleanup of copyright headers
- Fixup of bindings documentation
[1] http://lkml.kernel.org/r/1480089791-12517-1-git-send-email-narmstrong at baylibre.com
[2] http://lkml.kernel.org/r/1480416469-9655-1-git-send-email-narmstrong at baylibre.com
Neil Armstrong (4):
drm: Add support for Amlogic Meson Graphic Controller
ARM64: dts: meson-gx: Add Graphic Controller nodes
dt-bindings: display: add Amlogic Meson DRM Bindings
MAINTAINERS: add entry for Amlogic DRM drivers
.../bindings/display/meson/meson-drm.txt | 101 ++
MAINTAINERS | 9 +
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 +
.../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 +
.../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 +
.../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/meson/Kconfig | 9 +
drivers/gpu/drm/meson/Makefile | 4 +
drivers/gpu/drm/meson/meson_canvas.c | 68 +
drivers/gpu/drm/meson/meson_canvas.h | 42 +
drivers/gpu/drm/meson/meson_crtc.c | 208 +++
drivers/gpu/drm/meson/meson_crtc.h | 32 +
drivers/gpu/drm/meson/meson_drv.c | 343 +++++
drivers/gpu/drm/meson/meson_drv.h | 60 +
drivers/gpu/drm/meson/meson_plane.c | 230 ++++
drivers/gpu/drm/meson/meson_plane.h | 30 +
drivers/gpu/drm/meson/meson_registers.h | 1395 ++++++++++++++++++++
drivers/gpu/drm/meson/meson_vclk.c | 167 +++
drivers/gpu/drm/meson/meson_vclk.h | 34 +
drivers/gpu/drm/meson/meson_venc.c | 254 ++++
drivers/gpu/drm/meson/meson_venc.h | 72 +
drivers/gpu/drm/meson/meson_venc_cvbs.c | 293 ++++
drivers/gpu/drm/meson/meson_venc_cvbs.h | 41 +
drivers/gpu/drm/meson/meson_viu.c | 331 +++++
drivers/gpu/drm/meson/meson_viu.h | 64 +
drivers/gpu/drm/meson/meson_vpp.c | 162 +++
drivers/gpu/drm/meson/meson_vpp.h | 35 +
33 files changed, 4078 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/meson/meson-drm.txt
create mode 100644 drivers/gpu/drm/meson/Kconfig
create mode 100644 drivers/gpu/drm/meson/Makefile
create mode 100644 drivers/gpu/drm/meson/meson_canvas.c
create mode 100644 drivers/gpu/drm/meson/meson_canvas.h
create mode 100644 drivers/gpu/drm/meson/meson_crtc.c
create mode 100644 drivers/gpu/drm/meson/meson_crtc.h
create mode 100644 drivers/gpu/drm/meson/meson_drv.c
create mode 100644 drivers/gpu/drm/meson/meson_drv.h
create mode 100644 drivers/gpu/drm/meson/meson_plane.c
create mode 100644 drivers/gpu/drm/meson/meson_plane.h
create mode 100644 drivers/gpu/drm/meson/meson_registers.h
create mode 100644 drivers/gpu/drm/meson/meson_vclk.c
create mode 100644 drivers/gpu/drm/meson/meson_vclk.h
create mode 100644 drivers/gpu/drm/meson/meson_venc.c
create mode 100644 drivers/gpu/drm/meson/meson_venc.h
create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.c
create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.h
create mode 100644 drivers/gpu/drm/meson/meson_viu.c
create mode 100644 drivers/gpu/drm/meson/meson_viu.h
create mode 100644 drivers/gpu/drm/meson/meson_vpp.c
create mode 100644 drivers/gpu/drm/meson/meson_vpp.h
--
1.9.1
^ permalink raw reply
* [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-11-30 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-1-git-send-email-narmstrong@baylibre.com>
Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
boards.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 +++++++++++++++++++
.../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
8 files changed, 91 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fc033c0..a27f881 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -356,5 +356,24 @@
status = "disabled";
};
};
+
+ vpu: vpu at d0100000 {
+ compatible = "amlogic,meson-gx-vpu";
+ reg = <0x0 0xd0100000 0x0 0x100000>,
+ <0x0 0xc883c000 0x0 0x1000>,
+ <0x0 0xc8838000 0x0 0x1000>;
+ reg-names = "vpu", "hhi", "dmc";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* CVBS VDAC output port */
+ port at 0 {
+ reg = <0>;
+
+ cvbs_vdac_out: endpoint {
+ };
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 9696820..390f7db 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -142,6 +142,17 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
&uart_AO {
@@ -229,3 +240,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 203be28..44bdebf 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -125,6 +125,17 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -234,3 +245,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index ac5ad3b..5353a20 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -506,3 +506,7 @@
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
};
+
+&vpu {
+ compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index e99101a..7bd0538 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -117,6 +117,17 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
&uart_AO {
@@ -203,3 +214,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 9f89b99..5c7a8fa 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -299,3 +299,7 @@
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
};
+
+&vpu {
+ compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index d320727..5b99749 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -90,6 +90,17 @@
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -167,3 +178,7 @@
max-speed = <1000>;
};
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
index c1974bb..eb2f0c3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
@@ -112,3 +112,7 @@
};
};
};
+
+&vpu {
+ compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-1-git-send-email-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/display/meson/meson-drm.txt | 101 +++++++++++++++++++++
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/meson/meson-drm.txt
diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
new file mode 100644
index 0000000..e52869a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
@@ -0,0 +1,101 @@
+Amlogic Meson Display Controller
+================================
+
+The Amlogic Meson Display controller is composed of several components
+that are going to be documented below:
+
+DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
+ | vd1 _______ _____________ _________________ | |
+D |-------| |----| | | | | HDMI PLL |
+D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
+R |-------| |----| Processing | | | | |
+ | osd2 | | | |---| Enci ----------|----|-----VDAC------|
+R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
+A | osd1 | | | Blenders | | Encl ----------|----|---------------|
+M |-------|______|----|____________| |________________| | |
+___|__________________________________________________________|_______________|
+
+
+VIU: Video Input Unit
+---------------------
+
+The Video Input Unit is in charge of the pixel scanout from the DDR memory.
+It fetches the frames addresses, stride and parameters from the "Canvas" memory.
+This part is also in charge of the CSC (Colorspace Conversion).
+It can handle 2 OSD Planes and 2 Video Planes.
+
+VPP: Video Post Processing
+--------------------------
+
+The Video Post Processing is in charge of the scaling and blending of the
+various planes into a single pixel stream.
+There is a special "pre-blending" used by the video planes with a dedicated
+scaler and a "post-blending" to merge with the OSD Planes.
+The OSD planes also have a dedicated scaler for one of the OSD.
+
+VENC: Video Encoders
+--------------------
+
+The VENC is composed of the multiple pixel encoders :
+ - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
+ - ENCP : Progressive Video Encoder for HDMI
+ - ENCL : LCD LVDS Encoder
+The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
+tree and provides the scanout clock to the VPP and VIU.
+The ENCI is connected to a single VDAC for Composite Output.
+The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
+
+Device Tree Bindings:
+---------------------
+
+VPU: Video Processing Unit
+--------------------------
+
+Required properties:
+- compatible: value should be different for each SoC family as :
+ - GXBB (S905) : "amlogic,meson-gxbb-vpu"
+ - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
+ - GXM (S912) : "amlogic,meson-gxm-vpu"
+ followed by the common "amlogic,meson-gx-vpu"
+- reg: base address and size of he following memory-mapped regions :
+ - vpu
+ - hhi
+ - dmc
+- reg-names: should contain the names of the previous memory regions
+- interrupts: should contain the VENC Vsync interrupt number
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ The first port should be connected to a CVBS connector endpoint if available.
+
+Example:
+
+tv: connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ tv_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+};
+
+vpu: vpu at d0100000 {
+ compatible = "amlogic,meson-gxbb-vpu";
+ reg = <0x0 0xd0100000 0x0 0x100000>,
+ <0x0 0xc883c000 0x0 0x1000>,
+ <0x0 0xc8838000 0x0 0x1000>;
+ reg-names = "vpu", "hhi", "dmc";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* CVBS VDAC output port */
+ port at 0 {
+ cvbs_vdac_out: endpoint {
+ reg = <0>;
+ remote-endpoint = <&tv_connector_in>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 4/4] MAINTAINERS: add entry for Amlogic DRM drivers
From: Neil Armstrong @ 2016-11-30 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-1-git-send-email-narmstrong@baylibre.com>
Add myself as maintainer for Amlogic DRM drivers.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..b2486fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4078,6 +4078,15 @@ S: Supported
F: drivers/gpu/drm/sun4i/
F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+DRM DRIVERS FOR AMLOGIC SOCS
+M: Neil Armstrong <narmstrong@baylibre.com>
+L: dri-devel at lists.freedesktop.org
+L: linux-amlogic at lists.infradead.org
+W: http://linux-meson.com/
+S: Supported
+F: drivers/gpu/drm/meson/
+F: Documentation/devicetree/bindings/display/meson/meson-drm.txt
+
DRM DRIVERS FOR EXYNOS
M: Inki Dae <inki.dae@samsung.com>
M: Joonyoung Shim <jy0922.shim@samsung.com>
--
1.9.1
^ permalink raw reply related
* [git pull] Renesas RZ/G1M and RZ/G1E CPG Core Clock Definitions
From: Arnd Bergmann @ 2016-11-30 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479904798-12768-1-git-send-email-geert+renesas@glider.be>
On Wednesday, November 23, 2016 1:39:58 PM CET Geert Uytterhoeven wrote:
> Renesas RZ/G1M and RZ/G1E CPG Core Clock Definitions
>
> This contains clock definitions shared by clock drivers and DTS files,
> and is provided as a dependency for the latter.
>
> This has already been pulled by Stephen as part of a larger pull
> request, and is present in clk/clk-next, together with the corresponding
> clock drivers.
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL v2] Second Round of Renesas ARM Based SoC DT Updates for v4.10
From: Arnd Bergmann @ 2016-11-30 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479931686.git.horms+renesas@verge.net.au>
On Wednesday, November 23, 2016 9:14:33 PM CET Simon Horman wrote:
> Second Round of Renesas ARM Based SoC DT Updates for v4.10
>
> Enhancements:
> * Add device nodes for PRR
> * Add r8a7745 SoC and sk-rzg1e board
> * Add r8a7743 SoC and sk-rzg1m board
> * Enable SDR-104 and I2C demuxer on alt, koelsch and lager boards
>
> Corrections:
> * Use SYSC "always-on" PM Domain for sound on r8a7794 SoC
> * Correct hsusb parent clock on r8a7794 SoC
> * Correct PFC names for DU on alt board
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH v6 1/4] i2c: pxa: Add definition of fast and high speed modes via the regs layout
From: Thomas Petazzoni @ 2016-11-30 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130140017.26307-2-romain.perier@free-electrons.com>
Hello,
On Wed, 30 Nov 2016 15:00:14 +0100, Romain Perier wrote:
> #ifdef CONFIG_I2C_PXA_SLAVE
> dev_info(&i2c->adap.dev, "Enabling slave mode\n");
> @@ -1234,6 +1238,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
> i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
> i2c->reg_icr = i2c->reg_base + pxa_reg_layout[i2c_type].icr;
> i2c->reg_isr = i2c->reg_base + pxa_reg_layout[i2c_type].isr;
> + i2c->fm_mask = pxa_reg_layout[i2c_type].fm ? pxa_reg_layout[i2c_type].fm : ICR_FM;
> + i2c->hs_mask = pxa_reg_layout[i2c_type].hs ? pxa_reg_layout[i2c_type].hs : ICR_HS;
These lines are too long according to checkpatch. What about using what
Wolfram originally suggested, i.e:
i2c->fm_mask = pxa_reg_layout[i2c_type].fm ?: ICR_FM;
which does exactly the same, but fits within 80 characters ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Match Updates for v4.10
From: Arnd Bergmann @ 2016-11-30 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479928995.git.horms+renesas@verge.net.au>
On Wednesday, November 23, 2016 9:13:31 PM CET Simon Horman wrote:
> This pull request is based on the pull request "soc_device_match()
> interface for matching against soc_bus attributes" sent by Geert
> Uytterhoeven which corresponds to the soc-device-match-tag1 tag in his
> renesas-driver's tree. It provides infrastructure used by changes in this
> pull request.
>
> This pull request is broken out of an earlier pull request,
> "Second Round of Renesas ARM Based SoC Drivers Updates for v4.10".
> The motivation for breaking up the pull request is to provide
> branches with minimal dependencies.
>
> This pull request is targeted at the next/drivers branch of the arm-soc tree.
>
> It introduces some minor merge conflicts in drivers/soc/renesas/Makefile.
> The resolution is to take both sides. A sample merge resolution is
> provided in the renesas-next-20161123v2-v4.9-rc1 tag of the renesas tree.
>
Pulled into next/drivers, thanks!
Arnd
^ permalink raw reply
* [GIT PULL v2] Second Round of Renesas ARM64 Based SoC DT Updates for v4.10
From: Arnd Bergmann @ 2016-11-30 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
On Monday, November 21, 2016 1:05:10 PM CET Simon Horman wrote:
> Second Round of Renesas ARM64 Based SoC DT Updates for v4.10
>
> Enhancements:
> * Add device nodes for PRR
> * Add m3ulcb board
> * Enable I2C on r8a7796/salvator-x board
> * Enable SDHI0 on h3ulcb board
>
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Allwinner arm64 DT changes for 4.10, bis
From: Arnd Bergmann @ 2016-11-30 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122144731.c6q6jxgd7cyeieqr@lukather>
On Tuesday, November 22, 2016 3:47:31 PM CET Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Here is a second run at the arm64 PR I sent earlier.
>
> We had a (build) dependency against the clock patches that have been
> merged by Stephen and Mike through the clock tree.
>
> Hence, this new PR is based on top of the tag I sent their way, and it
> supersedes the previous arm64 PR.
>
> I used this occasion to rename the patches prefix as Olof suggested in
> the earlier pull request.
Just to document what we discussed on IRC: I've dropped this pull
request, as we had already merged the previous one, and some other
patches on top. Instead, I changed the data in the sun50i-a64.dtsi
to reference the clocks and resets by numerical value rather than
by name, which fixes the build.
Arnd
^ permalink raw reply
* [PATCH 2/2] ACPI: Ignore Consumer/Producer for QWord/DWord/Word Address Space
From: Bjorn Helgaas @ 2016-11-30 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130120425.GA13765@red-moon>
On Wed, Nov 30, 2016 at 12:04:25PM +0000, Lorenzo Pieralisi wrote:
> On Tue, Nov 29, 2016 at 12:43:34PM -0600, Bjorn Helgaas wrote:
> > Per ACPI spec r6.0, sec 6.4.3.5.1, 2, 3, Bit [0] of General Flags (the
> > Consumer/Producer bit) should be ignored for QWord/DWord/Word Address Space
> > descriptors. The Consumer/Producer bit is defined only for the Extended
> > Address Space descriptor.
> >
> > Ignore Consumer/Producer except for Extended Address Space descriptors.
> >
> > Note that for QWord/DWord/Word descriptors, we previously applied the
> > translation offset (_TRA) only when the Consumer/Producer bit was set.
>
> "..Consumer/Producer bit was clear" ? If that bit was set:
>
> struct acpi_resource_address->producer_consumer == ACPI_CONSUMER
>
> and we are not applying the _TRA offset in that case, right ?
Right, of course. How about this instead?
Note that for QWord/DWord/Word descriptors, we previously applied the
translation offset (_TRA) only for Producers, i.e., when the Consumer/
Producer bit was clear. This patch changes that: for those descriptors,
we ignore Consumer/Producer and always apply the translation offset.
> > This patch changes that: for those descriptors, we ignore Consumer/Producer
> > and always apply the translation offset.
> >
> > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> > ---
> > drivers/acpi/resource.c | 16 +++++++++++-----
> > 1 file changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> > index 2732d39e..b45cd8f 100644
> > --- a/drivers/acpi/resource.c
> > +++ b/drivers/acpi/resource.c
> > @@ -261,11 +261,16 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> > * primary side. Non-bridge devices must list 0 for all Address
> > * Translation offset bits.
> > */
> > - if (addr->producer_consumer == ACPI_PRODUCER)
> > + if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64) {
> > + if (addr->producer_consumer == ACPI_PRODUCER)
> > + offset = attr->translation_offset;
> > + else if (attr->translation_offset)
> > + pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> > + attr->translation_offset);
> > + } else {
> > offset = attr->translation_offset;
> > - else if (attr->translation_offset)
> > - pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> > - attr->translation_offset);
> > + }
> > +
> > start = attr->minimum + offset;
> > end = attr->maximum + offset;
> >
> > @@ -294,7 +299,8 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> > return false;
> > }
> >
> > - if (addr->producer_consumer == ACPI_PRODUCER)
> > + if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64 &&
> > + addr->producer_consumer == ACPI_PRODUCER)
> > res->flags |= IORESOURCE_WINDOW;
> >
> > if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: defconfig: Do not lower CONFIG_LOG_BUF_SHIFT
From: Arnd Bergmann @ 2016-11-30 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123145508.GK28723@e104818-lin.cambridge.arm.com>
On Wednesday, November 23, 2016 2:55:09 PM CET Catalin Marinas wrote:
> On Wed, Nov 23, 2016 at 02:36:16PM +0100, Geert Uytterhoeven wrote:
> > The default value of 17 for CONFIG_LOG_BUF_SHIFT is much more suitable
> > than 14. The latter easily leads to lost kernel messages on systems with
> > only one CPU core.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Applied on next/arm64, thanks!
Arnd
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-30 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-4-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
> 1 file changed, 101 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>
> diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
> mode 100644
> index 0000000..e52869a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> @@ -0,0 +1,101 @@
> +Amlogic Meson Display Controller
> +================================
> +
> +The Amlogic Meson Display controller is composed of several components
> +that are going to be documented below:
> +
> +DMC|---------------VPU (Video Processing Unit)------------|------HHI------|
> + | vd1 _______ _____________ _____________ | |
> +D |-------| |----| | | | | HDMI PLL |
> +D | vd2 | VIU | | Video Post | | Video Encs |<---|-----VCLK |
> +R |-------| |----| Processing | | | | |
> + | osd2 | | | |---| Enci ------|----|-----VDAC------|
> +R |-------| CSC |----| Scalers | | Encp ------|----|----HDMI-TX----|
> +A | osd1 | | | Blenders | | Encl-------|----|---------------|
> +M |-------|______|----|____________| |____________| | |
> +___|______________________________________________________|_______________|
> +
> +
> +VIU: Video Input Unit
> +---------------------
> +
> +The Video Input Unit is in charge of the pixel scanout from the DDR memory.
> +It fetches the frames addresses, stride and parameters from the "Canvas"
> memory.
> +This part is also in charge of the CSC (Colorspace Conversion).
> +It can handle 2 OSD Planes and 2 Video Planes.
> +
> +VPP: Video Post Processing
> +--------------------------
> +
> +The Video Post Processing is in charge of the scaling and blending of the
> +various planes into a single pixel stream.
> +There is a special "pre-blending" used by the video planes with a dedicated
> +scaler and a "post-blending" to merge with the OSD Planes.
> +The OSD planes also have a dedicated scaler for one of the OSD.
> +
> +VENC: Video Encoders
> +--------------------
> +
> +The VENC is composed of the multiple pixel encoders :
> + - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
> + - ENCP : Progressive Video Encoder for HDMI
> + - ENCL : LCD LVDS Encoder
> +The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and
> clock
> +tree and provides the scanout clock to the VPP and VIU.
> +The ENCI is connected to a single VDAC for Composite Output.
> +The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
> +
> +Device Tree Bindings:
> +---------------------
> +
> +VPU: Video Processing Unit
> +--------------------------
> +
> +Required properties:
> +- compatible: value should be different for each SoC family as :
> + - GXBB (S905) : "amlogic,meson-gxbb-vpu"
> + - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
> + - GXM (S912) : "amlogic,meson-gxm-vpu"
> + followed by the common "amlogic,meson-gx-vpu"
> +- reg: base address and size of he following memory-mapped regions :
> + - vpu
> + - hhi
> + - dmc
> +- reg-names: should contain the names of the previous memory regions
> +- interrupts: should contain the VENC Vsync interrupt number
> +
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + The first port should be connected to a CVBS connector endpoint if
> available.
This is a bit vague, I propose clarifying it with a description similar to the
one in the renesas,du.txt bindings.
Required nodes:
The connections to the VPU output video ports are modeled using the OF graph
bindings specified in Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each DU output.
Port 0 Port1 Port2 Port3
-----------------------------------------------------------------------------
R8A7779 (H1) DPAD 0 DPAD 1 - -
R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
R8A7791 (M2-W) DPAD LVDS 0 - -
R8A7792 (V2H) DPAD 0 DPAD 1 - -
R8A7793 (M2-N) DPAD LVDS 0 - -
R8A7794 (E2) DPAD 0 DPAD 1 - -
R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
R8A7796 (M3-W) DPAD HDMI LVDS -
(You should obviously replace the table with Amlogic data)
It doesn't matter if the current driver implementation only supports CVBS, the
DT bindings can already document the other ports.
> +
> +Example:
> +
> +tv: connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
I'd remove the label here, as it doesn't bring any additional information.
Unless the board you're using has a label for the connector, in case that
label should be used.
Apart from that,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + port {
> + tv_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> +};
> +
> +vpu: vpu at d0100000 {
> + compatible = "amlogic,meson-gxbb-vpu";
> + reg = <0x0 0xd0100000 0x0 0x100000>,
> + <0x0 0xc883c000 0x0 0x1000>,
> + <0x0 0xc8838000 0x0 0x1000>;
> + reg-names = "vpu", "hhi", "dmc";
> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* CVBS VDAC output port */
> + port at 0 {
> + cvbs_vdac_out: endpoint {
> + reg = <0>;
> + remote-endpoint = <&tv_connector_in>;
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [GIT PULL 1/2] SoCFPGA DTS update for v4.10, part 3
From: Arnd Bergmann @ 2016-11-30 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162309.5408-1-dinguyen@kernel.org>
On Monday, November 21, 2016 10:23:08 AM CET Dinh Nguyen wrote:
> SoCFPGA DTS update for v4.10, part 3
> - Fine tune L2 cache configuration
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-30 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-4-git-send-email-narmstrong@baylibre.com>
Hi Neil,
On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
I forgot to mention that the file should not be named meson-drm.txt as DRM is
a Linux-specific concept. You can name it meson.txt, but a better option would
be amlogic,meson.txt. By the way does it really need a subdirectory ?
> 1 file changed, 101 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/meson/meson-drm.txt
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [GIT PULL 2/2] SoCFPGA update for v4.10
From: Arnd Bergmann @ 2016-11-30 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162309.5408-2-dinguyen@kernel.org>
On Monday, November 21, 2016 10:23:09 AM CET Dinh Nguyen wrote:
> SoCFPGA update for v4.10
> - Fixup spelling error
>
Pulled into next/fixes-non-critical, thanks!
Arnd
^ permalink raw reply
* [PATCH v2 4/4] MAINTAINERS: add entry for Amlogic DRM drivers
From: Laurent Pinchart @ 2016-11-30 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-5-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
On Wednesday 30 Nov 2016 16:43:45 Neil Armstrong wrote:
> Add myself as maintainer for Amlogic DRM drivers.
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
After updating this patch due to the rename I proposed in patch 3/4,
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> MAINTAINERS | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1cd38a7..b2486fb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4078,6 +4078,15 @@ S: Supported
> F: drivers/gpu/drm/sun4i/
> F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>
> +DRM DRIVERS FOR AMLOGIC SOCS
> +M: Neil Armstrong <narmstrong@baylibre.com>
> +L: dri-devel at lists.freedesktop.org
> +L: linux-amlogic at lists.infradead.org
> +W: http://linux-meson.com/
> +S: Supported
> +F: drivers/gpu/drm/meson/
> +F: Documentation/devicetree/bindings/display/meson/meson-drm.txt
> +
> DRM DRIVERS FOR EXYNOS
> M: Inki Dae <inki.dae@samsung.com>
> M: Joonyoung Shim <jy0922.shim@samsung.com>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2734274.BAOZxRirYz@avalon>
Hi Laurent,
On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>
> I forgot to mention that the file should not be named meson-drm.txt as DRM is
> a Linux-specific concept. You can name it meson.txt, but a better option would
> be amlogic,meson.txt. By the way does it really need a subdirectory ?
I took example of the sun4i layout the naming, and no it does not need a subdirector..
I will move it to amlogic,meson.txt, seems far better.
Thanks,
Neil
>> 1 file changed, 101 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>
^ permalink raw reply
* [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Laurent Pinchart @ 2016-11-30 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-3-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
On Wednesday 30 Nov 2016 16:43:43 Neil Armstrong wrote:
> Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
> boards.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 ++++++++++++++++
> .../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
> 8 files changed, 91 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi index fc033c0..a27f881 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -356,5 +356,24 @@
> status = "disabled";
> };
> };
> +
> + vpu: vpu at d0100000 {
> + compatible = "amlogic,meson-gx-vpu";
> + reg = <0x0 0xd0100000 0x0 0x100000>,
> + <0x0 0xc883c000 0x0 0x1000>,
> + <0x0 0xc8838000 0x0 0x1000>;
> + reg-names = "vpu", "hhi", "dmc";
> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* CVBS VDAC output port */
> + port at 0 {
> + reg = <0>;
> +
> + cvbs_vdac_out: endpoint {
> + };
Endpoints require a remote-endpoint property. You should move the endpoint to
board DT files.
> + };
> + };
> };
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts index
> 9696820..390f7db 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> @@ -142,6 +142,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
Unless the board has a label for the connector (either on the board, on the
casing or in the user manual) I'd leave this out. Same comment for the other
boards.
Apart from that,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> &uart_AO {
> @@ -229,3 +240,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi index 203be28..44bdebf
> 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -125,6 +125,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -234,3 +245,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index ac5ad3b..5353a20 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -506,3 +506,7 @@
> <&clkc CLKID_FCLK_DIV2>;
> clock-names = "core", "clkin0", "clkin1";
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts index
> e99101a..7bd0538 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> @@ -117,6 +117,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> &uart_AO {
> @@ -203,3 +214,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 9f89b99..5c7a8fa 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -299,3 +299,7 @@
> <&clkc CLKID_FCLK_DIV2>;
> clock-names = "core", "clkin0", "clkin1";
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts index
> d320727..5b99749 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -90,6 +90,17 @@
> compatible = "mmc-pwrseq-emmc";
> reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -167,3 +178,7 @@
> max-speed = <1000>;
> };
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi index c1974bb..eb2f0c3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> @@ -112,3 +112,7 @@
> };
> };
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 1/4] drm: Add support for Amlogic Meson Graphic Controller
From: Laurent Pinchart @ 2016-11-30 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-2-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
I'm afraid I don't have time for a complete review, but could you please get
rid of the of_machine_is_compatible() calls and match on the VPU compatible
string instead ?
On Wednesday 30 Nov 2016 16:43:42 Neil Armstrong wrote:
> The Amlogic Meson Display controller is composed of several components :
>
> DMC|---------------VPU (Video Processing
> Unit)----------------|------HHI------| |
> vd1 _______ _____________ _________________ | |
> D |-------| |----| | | | | HDMI
> PLL | D | vd2 | VIU | | Video Post | | Video Encoders
> |<---|-----VCLK | R |-------| |----| Processing
> | | | | | |
> osd2 | | | |---| Enci ----------|----|-----VDAC------|
> R |-------| CSC |----| Scalers | | Encp
> ----------|----|----HDMI-TX----| A | osd1 | | | Blenders | |
> Encl ----------|----|---------------|
> M |-------|______|----|____________| |________________| |
> |
> ___|__________________________________________________________|____________
> ___|
>
> VIU: Video Input Unit
> ---------------------
>
> The Video Input Unit is in charge of the pixel scanout from the DDR memory.
> It fetches the frames addresses, stride and parameters from the "Canvas"
> memory. This part is also in charge of the CSC (Colorspace Conversion).
> It can handle 2 OSD Planes and 2 Video Planes.
>
> VPP: Video Post Processing
> --------------------------
>
> The Video Post Processing is in charge of the scaling and blending of the
> various planes into a single pixel stream.
> There is a special "pre-blending" used by the video planes with a dedicated
> scaler and a "post-blending" to merge with the OSD Planes.
> The OSD planes also have a dedicated scaler for one of the OSD.
>
> VENC: Video Encoders
> --------------------
>
> The VENC is composed of the multiple pixel encoders :
> - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
> - ENCP : Progressive Video Encoder for HDMI
> - ENCL : LCD LVDS Encoder
> The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
> tree and provides the scanout clock to the VPP and VIU.
> The ENCI is connected to a single VDAC for Composite Output.
> The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
>
> This driver is a DRM/KMS driver using the following DRM components :
> - GEM-CMA
> - PRIME-CMA
> - Atomic Modesetting
> - FBDev-CMA
>
> For the following SoCs :
> - GXBB Family (S905)
> - GXL Family (S905X, S905D)
> - GXM Family (S912)
>
> The current driver only supports the CVBS PAL/NTSC output modes, but the
> CRTC/Planes management should support bigger modes.
> But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
> a second time.
>
> The Device Tree bindings makes use of the endpoints video interface
> definitions to connect to the optional CVBS and in the future the HDMI
> Connector nodes.
>
> HDMI Support is planned for a next release.
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/meson/Kconfig | 9 +
> drivers/gpu/drm/meson/Makefile | 4 +
> drivers/gpu/drm/meson/meson_canvas.c | 68 ++
> drivers/gpu/drm/meson/meson_canvas.h | 42 +
> drivers/gpu/drm/meson/meson_crtc.c | 208 +++++
> drivers/gpu/drm/meson/meson_crtc.h | 32 +
> drivers/gpu/drm/meson/meson_drv.c | 343 ++++++++
> drivers/gpu/drm/meson/meson_drv.h | 60 ++
> drivers/gpu/drm/meson/meson_plane.c | 230 +++++
> drivers/gpu/drm/meson/meson_plane.h | 30 +
> drivers/gpu/drm/meson/meson_registers.h | 1395 ++++++++++++++++++++++++++++
> drivers/gpu/drm/meson/meson_vclk.c | 167 ++++
> drivers/gpu/drm/meson/meson_vclk.h | 34 +
> drivers/gpu/drm/meson/meson_venc.c | 254 ++++++
> drivers/gpu/drm/meson/meson_venc.h | 72 ++
> drivers/gpu/drm/meson/meson_venc_cvbs.c | 293 +++++++
> drivers/gpu/drm/meson/meson_venc_cvbs.h | 41 +
> drivers/gpu/drm/meson/meson_viu.c | 331 ++++++++
> drivers/gpu/drm/meson/meson_viu.h | 64 ++
> drivers/gpu/drm/meson/meson_vpp.c | 162 ++++
> drivers/gpu/drm/meson/meson_vpp.h | 35 +
> 23 files changed, 3877 insertions(+)
> create mode 100644 drivers/gpu/drm/meson/Kconfig
> create mode 100644 drivers/gpu/drm/meson/Makefile
> create mode 100644 drivers/gpu/drm/meson/meson_canvas.c
> create mode 100644 drivers/gpu/drm/meson/meson_canvas.h
> create mode 100644 drivers/gpu/drm/meson/meson_crtc.c
> create mode 100644 drivers/gpu/drm/meson/meson_crtc.h
> create mode 100644 drivers/gpu/drm/meson/meson_drv.c
> create mode 100644 drivers/gpu/drm/meson/meson_drv.h
> create mode 100644 drivers/gpu/drm/meson/meson_plane.c
> create mode 100644 drivers/gpu/drm/meson/meson_plane.h
> create mode 100644 drivers/gpu/drm/meson/meson_registers.h
> create mode 100644 drivers/gpu/drm/meson/meson_vclk.c
> create mode 100644 drivers/gpu/drm/meson/meson_vclk.h
> create mode 100644 drivers/gpu/drm/meson/meson_venc.c
> create mode 100644 drivers/gpu/drm/meson/meson_venc.h
> create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.c
> create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.h
> create mode 100644 drivers/gpu/drm/meson/meson_viu.c
> create mode 100644 drivers/gpu/drm/meson/meson_viu.h
> create mode 100644 drivers/gpu/drm/meson/meson_vpp.c
> create mode 100644 drivers/gpu/drm/meson/meson_vpp.h
--
Regards,
Laurent Pinchart
^ permalink raw reply
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