* Applied "spi: atmel: Use core SPI_MASTER_MUST_[RT]X handling" to the spi tree
From: Mark Brown @ 2016-11-25 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86f613a36c2e7db07c3ec7d0b8a650cdb9222b32.1479985886.git.nicolas.ferre@atmel.com>
The patch
spi: atmel: Use core SPI_MASTER_MUST_[RT]X handling
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7910d9af000acc155745e44be55a5d0dc9e26ce7 Mon Sep 17 00:00:00 2001
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Thu, 24 Nov 2016 12:24:58 +0100
Subject: [PATCH] spi: atmel: Use core SPI_MASTER_MUST_[RT]X handling
We need both RX and TX data for each transfer in any case (PIO, PDC, DMA).
So convert the driver to the core dummy buffer handling with the
SPI_MASTER_MUST_RX/SPI_MASTER_MUST_TX infrastructure.
This move changes the maximum PDC/DMA buffer handling to 65535 bytes
instead of a single page and sets master->max_dma_len to this value.
All dummy buffer management is removed from the driver.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-atmel.c | 131 +++++++++++++-----------------------------------
1 file changed, 35 insertions(+), 96 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index a9ae1836e1e2..8f20d4f75e4a 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -303,10 +303,6 @@ struct atmel_spi {
struct completion xfer_completion;
- /* scratch buffer */
- void *buffer;
- dma_addr_t buffer_dma;
-
struct atmel_spi_caps caps;
bool use_dma;
@@ -327,7 +323,7 @@ struct atmel_spi_device {
u32 csr;
};
-#define BUFFER_SIZE PAGE_SIZE
+#define SPI_MAX_DMA_XFER 65535 /* true for both PDC and DMA */
#define INVALID_DMA_ADDRESS 0xffffffff
/*
@@ -612,14 +608,10 @@ static void atmel_spi_next_xfer_single(struct spi_master *master,
cpu_relax();
}
- if (xfer->tx_buf) {
- if (xfer->bits_per_word > 8)
- spi_writel(as, TDR, *(u16 *)(xfer->tx_buf + xfer_pos));
- else
- spi_writel(as, TDR, *(u8 *)(xfer->tx_buf + xfer_pos));
- } else {
- spi_writel(as, TDR, 0);
- }
+ if (xfer->bits_per_word > 8)
+ spi_writel(as, TDR, *(u16 *)(xfer->tx_buf + xfer_pos));
+ else
+ spi_writel(as, TDR, *(u8 *)(xfer->tx_buf + xfer_pos));
dev_dbg(master->dev.parent,
" start pio xfer %p: len %u tx %p rx %p bitpw %d\n",
@@ -666,17 +658,12 @@ static void atmel_spi_next_xfer_fifo(struct spi_master *master,
/* Fill TX FIFO */
while (num_data >= 2) {
- if (xfer->tx_buf) {
- if (xfer->bits_per_word > 8) {
- td0 = *words++;
- td1 = *words++;
- } else {
- td0 = *bytes++;
- td1 = *bytes++;
- }
+ if (xfer->bits_per_word > 8) {
+ td0 = *words++;
+ td1 = *words++;
} else {
- td0 = 0;
- td1 = 0;
+ td0 = *bytes++;
+ td1 = *bytes++;
}
spi_writel(as, TDR, (td1 << 16) | td0);
@@ -684,14 +671,10 @@ static void atmel_spi_next_xfer_fifo(struct spi_master *master,
}
if (num_data) {
- if (xfer->tx_buf) {
- if (xfer->bits_per_word > 8)
- td0 = *words++;
- else
- td0 = *bytes++;
- } else {
- td0 = 0;
- }
+ if (xfer->bits_per_word > 8)
+ td0 = *words++;
+ else
+ td0 = *bytes++;
spi_writew(as, TDR, td0);
num_data--;
@@ -750,24 +733,14 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
/* prepare the RX dma transfer */
sg_init_table(&as->dma.sgrx, 1);
- if (xfer->rx_buf) {
- as->dma.sgrx.dma_address = xfer->rx_dma + xfer->len - *plen;
- } else {
- as->dma.sgrx.dma_address = as->buffer_dma;
- if (len > BUFFER_SIZE)
- len = BUFFER_SIZE;
- }
+ as->dma.sgrx.dma_address = xfer->rx_dma + xfer->len - *plen;
/* prepare the TX dma transfer */
sg_init_table(&as->dma.sgtx, 1);
- if (xfer->tx_buf) {
- as->dma.sgtx.dma_address = xfer->tx_dma + xfer->len - *plen;
- } else {
- as->dma.sgtx.dma_address = as->buffer_dma;
- if (len > BUFFER_SIZE)
- len = BUFFER_SIZE;
- memset(as->buffer, 0, len);
- }
+ as->dma.sgtx.dma_address = xfer->tx_dma + xfer->len - *plen;
+
+ if (len > master->max_dma_len)
+ len = master->max_dma_len;
sg_dma_len(&as->dma.sgtx) = len;
sg_dma_len(&as->dma.sgrx) = len;
@@ -834,25 +807,10 @@ static void atmel_spi_next_xfer_data(struct spi_master *master,
struct atmel_spi *as = spi_master_get_devdata(master);
u32 len = *plen;
- /* use scratch buffer only when rx or tx data is unspecified */
- if (xfer->rx_buf)
- *rx_dma = xfer->rx_dma + xfer->len - *plen;
- else {
- *rx_dma = as->buffer_dma;
- if (len > BUFFER_SIZE)
- len = BUFFER_SIZE;
- }
-
- if (xfer->tx_buf)
- *tx_dma = xfer->tx_dma + xfer->len - *plen;
- else {
- *tx_dma = as->buffer_dma;
- if (len > BUFFER_SIZE)
- len = BUFFER_SIZE;
- memset(as->buffer, 0, len);
- dma_sync_single_for_device(&as->pdev->dev,
- as->buffer_dma, len, DMA_TO_DEVICE);
- }
+ *rx_dma = xfer->rx_dma + xfer->len - *plen;
+ *tx_dma = xfer->tx_dma + xfer->len - *plen;
+ if (len > master->max_dma_len)
+ len = master->max_dma_len;
*plen = len;
}
@@ -1026,16 +984,12 @@ atmel_spi_pump_single_data(struct atmel_spi *as, struct spi_transfer *xfer)
u16 *rxp16;
unsigned long xfer_pos = xfer->len - as->current_remaining_bytes;
- if (xfer->rx_buf) {
- if (xfer->bits_per_word > 8) {
- rxp16 = (u16 *)(((u8 *)xfer->rx_buf) + xfer_pos);
- *rxp16 = spi_readl(as, RDR);
- } else {
- rxp = ((u8 *)xfer->rx_buf) + xfer_pos;
- *rxp = spi_readl(as, RDR);
- }
+ if (xfer->bits_per_word > 8) {
+ rxp16 = (u16 *)(((u8 *)xfer->rx_buf) + xfer_pos);
+ *rxp16 = spi_readl(as, RDR);
} else {
- spi_readl(as, RDR);
+ rxp = ((u8 *)xfer->rx_buf) + xfer_pos;
+ *rxp = spi_readl(as, RDR);
}
if (xfer->bits_per_word > 8) {
if (as->current_remaining_bytes > 2)
@@ -1074,12 +1028,10 @@ atmel_spi_pump_fifo_data(struct atmel_spi *as, struct spi_transfer *xfer)
/* Read data */
while (num_data) {
rd = spi_readl(as, RDR);
- if (xfer->rx_buf) {
- if (xfer->bits_per_word > 8)
- *words++ = rd;
- else
- *bytes++ = rd;
- }
+ if (xfer->bits_per_word > 8)
+ *words++ = rd;
+ else
+ *bytes++ = rd;
num_data--;
}
}
@@ -1561,29 +1513,22 @@ static int atmel_spi_probe(struct platform_device *pdev)
master->bus_num = pdev->id;
master->num_chipselect = master->dev.of_node ? 0 : 4;
master->setup = atmel_spi_setup;
+ master->flags = (SPI_MASTER_MUST_RX | SPI_MASTER_MUST_TX);
master->transfer_one_message = atmel_spi_transfer_one_message;
master->cleanup = atmel_spi_cleanup;
master->auto_runtime_pm = true;
+ master->max_dma_len = SPI_MAX_DMA_XFER;
platform_set_drvdata(pdev, master);
as = spi_master_get_devdata(master);
- /*
- * Scratch buffer is used for throwaway rx and tx data.
- * It's coherent to minimize dcache pollution.
- */
- as->buffer = dma_alloc_coherent(&pdev->dev, BUFFER_SIZE,
- &as->buffer_dma, GFP_KERNEL);
- if (!as->buffer)
- goto out_free;
-
spin_lock_init(&as->lock);
as->pdev = pdev;
as->regs = devm_ioremap_resource(&pdev->dev, regs);
if (IS_ERR(as->regs)) {
ret = PTR_ERR(as->regs);
- goto out_free_buffer;
+ goto out_unmap_regs;
}
as->phybase = regs->start;
as->irq = irq;
@@ -1681,9 +1626,6 @@ static int atmel_spi_probe(struct platform_device *pdev)
clk_disable_unprepare(clk);
out_free_irq:
out_unmap_regs:
-out_free_buffer:
- dma_free_coherent(&pdev->dev, BUFFER_SIZE, as->buffer,
- as->buffer_dma);
out_free:
spi_master_put(master);
return ret;
@@ -1708,9 +1650,6 @@ static int atmel_spi_remove(struct platform_device *pdev)
spi_readl(as, SR);
spin_unlock_irq(&as->lock);
- dma_free_coherent(&pdev->dev, BUFFER_SIZE, as->buffer,
- as->buffer_dma);
-
clk_disable_unprepare(as->clk);
pm_runtime_put_noidle(&pdev->dev);
--
2.10.2
^ permalink raw reply related
* Applied "spi: atmel: Use SPI core DMA mapping framework" to the spi tree
From: Mark Brown @ 2016-11-25 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0539d3d8c41760bbf0536009b07b4bda57265467.1479985886.git.nicolas.ferre@atmel.com>
The patch
spi: atmel: Use SPI core DMA mapping framework
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 04242ca4e8917999ac2bbc3d2b10409661f60272 Mon Sep 17 00:00:00 2001
From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Date: Thu, 24 Nov 2016 12:24:59 +0100
Subject: [PATCH] spi: atmel: Use SPI core DMA mapping framework
Use the SPI core DMA mapping framework instead of our own
in case of DMA support. PDC support is not converted to this
framework.
The driver is now able to transfer a complete sg list through DMA.
This eventually fix an issue with vmalloc'ed DMA memory that is
provided for example by UBI/UBIFS layers.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
[nicolas.ferre at atmel.com: restrict the use to non-PDC DMA]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-atmel.c | 57 ++++++++++++++++++++++---------------------------
1 file changed, 25 insertions(+), 32 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 8f20d4f75e4a..7e03e221d307 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -268,8 +268,6 @@
struct atmel_spi_dma {
struct dma_chan *chan_rx;
struct dma_chan *chan_tx;
- struct scatterlist sgrx;
- struct scatterlist sgtx;
struct dma_async_tx_descriptor *data_desc_rx;
struct dma_async_tx_descriptor *data_desc_tx;
@@ -453,6 +451,15 @@ static inline bool atmel_spi_use_dma(struct atmel_spi *as,
return as->use_dma && xfer->len >= DMA_MIN_BYTES;
}
+static bool atmel_spi_can_dma(struct spi_master *master,
+ struct spi_device *spi,
+ struct spi_transfer *xfer)
+{
+ struct atmel_spi *as = spi_master_get_devdata(master);
+
+ return atmel_spi_use_dma(as, xfer);
+}
+
static int atmel_spi_dma_slave_config(struct atmel_spi *as,
struct dma_slave_config *slave_config,
u8 bits_per_word)
@@ -720,7 +727,6 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
struct dma_async_tx_descriptor *txdesc;
struct dma_slave_config slave_config;
dma_cookie_t cookie;
- u32 len = *plen;
dev_vdbg(master->dev.parent, "atmel_spi_next_xfer_dma_submit\n");
@@ -731,34 +737,22 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
/* release lock for DMA operations */
atmel_spi_unlock(as);
- /* prepare the RX dma transfer */
- sg_init_table(&as->dma.sgrx, 1);
- as->dma.sgrx.dma_address = xfer->rx_dma + xfer->len - *plen;
-
- /* prepare the TX dma transfer */
- sg_init_table(&as->dma.sgtx, 1);
- as->dma.sgtx.dma_address = xfer->tx_dma + xfer->len - *plen;
-
- if (len > master->max_dma_len)
- len = master->max_dma_len;
-
- sg_dma_len(&as->dma.sgtx) = len;
- sg_dma_len(&as->dma.sgrx) = len;
-
- *plen = len;
+ *plen = xfer->len;
if (atmel_spi_dma_slave_config(as, &slave_config,
xfer->bits_per_word))
goto err_exit;
/* Send both scatterlists */
- rxdesc = dmaengine_prep_slave_sg(rxchan, &as->dma.sgrx, 1,
+ rxdesc = dmaengine_prep_slave_sg(rxchan,
+ xfer->rx_sg.sgl, xfer->rx_sg.nents,
DMA_FROM_DEVICE,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!rxdesc)
goto err_dma;
- txdesc = dmaengine_prep_slave_sg(txchan, &as->dma.sgtx, 1,
+ txdesc = dmaengine_prep_slave_sg(txchan,
+ xfer->tx_sg.sgl, xfer->tx_sg.nents,
DMA_TO_DEVICE,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!txdesc)
@@ -804,15 +798,10 @@ static void atmel_spi_next_xfer_data(struct spi_master *master,
dma_addr_t *rx_dma,
u32 *plen)
{
- struct atmel_spi *as = spi_master_get_devdata(master);
- u32 len = *plen;
-
*rx_dma = xfer->rx_dma + xfer->len - *plen;
*tx_dma = xfer->tx_dma + xfer->len - *plen;
- if (len > master->max_dma_len)
- len = master->max_dma_len;
-
- *plen = len;
+ if (*plen > master->max_dma_len)
+ *plen = master->max_dma_len;
}
static int atmel_spi_set_xfer_speed(struct atmel_spi *as,
@@ -1252,7 +1241,7 @@ static int atmel_spi_one_transfer(struct spi_master *master,
* better fault reporting.
*/
if ((!msg->is_dma_mapped)
- && (atmel_spi_use_dma(as, xfer) || as->use_pdc)) {
+ && as->use_pdc) {
if (atmel_spi_dma_map_xfer(as, xfer) < 0)
return -ENOMEM;
}
@@ -1329,7 +1318,7 @@ static int atmel_spi_one_transfer(struct spi_master *master,
}
if (!msg->is_dma_mapped
- && (atmel_spi_use_dma(as, xfer) || as->use_pdc))
+ && as->use_pdc)
atmel_spi_dma_unmap_xfer(master, xfer);
return 0;
@@ -1340,7 +1329,7 @@ static int atmel_spi_one_transfer(struct spi_master *master,
}
if (!msg->is_dma_mapped
- && (atmel_spi_use_dma(as, xfer) || as->use_pdc))
+ && as->use_pdc)
atmel_spi_dma_unmap_xfer(master, xfer);
if (xfer->delay_usecs)
@@ -1518,6 +1507,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
master->cleanup = atmel_spi_cleanup;
master->auto_runtime_pm = true;
master->max_dma_len = SPI_MAX_DMA_XFER;
+ master->can_dma = atmel_spi_can_dma;
platform_set_drvdata(pdev, master);
as = spi_master_get_devdata(master);
@@ -1554,10 +1544,13 @@ static int atmel_spi_probe(struct platform_device *pdev)
as->use_pdc = false;
if (as->caps.has_dma_support) {
ret = atmel_spi_configure_dma(as);
- if (ret == 0)
+ if (ret == 0) {
+ master->dma_tx = as->dma.chan_tx;
+ master->dma_rx = as->dma.chan_rx;
as->use_dma = true;
- else if (ret == -EPROBE_DEFER)
+ } else if (ret == -EPROBE_DEFER) {
return ret;
+ }
} else {
as->use_pdc = true;
}
--
2.10.2
^ permalink raw reply related
* Applied "spi: atmel: trivial: remove unused fields in DMA structure" to the spi tree
From: Mark Brown @ 2016-11-25 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b9945f7ce52c8368843c7de850de302c34d828d7.1479985886.git.nicolas.ferre@atmel.com>
The patch
spi: atmel: trivial: remove unused fields in DMA structure
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d5fab59cab1875b42b93f53da248cac90046547d Mon Sep 17 00:00:00 2001
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Thu, 24 Nov 2016 12:25:00 +0100
Subject: [PATCH] spi: atmel: trivial: remove unused fields in DMA structure
The atmel_spi_dma structure was cluttered with unused fields relative
to older DMA channel selection API. Remove them.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-atmel.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 7e03e221d307..1a21bc6f7d7a 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -268,10 +268,6 @@
struct atmel_spi_dma {
struct dma_chan *chan_rx;
struct dma_chan *chan_tx;
- struct dma_async_tx_descriptor *data_desc_rx;
- struct dma_async_tx_descriptor *data_desc_tx;
-
- struct at_dma_slave dma_slave;
};
struct atmel_spi_caps {
--
2.10.2
^ permalink raw reply related
* Applied "spi: atmel: remove the use of private channel fields" to the spi tree
From: Mark Brown @ 2016-11-25 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c68cd05242ce0e770b639f8cf1019ca94ec2f694.1479985886.git.nicolas.ferre@atmel.com>
The patch
spi: atmel: remove the use of private channel fields
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 768f3d9d80d28c0d2d3cb5774f220c04d4d3c6d8 Mon Sep 17 00:00:00 2001
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Thu, 24 Nov 2016 12:25:01 +0100
Subject: [PATCH] spi: atmel: remove the use of private channel fields
For DMA transfers, we now use the core DMA framework which provides
channel fields in the spi_master structure. Remove the private channels
from atmel_spi stucture which were located in a sub-structure. This
last one (atmel_spi_dma) which is now empty is also removed.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-atmel.c | 86 ++++++++++++++++++++++++-------------------------
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 1a21bc6f7d7a..3e537ed5cd75 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -265,11 +265,6 @@
#define AUTOSUSPEND_TIMEOUT 2000
-struct atmel_spi_dma {
- struct dma_chan *chan_rx;
- struct dma_chan *chan_tx;
-};
-
struct atmel_spi_caps {
bool is_spi2;
bool has_wdrbt;
@@ -302,8 +297,6 @@ struct atmel_spi {
bool use_dma;
bool use_pdc;
bool use_cs_gpios;
- /* dmaengine data */
- struct atmel_spi_dma dma;
bool keep_cs;
bool cs_active;
@@ -460,6 +453,7 @@ static int atmel_spi_dma_slave_config(struct atmel_spi *as,
struct dma_slave_config *slave_config,
u8 bits_per_word)
{
+ struct spi_master *master = platform_get_drvdata(as->pdev);
int err = 0;
if (bits_per_word > 8) {
@@ -491,7 +485,7 @@ static int atmel_spi_dma_slave_config(struct atmel_spi *as,
* path works the same whether FIFOs are available (and enabled) or not.
*/
slave_config->direction = DMA_MEM_TO_DEV;
- if (dmaengine_slave_config(as->dma.chan_tx, slave_config)) {
+ if (dmaengine_slave_config(master->dma_tx, slave_config)) {
dev_err(&as->pdev->dev,
"failed to configure tx dma channel\n");
err = -EINVAL;
@@ -506,7 +500,7 @@ static int atmel_spi_dma_slave_config(struct atmel_spi *as,
* enabled) or not.
*/
slave_config->direction = DMA_DEV_TO_MEM;
- if (dmaengine_slave_config(as->dma.chan_rx, slave_config)) {
+ if (dmaengine_slave_config(master->dma_rx, slave_config)) {
dev_err(&as->pdev->dev,
"failed to configure rx dma channel\n");
err = -EINVAL;
@@ -515,7 +509,8 @@ static int atmel_spi_dma_slave_config(struct atmel_spi *as,
return err;
}
-static int atmel_spi_configure_dma(struct atmel_spi *as)
+static int atmel_spi_configure_dma(struct spi_master *master,
+ struct atmel_spi *as)
{
struct dma_slave_config slave_config;
struct device *dev = &as->pdev->dev;
@@ -525,26 +520,26 @@ static int atmel_spi_configure_dma(struct atmel_spi *as)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- as->dma.chan_tx = dma_request_slave_channel_reason(dev, "tx");
- if (IS_ERR(as->dma.chan_tx)) {
- err = PTR_ERR(as->dma.chan_tx);
+ master->dma_tx = dma_request_slave_channel_reason(dev, "tx");
+ if (IS_ERR(master->dma_tx)) {
+ err = PTR_ERR(master->dma_tx);
if (err == -EPROBE_DEFER) {
dev_warn(dev, "no DMA channel available at the moment\n");
- return err;
+ goto error_clear;
}
dev_err(dev,
"DMA TX channel not available, SPI unable to use DMA\n");
err = -EBUSY;
- goto error;
+ goto error_clear;
}
/*
* No reason to check EPROBE_DEFER here since we have already requested
* tx channel. If it fails here, it's for another reason.
*/
- as->dma.chan_rx = dma_request_slave_channel(dev, "rx");
+ master->dma_rx = dma_request_slave_channel(dev, "rx");
- if (!as->dma.chan_rx) {
+ if (!master->dma_rx) {
dev_err(dev,
"DMA RX channel not available, SPI unable to use DMA\n");
err = -EBUSY;
@@ -557,31 +552,38 @@ static int atmel_spi_configure_dma(struct atmel_spi *as)
dev_info(&as->pdev->dev,
"Using %s (tx) and %s (rx) for DMA transfers\n",
- dma_chan_name(as->dma.chan_tx),
- dma_chan_name(as->dma.chan_rx));
+ dma_chan_name(master->dma_tx),
+ dma_chan_name(master->dma_rx));
+
return 0;
error:
- if (as->dma.chan_rx)
- dma_release_channel(as->dma.chan_rx);
- if (!IS_ERR(as->dma.chan_tx))
- dma_release_channel(as->dma.chan_tx);
+ if (master->dma_rx)
+ dma_release_channel(master->dma_rx);
+ if (!IS_ERR(master->dma_tx))
+ dma_release_channel(master->dma_tx);
+error_clear:
+ master->dma_tx = master->dma_rx = NULL;
return err;
}
-static void atmel_spi_stop_dma(struct atmel_spi *as)
+static void atmel_spi_stop_dma(struct spi_master *master)
{
- if (as->dma.chan_rx)
- dmaengine_terminate_all(as->dma.chan_rx);
- if (as->dma.chan_tx)
- dmaengine_terminate_all(as->dma.chan_tx);
+ if (master->dma_rx)
+ dmaengine_terminate_all(master->dma_rx);
+ if (master->dma_tx)
+ dmaengine_terminate_all(master->dma_tx);
}
-static void atmel_spi_release_dma(struct atmel_spi *as)
+static void atmel_spi_release_dma(struct spi_master *master)
{
- if (as->dma.chan_rx)
- dma_release_channel(as->dma.chan_rx);
- if (as->dma.chan_tx)
- dma_release_channel(as->dma.chan_tx);
+ if (master->dma_rx) {
+ dma_release_channel(master->dma_rx);
+ master->dma_rx = NULL;
+ }
+ if (master->dma_tx) {
+ dma_release_channel(master->dma_tx);
+ master->dma_tx = NULL;
+ }
}
/* This function is called by the DMA driver from tasklet context */
@@ -717,8 +719,8 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
u32 *plen)
{
struct atmel_spi *as = spi_master_get_devdata(master);
- struct dma_chan *rxchan = as->dma.chan_rx;
- struct dma_chan *txchan = as->dma.chan_tx;
+ struct dma_chan *rxchan = master->dma_rx;
+ struct dma_chan *txchan = master->dma_tx;
struct dma_async_tx_descriptor *rxdesc;
struct dma_async_tx_descriptor *txdesc;
struct dma_slave_config slave_config;
@@ -782,7 +784,7 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
err_dma:
spi_writel(as, IDR, SPI_BIT(OVRES));
- atmel_spi_stop_dma(as);
+ atmel_spi_stop_dma(master);
err_exit:
atmel_spi_lock(as);
return -ENOMEM;
@@ -1310,7 +1312,7 @@ static int atmel_spi_one_transfer(struct spi_master *master,
spi_readl(as, SR);
} else if (atmel_spi_use_dma(as, xfer)) {
- atmel_spi_stop_dma(as);
+ atmel_spi_stop_dma(master);
}
if (!msg->is_dma_mapped
@@ -1539,10 +1541,8 @@ static int atmel_spi_probe(struct platform_device *pdev)
as->use_dma = false;
as->use_pdc = false;
if (as->caps.has_dma_support) {
- ret = atmel_spi_configure_dma(as);
+ ret = atmel_spi_configure_dma(master, as);
if (ret == 0) {
- master->dma_tx = as->dma.chan_tx;
- master->dma_rx = as->dma.chan_rx;
as->use_dma = true;
} else if (ret == -EPROBE_DEFER) {
return ret;
@@ -1608,7 +1608,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
pm_runtime_set_suspended(&pdev->dev);
if (as->use_dma)
- atmel_spi_release_dma(as);
+ atmel_spi_release_dma(master);
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
@@ -1630,8 +1630,8 @@ static int atmel_spi_remove(struct platform_device *pdev)
/* reset the hardware and block queue progress */
spin_lock_irq(&as->lock);
if (as->use_dma) {
- atmel_spi_stop_dma(as);
- atmel_spi_release_dma(as);
+ atmel_spi_stop_dma(master);
+ atmel_spi_release_dma(master);
}
spi_writel(as, CR, SPI_BIT(SWRST));
--
2.10.2
^ permalink raw reply related
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125124528.GJ14217@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote:
>> Looking at thread and discussion now, first thinking would be to ensure
>> the transaction is completed properly and then isr fired. You may need
>> to talk to your HW designers to find a way for that. It is quite common
>> that DMA controllers will fire and complete whereas the transaction is
>> still in flight.
>>
>> If that is not doable, then since you claim this is custom part which
>> other vendors wont use (hope we are wrong down the line), then we can
>> have a custom api,
>>
>> foo_sbox_configure(bool enable, ...);
>>
>> This can be invoked from NFC driver when required for configuration and
>> teardown. For very specific cases where people need some specific
>> configuration we do allow custom APIs.
>>
>> Only problem with that would be it wont be a generic solution and you
>> seem to be fine with that.
>
> Isn't this just the same problem as PL08x or any other system which
> has multiple requests from devices, but only a limited number of
> hardware channels - so you have to route the request signals to the
> appropriate hardware channels according to the requests queued up?
>
> If so, no new "custom" APIs are required, it's already able to be
> solved within the DMA engine drivers...
That isn't the problem. The multiplexing of many devices on a limited
number of hardware channels is working fine. The problem is that (some)
client devices need the routing to remain for some time after the dma
interrupt signals completion. I'd characterise this hardware as broken,
but there's nothing we can do about that.
The fix has to provide some way for the dma driver to delay reusing a
hardware channel until the client device indicates completion. If only
a short delay (a few bus cycles) is needed, it is probably acceptable to
rework the driver such that the descriptor completion callback can do
the necessary waiting (e.g. by busy-polling a device status register).
If the delay can be longer, some other method needs to be devised.
--
M?ns Rullg?rd
^ permalink raw reply
* [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Ulf Hansson @ 2016-11-25 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07e71ce4-a78e-750c-6325-0a88891519d5@marvell.com>
[...]
>>>>>> +
>>>>>> + /*
>>>>>> + * Xenon Specific property:
>>>>>> + * emmc: explicitly indicate whether this slot is for eMMC
>>>>>> + * slotno: the index of slot. Refer to SDHC_SYS_CFG_INFO register
>>>>>> + * tun-count: the interval between re-tuning
>>>>>> + * PHY type: "sdhc phy", "emmc phy 5.0" or "emmc phy 5.1"
>>>>>> + */
>>>>>> + if (of_property_read_bool(np, "marvell,xenon-emmc"))
>>>>>> + priv->emmc_slot = true;
>>>>>
>>>>> So, you need this because of the eMMC voltage switch behaviour, right?
>>>>>
>>>>> Then I would rather like to describe this a generic DT bindings for
>>>>> the eMMC voltage level support. There have acutally been some earlier
>>>>> discussions for this, but we haven't yet made some changes.
>>>>>
>>>>> I think what is missing is a mmc-ddr-3_3v DT binding, which when set,
>>>>> allows the host driver to accept I/O voltage switches to 3.3V. If not
>>>>> supported the ->start_signal_voltage_switch() ops may return -EINVAL.
>>>>> This would inform the mmc core to move on to the next supported
>>>>> voltage level. There might be some minor additional changes to the mmc
>>>>> card initialization sequence, but those should be simple.
>>>>>
>>>>> I can help out to look into this, unless you want to do it yourself of course!?
>>>>>
>>>> Yes. One of the reasons is to provide eMMC specific voltage setting.
>>>> But in my very own opinion, it should be irrelevant to voltage level.
>>>> The eMMC voltage setting on our SDHC is different from SD/SDIO voltage switch.
>>>> It will become more complex with different SOC implementation details.
>>>
>>> Got it. Although I think we can cope with that fine just by using the
>>> different SD/eMMC speed modes settings defined in DT (or from the
>>> SDHCI caps register)
>>>
>> In my very opinion, I'm not sure if there is any corner case that driver cannot
>> determine the eMMC card type from DT and SDHC caps.
>>
>>>> Unfortunately, MMC driver cannot determine the card type yet when eMMC voltage
>>>> setting should be executed.
>>>> Thus an flag is required here to tell driver to execute eMMC voltage setting.
>>>>
>>>> Besides, additional eMMC specific settings might be implemented in future, besides
>>>> voltage setting. Most of them should be completed before MMC driver recognizes the
>>>> card type. Thus I have to keep this flag to indicate current SDHC is for eMMC.
>>>
>>> I doubt you will need a generic "eMMC" flag, but let's see when we go forward.
>>>
>>> Currently it's clear you don't need such a flag, so I will submit a
>>> change adding a DT binding for "mmc-ddr-3_3v" then we can take it from
>>> there, to see if it suits your needs.
>>>
>
> Another reason for a special "xenon-emmc" property is that our host IP usually can
> support both eMMC and SD. Whether a host is used as eMMC or SD depends on the
> final implementation of the actual product.
> Thus our host driver needs to know whether current SDHC is fixed as eMMC or SD.
> So far, It can only get the information from DT.
As a matter of fact for mounted non-removable cards, such as eMMC, we
already have the option to describe some of their characteristics in
DT. Perhaps that's what you need?
Please have a look at:
Documentation/devicetree/bindings/mmc/mmc-card.txt
>
> After out host driver get the card type information from DT, it can prepare eMMC
> specific voltage, set eMMC specific mmc->caps/caps2 flags and do other
> vendor specific init, before card init procedure.
> Otherwise, our host driver has to wait until card type is determined in mmc_rescan().
>
> A generic "eMMC" flag is unnecessary. I just require a private property,
> which is only used in our host driver and DT.
>
> Thank you.
>
> Best regards,
> Hu Ziji
>
>>
>> Actually, our eMMC is usually fixed as 1.8V.
>>
>> The pair "no-sd" + "no-sdio" can provide the similar information.
>> But I'm not sure if it is proper to use those two property in such a way.
>>
>> Thank you.
>>
>> Best regards
>> Hu Ziji
>>
>>> [...]
>>>
>>> Kind regards
>>> Uffe
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
Kind regards
Uffe
^ permalink raw reply
* [PATCH 1/5] spi: atmel: trivial: move info banner to latest probe action
From: Mark Brown @ 2016-11-25 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e259bb1c87e32c67295747f868f8684c1e929d68.1479985886.git.nicolas.ferre@atmel.com>
On Thu, Nov 24, 2016 at 12:24:57PM +0100, Nicolas Ferre wrote:
> The info banner is here to tell that everything went well, so place
> it at the very end of the probe function.
Really we should just drop this, the banner is only telling us things
enumerated from DT so it's adding noise to the boot.
-------------- 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/20161125/7ef8494d/attachment.sig>
^ permalink raw reply
* [PATCH v2 7/7] ARM64: dts: amlogic: add the ethernet TX delay configuration
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl@googlemail.com>
This adds the amlogic,tx-delay-ns with the old (hardcoded) default value
of 2ns to all boards which are using an RGMII ethernet PHY.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 2 ++
6 files changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index cbaf024..fdade07 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -161,6 +161,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
phy-mode = "rgmii";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 2abc553..8172e12 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -152,6 +152,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
phy-mode = "rgmii";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index a0e92e3..ab49712 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -131,6 +131,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
phy-mode = "rgmii";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index f66939c..7fd11c6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -64,6 +64,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
/* External PHY is in RGMII */
phy-mode = "rgmii";
};
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..f83d6dc 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -156,6 +156,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
/* External PHY is in RGMII */
phy-mode = "rgmii";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
index 5dbc660..e428e29 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
@@ -64,6 +64,8 @@
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
+ amlogic,tx-delay-ns = <2>;
+
/* External PHY is in RGMII */
phy-mode = "rgmii";
};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 6/7] ARM64: dts: meson-gxbb-vega-s95: add reset for the ethernet PHY
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl@googlemail.com>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state. While here also specify the phy-handle of the ethmac node to
make the PHY configuration similar to the one we have on GXL devices.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index e59ad30..a0e92e3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -113,10 +113,25 @@
pinctrl-names = "default";
};
+&mdio0 {
+ ethernet_phy0: ethernet-phy at 0 {
+ compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
ðmac {
status = "okay";
pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
+
+ phy-handle = <ðernet_phy0>;
+
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-active-low;
+
+ phy-mode = "rgmii";
};
&usb0_phy {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 5/7] ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl@googlemail.com>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state. While here also specify the phy-handle of the ethmac node to
make the PHY configuration similar to the one we have on GXL devices.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 203be28..2abc553 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -134,10 +134,25 @@
pinctrl-names = "default";
};
+&mdio0 {
+ ethernet_phy0: ethernet-phy at 0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
ðmac {
status = "okay";
pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
+
+ phy-handle = <ðernet_phy0>;
+
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-active-low;
+
+ phy-mode = "rgmii";
};
&ir {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 4/7] ARM64: dts: meson-gxbb-odroidc2: add reset for the ethernet PHY
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl@googlemail.com>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state. While here also specify the phy-handle of the ethmac node to
make the PHY configuration similar to the one we have on GXL devices.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..cbaf024 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -143,10 +143,25 @@
pinctrl-names = "default";
};
+&mdio0 {
+ ethernet_phy0: ethernet-phy at 0 {
+ compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
ðmac {
status = "okay";
pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
+
+ phy-handle = <ðernet_phy0>;
+
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-active-low;
+
+ phy-mode = "rgmii";
};
&ir {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/7] ARM64: dts: meson-gx: move the MDIO node to meson-gx
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl@googlemail.com>
stmmac's MDIO bus is currently only defined in meson-gxl.dtsi. Move it
up to meson-gx to allow us to keep the stmmac configuration for
meson-gxbb similar to the configuration on meson-gxl.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 6 ------
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 47ab306..a2c3ca6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -371,6 +371,12 @@
interrupt-names = "macirq";
phy-mode = "rgmii";
status = "disabled";
+
+ mdio0: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ };
};
apb: apb at d0000000 {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 3af54dc..aa3cd80 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -57,12 +57,6 @@
<&clkc CLKID_FCLK_DIV2>,
<&clkc CLKID_MPLL2>;
clock-names = "stmmaceth", "clkin0", "clkin1";
-
- mdio0: mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "snps,dwmac-mdio";
- };
};
&aobus {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/7] net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl@googlemail.com>
Prior to this patch we were using a hardcoded RGMII TX clock delay of
2ns (= 1/4 cycle of the 125MHz RGMII TX clock). This value works for
many boards, but unfortunately not for all (due to the way the actual
circuit is designed, sometimes because the TX delay is enabled in the
PHY, etc.). Making the TX delay on the MAC side configurable allows us
to support all possible hardware combinations.
This allows fixing a compatibility issue on some boards, where the
RTL8211F PHY is configured to generate the TX delay. We can now turn
off the TX delay in the MAC, because otherwise we would be applying the
delay twice (which results in non-working TX traffic).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 26 +++++++++++++++++-----
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 250e4ce..8ba33be 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -35,10 +35,6 @@
#define PRG_ETH0_TXDLY_SHIFT 5
#define PRG_ETH0_TXDLY_MASK GENMASK(6, 5)
-#define PRG_ETH0_TXDLY_OFF (0x0 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_QUARTER (0x1 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_HALF (0x2 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_THREE_QUARTERS (0x3 << PRG_ETH0_TXDLY_SHIFT)
/* divider for the result of m250_sel */
#define PRG_ETH0_CLK_M250_DIV_SHIFT 7
@@ -69,6 +65,8 @@ struct meson8b_dwmac {
struct clk_divider m25_div;
struct clk *m25_div_clk;
+
+ u32 tx_delay_ns;
};
static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
@@ -179,6 +177,7 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
{
int ret;
unsigned long clk_rate;
+ u8 tx_dly_val;
switch (dwmac->phy_mode) {
case PHY_INTERFACE_MODE_RGMII:
@@ -196,9 +195,13 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
PRG_ETH0_INVERTED_RMII_CLK, 0);
- /* TX clock delay - all known boards use a 1/4 cycle delay */
+ /* TX clock delay in ns = "8ns / 4 * tx_dly_val" (where
+ * 8ns are exactly one cycle of the 125MHz RGMII TX clock):
+ * 0ns = 0x0, 2ns = 0x1, 4ns = 0x2, 6ns = 0x3
+ */
+ tx_dly_val = dwmac->tx_delay_ns >> 1;
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
- PRG_ETH0_TXDLY_QUARTER);
+ tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
break;
case PHY_INTERFACE_MODE_RMII:
@@ -277,6 +280,17 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
if (dwmac->phy_mode < 0) {
dev_err(&pdev->dev, "missing phy-mode property\n");
return -EINVAL;
+ } else if (dwmac->phy_mode != PHY_INTERFACE_MODE_RMII) {
+ ret = of_property_read_u32(pdev->dev.of_node,
+ "amlogic,tx-delay-ns",
+ &dwmac->tx_delay_ns);
+ if (ret && dwmac->phy_mode == PHY_INTERFACE_MODE_RGMII)
+ /* default to a TX clock delay of 2ns when the PHY is
+ * connected via RGMII (with RGMII_ID and RGMII_TXID
+ * the TX clock delay is generated by the PHY and thus
+ * we use the default 0ns delay in these case).
+ */
+ dwmac->tx_delay_ns = 2;
}
ret = meson8b_init_clk(dwmac);
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/7] net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl@googlemail.com>
This allows configuring the RGMII TX clock delay. The RGMII clock is
generated by underlying hardware of the the Meson 8b / GXBB DWMAC glue.
The configuration depends on the actual hardware (no delay may be
needed due to the design of the actual circuit, the PHY might add this
delay, etc.).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
Documentation/devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
index 89e62dd..f8bc540 100644
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/meson-dwmac.txt
@@ -25,6 +25,20 @@ Required properties on Meson8b and newer:
- "clkin0" - first parent clock of the internal mux
- "clkin1" - second parent clock of the internal mux
+Optional properties on Meson8b and newer:
+- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
+ by this driver) in nanoseconds. Allowed values
+ are: 0ns, 2ns, 4ns, 6ns.
+ This must be configured when the phy-mode is
+ "rgmii" (typically a value of 2ns is used in
+ this case).
+ When phy-mode is set to "rgmii-id" or
+ "rgmii-txid" the TX clock delay is already
+ provided by the PHY. In that case this
+ property should be set to 0ns (which disables
+ the TX clock delay in the MAC to prevent the
+ clock from going off because both PHY and MAC
+ are adding a delay).
Example for Meson6:
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/7] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Martin Blumenstingl @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124143417.10178-1-martin.blumenstingl@googlemail.com>
Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
cycle TX clock delay. This seems to work fine for many boards (for
example Odroid-C2 or Amlogic's reference boards) but there are some
others where TX traffic is simply broken.
There are probably multiple reasons why it's working on some boards
while it's broken on others:
- some of Amlogic's reference boards are using a Micrel PHY
- hardware circuit design
- maybe more...
iperf3 results on my Mecool BB2 board (Meson GXM, RTL8211F PHY) with
TX clock delay disabled on the MAC (as it's enabled in the PHY driver).
TX throughput was virtually zero before:
$ iperf3 -c 192.168.1.100 -R
Connecting to host 192.168.1.100, port 5201
Reverse mode, remote host 192.168.1.100 is sending
[ 4] local 192.168.1.206 port 52828 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 108 MBytes 901 Mbits/sec
[ 4] 1.00-2.00 sec 94.2 MBytes 791 Mbits/sec
[ 4] 2.00-3.00 sec 96.5 MBytes 810 Mbits/sec
[ 4] 3.00-4.00 sec 96.2 MBytes 808 Mbits/sec
[ 4] 4.00-5.00 sec 96.6 MBytes 810 Mbits/sec
[ 4] 5.00-6.00 sec 96.5 MBytes 810 Mbits/sec
[ 4] 6.00-7.00 sec 96.6 MBytes 810 Mbits/sec
[ 4] 7.00-8.00 sec 96.5 MBytes 809 Mbits/sec
[ 4] 8.00-9.00 sec 105 MBytes 884 Mbits/sec
[ 4] 9.00-10.00 sec 111 MBytes 934 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1000 MBytes 839 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 998 MBytes 837 Mbits/sec receiver
iperf Done.
$ iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 4] local 192.168.1.206 port 52832 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.01 sec 99.5 MBytes 829 Mbits/sec 117 139 KBytes
[ 4] 1.01-2.00 sec 105 MBytes 884 Mbits/sec 129 70.7 KBytes
[ 4] 2.00-3.01 sec 107 MBytes 889 Mbits/sec 106 187 KBytes
[ 4] 3.01-4.01 sec 105 MBytes 878 Mbits/sec 92 143 KBytes
[ 4] 4.01-5.00 sec 105 MBytes 882 Mbits/sec 140 129 KBytes
[ 4] 5.00-6.01 sec 106 MBytes 883 Mbits/sec 115 195 KBytes
[ 4] 6.01-7.00 sec 102 MBytes 863 Mbits/sec 133 70.7 KBytes
[ 4] 7.00-8.01 sec 106 MBytes 884 Mbits/sec 143 97.6 KBytes
[ 4] 8.01-9.01 sec 104 MBytes 875 Mbits/sec 124 107 KBytes
[ 4] 9.01-10.01 sec 105 MBytes 876 Mbits/sec 90 139 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.01 sec 1.02 GBytes 874 Mbits/sec 1189 sender
[ 4] 0.00-10.01 sec 1.02 GBytes 873 Mbits/sec receiver
iperf Done.
I get similar TX throughput on my Meson GXBB "MXQ Pro+" board when I
disable the PHY's TX-delay and configure a 4ms TX-delay on the MAC.
So changes to at least the RTL8211F PHY driver are needed to get it
working properly in all situations.
NOTE: patches 3-7 should be taken though the Amlogic tree. patches 1
and 2 can be taken through the net-tree or through the Amlogic tree.
There shouldn't be a runtime dependency as long as phy-mode "rgmii"
(or the not-relevant-for-this-case "rmii") is used (which is currently
the case for all ARM64 meson-gx boards) due to the dwmac-meson8b's
default 2ns TX-delay.
Changes since v1:
- renamed the devicetree property "amlogic,tx-delay" to
"amlogic,tx-delay-ns", which makes the .dts easier to read as we can
simply specify human-readable values instead of having "preprocessor
defines and calculation in human brain". Thanks to Andrew Lunn for
the suggestion!
- improved documentation to indicate when the MAC TX-delay should be
configured and how to use the PHY's TX-delay
- changed the default TX-delay in the dwmac-meson8b driver from 2ns
to 0ms when any of the rgmii-*id modes are used (the 2ns default
value still applies for phy-mode "rgmii")
- added patches to properly reset the PHY on Meson GXBB devices and to
use a similar configuration than the one we use on Meson GXL devices
(by passing a phy-handle to stmmac and defining the PHY in the mdio0
bus - patch 3-6)
- add the "amlogic,tx-delay-ns" property to all boards which are using
the RGMII PHY (patch 7)
Martin Blumenstingl (7):
net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
ARM64: dts: meson-gx: move the MDIO node to meson-gx
ARM64: dts: meson-gxbb-odroidc2: add reset for the ethernet PHY
ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
ARM64: dts: meson-gxbb-vega-s95: add reset for the ethernet PHY
ARM64: dts: amlogic: add the ethernet TX delay configuration
.../devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 6 +++++
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 17 ++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 17 ++++++++++++++
.../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 17 ++++++++++++++
.../boot/dts/amlogic/meson-gxl-s905d-p230.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 6 -----
.../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 ++
.../arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 2 ++
.../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 26 +++++++++++++++++-----
10 files changed, 97 insertions(+), 12 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Ulf Hansson @ 2016-11-25 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <76ce72f8-4b86-3b83-544f-b9a7ef871393@marvell.com>
[...]
>>
>> Moreover, we have ->enable_sdio_irq() ops that deals with this.
>>
> Yes. I mean the SDIO irqs on DAT1 line in async mode.
> This field enables our host to recognize the async SDIO irq from SDIO device.
> It controls our host side behavior, other than the SDIO device.
>
> I think ->enable_sdio_irq() is a more reasonable place to put this workraound.
> I will export sdhci_enable_sdio_irq() and implement out host own
> enable_sdio_irq() calling sdhci_enable_sdio)irq() plus this workaround.
> Does it sound reasonable to you?
Yes.
[...]
>>
>> Got it. Although I think we can cope with that fine just by using the
>> different SD/eMMC speed modes settings defined in DT (or from the
>> SDHCI caps register)
>>
> In my very opinion, I'm not sure if there is any corner case that driver cannot
> determine the eMMC card type from DT and SDHC caps.
>
>>> Unfortunately, MMC driver cannot determine the card type yet when eMMC voltage
>>> setting should be executed.
>>> Thus an flag is required here to tell driver to execute eMMC voltage setting.
>>>
>>> Besides, additional eMMC specific settings might be implemented in future, besides
>>> voltage setting. Most of them should be completed before MMC driver recognizes the
>>> card type. Thus I have to keep this flag to indicate current SDHC is for eMMC.
>>
>> I doubt you will need a generic "eMMC" flag, but let's see when we go forward.
>>
>> Currently it's clear you don't need such a flag, so I will submit a
>> change adding a DT binding for "mmc-ddr-3_3v" then we can take it from
>> there, to see if it suits your needs.
>>
>
> Actually, our eMMC is usually fixed as 1.8V.
>
> The pair "no-sd" + "no-sdio" can provide the similar information.
> But I'm not sure if it is proper to use those two property in such a way.
Well, potentially those could be used like that.
The point of why we added them was to allow hosts that don't support
the different protocols (which is somewhat true for your case, because
of signal voltage issues) to tell the mmc core about it. That instead
of having to all kind of crazy hacks in the drives, that in then
didn't work out so well.
Kind regards
Uffe
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: David Howells @ 2016-11-25 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9c-C2uXZ0fVatCM8ffXJZDgjBcDb_T0nsFecGqgrF11Q@mail.gmail.com>
Okay, how about the attached?
Can these variables every be anything other than 1 or 0? E.g. should the
check on SetupMode be that it isn't 0 rather than it is 1?
David
---
commit 6d4bb08e376045e27706c2740c0fdff0a6ec43f7
Author: David Howells <dhowells@redhat.com>
Date: Fri Nov 25 11:52:05 2016 +0000
efi: Handle secure boot from UEFI-2.6
UEFI-2.6 adds a new variable, DeployedMode. If it exists, this must be 1
if we're to engage lockdown mode.
Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: David Howells <dhowells@redhat.com>
diff --git a/drivers/firmware/efi/libstub/secureboot.c b/drivers/firmware/efi/libstub/secureboot.c
index ca643eba5a4b..157782d1c552 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -22,6 +22,9 @@ static const efi_char16_t const efi_SecureBoot_name[] = {
static const efi_char16_t const efi_SetupMode_name[] = {
'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
};
+static const efi_char16_t const efi_DeployedMode_name[] = {
+ 'D', 'e', 'p', 'l', 'o', 'y', 'e', 'd', 'M', 'o', 'd', 'e', 0
+};
/* SHIM variables */
static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
@@ -62,6 +65,17 @@ int efi_get_secureboot(efi_system_table_t *sys_table_arg)
if (val == 1)
return 0;
+ /* UEFI-2.6 requires DeployedMode to be 1. */
+ if (sys_table_arg->hdr.revision == EFI_2_60_SYSTEM_TABLE_REVISION) {
+ status = get_efi_var(efi_DeployedMode_name, &efi_variable_guid,
+ NULL, &size, &val);
+ if (status != EFI_SUCCESS)
+ goto out_efi_err;
+
+ if (val != 1)
+ return 0;
+ }
+
/* See if a user has put shim into insecure mode. If so, and if the
* variable doesn't have the runtime attribute set, we might as well
* honor that.
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 333d31bf55bf..563abb37f03f 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -645,6 +645,10 @@ typedef struct {
#define EFI_SYSTEM_TABLE_SIGNATURE ((u64)0x5453595320494249ULL)
+#define EFI_2_60_SYSTEM_TABLE_REVISION ((2 << 16) | (60))
+#define EFI_2_50_SYSTEM_TABLE_REVISION ((2 << 16) | (50))
+#define EFI_2_40_SYSTEM_TABLE_REVISION ((2 << 16) | (40))
+#define EFI_2_31_SYSTEM_TABLE_REVISION ((2 << 16) | (31))
#define EFI_2_30_SYSTEM_TABLE_REVISION ((2 << 16) | (30))
#define EFI_2_20_SYSTEM_TABLE_REVISION ((2 << 16) | (20))
#define EFI_2_10_SYSTEM_TABLE_REVISION ((2 << 16) | (10))
^ permalink raw reply related
* [PATCH v2 6/8] ASoC: sun4i-codec: Add support for H3 codec
From: Maxime Ripard @ 2016-11-25 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-7-wens@csie.org>
On Fri, Nov 25, 2016 at 08:34:40PM +0800, Chen-Yu Tsai wrote:
> The codec on the H3 is similar to the one found on the A31. One key
> difference is the analog path controls are routed through the PRCM
> block. This is supported by the sun8i-codec-analog driver, and tied
> into this codec driver with the audio card's aux_dev.
>
> In addition, the H3 has no HP (headphone) and HBIAS support, and no
> MIC3 input. The FIFO related registers are slightly rearranged.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161125/1b113a91/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/8] ASoC: sun4i-codec: Add support for A23 codec
From: Maxime Ripard @ 2016-11-25 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-3-wens@csie.org>
On Fri, Nov 25, 2016 at 08:34:36PM +0800, Chen-Yu Tsai wrote:
> The codec in the A23 is similar to the one found on the A31. One key
> difference is the analog path controls are routed through the PRCM
> block. This is supported by the sun8i-codec-analog driver, and tied
> into this codec driver with the audio card's aux_dev.
>
> In addition, the A23 does not have LINEOUT, and it does not support
> headset jack detection or buttons.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161125/26d001dd/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 1/8] mfd: sun6i-prcm: Add codec analog controls sub-device for Allwinner A23
From: Maxime Ripard @ 2016-11-25 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125123442.28410-2-wens@csie.org>
On Fri, Nov 25, 2016 at 08:34:35PM +0800, Chen-Yu Tsai wrote:
> The PRCM block on the A23 contains a message box like interface to
> the registers for the analog path controls of the internal codec.
>
> Add a sub-device for it.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161125/37ff111a/attachment.sig>
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: Ard Biesheuvel @ 2016-11-25 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17942.1480078269@warthog.procyon.org.uk>
On 25 November 2016 at 12:51, David Howells <dhowells@redhat.com> wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> There is a 'revision' field in the header ('hdr') of the EFI system
>> table, so something like
>
> Is this the same as the fw_revision in the system table?
>
> #define EFI_2_60_SYSTEM_TABLE_REVISION ((2<<16) | (60))
> #define EFI_2_50_SYSTEM_TABLE_REVISION ((2<<16) | (50))
> #define EFI_2_40_SYSTEM_TABLE_REVISION ((2<<16) | (40))
> ...
>
Yes. And in fact, that means my example is incorrect (60 not 6 in the
minor field)
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: David Howells @ 2016-11-25 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9c-C2uXZ0fVatCM8ffXJZDgjBcDb_T0nsFecGqgrF11Q@mail.gmail.com>
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> There is a 'revision' field in the header ('hdr') of the EFI system
> table, so something like
Is this the same as the fw_revision in the system table?
#define EFI_2_60_SYSTEM_TABLE_REVISION ((2<<16) | (60))
#define EFI_2_50_SYSTEM_TABLE_REVISION ((2<<16) | (50))
#define EFI_2_40_SYSTEM_TABLE_REVISION ((2<<16) | (40))
...
David
^ permalink raw reply
* [RFC PATCH] ARM: dts: Add support for Turris Omnia
From: Tomas Hlavacek @ 2016-11-25 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124150700.GD7155@lunn.ch>
Hi!
On Thu, Nov 24, 2016 at 4:07 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> @Tomas: I think it doesn't make sense when we alternate sending
>> patches
>> without prior arrangement. Do you already work on a v5? If not I
>> can do
>> that to fix the last few comments. Not sure when a submission is too
>> late to enter v4.10, but I think the window isn't that big any more.
>
> It is getting a bit late. But maybe Linus will add in another -rc
> week.
>
>>
>> > No leds? No buttons via gpio-keys?
>>
>> The leds are controlled by a Cortex-M0 and without intervention
>> blink
>> according to a hardware function (network, power, pci). IMHO that's
>> ok
>> for an initial setup.
>
> Yes. That is fine. It is just unusual. Most boards have gpio-led and
> gpio-keys, which are easy to add. That is why i asked. Adding an LED
> driver which talks to this M0 can be added later.
Actually the WiP driver for MCU LED interface, that we use in our
kernel is here:
https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb
It definitely needs some cleanup and it adds non-standard features
(main PWM for all LEDs, autonomous blink mode, colors) via custom /sys
files, which I suspect that is not going to be acceptable for upstream.
Let's keep it for the next iteration.
Regarding the button, we actually have one, that is connected to the
MCU and by default it sets LED brigtness autonomously, but it should be
able to generate IRQs via the MCU if we change the mode in the MCU.
I'll look into that.
Tomas
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: Sascha Hauer @ 2016-11-25 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124154543.GA8937@linaro.org>
On Thu, Nov 24, 2016 at 08:45:43AM -0700, Mathieu Poirier wrote:
> On Thu, Nov 24, 2016 at 07:41:37AM +0100, Sascha Hauer wrote:
> > On Wed, Nov 23, 2016 at 10:13:02AM -0700, Mathieu Poirier wrote:
> > > On Wed, Nov 23, 2016 at 11:01:03AM +0100, Sascha Hauer wrote:
> > > > With this patch the serial core provides LED triggers for RX and TX.
> > > >
> > > > As the serial core layer does not know when the hardware actually sends
> > > > or receives characters, this needs help from the UART drivers. The
> > > > LED triggers are registered in uart_add_led_triggers() called from
> > > > the UART drivers which want to support LED triggers. All the driver
> > > > has to do then is to call uart_led_trigger_[tx|rx] to indicate
> > > > activite.
> > >
> > > Hello Sascha,
> > >
> > > >
> > > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > ---
> > > > drivers/tty/serial/serial_core.c | 73 ++++++++++++++++++++++++++++++++++++++++
> > > > include/linux/serial_core.h | 10 ++++++
> > > > 2 files changed, 83 insertions(+)
> > > >
> > > > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> > > > index f2303f3..3e8afb7 100644
> > > > --- a/drivers/tty/serial/serial_core.c
> > > > +++ b/drivers/tty/serial/serial_core.c
> > > > @@ -34,6 +34,7 @@
> > > > #include <linux/serial_core.h>
> > > > #include <linux/delay.h>
> > > > #include <linux/mutex.h>
> > > > +#include <linux/leds.h>
> > > >
> > > > #include <asm/irq.h>
> > > > #include <asm/uaccess.h>
> > > > @@ -2703,6 +2704,77 @@ static const struct attribute_group tty_dev_attr_group = {
> > > > .attrs = tty_dev_attrs,
> > > > };
> > > >
> > > > +void uart_led_trigger_tx(struct uart_port *uport)
> > > > +{
> > > > + unsigned long delay = 50;
> > > > +
> > > > + led_trigger_blink_oneshot(uport->led_trigger_tx, &delay, &delay, 0);
> > > > +}
> > > > +
> > > > +void uart_led_trigger_rx(struct uart_port *uport)
> > > > +{
> > > > + unsigned long delay = 50;
> > > > +
> > > > + led_trigger_blink_oneshot(uport->led_trigger_rx, &delay, &delay, 0);
> > >
> > > For both rx/tx the core constrains the delay_on/off along with the inversion.
> > > Instead of adding the led_trigger_rx/tx and led_trigger_rx/tx_name to the
> > > struct uart_port, wouldn't it be better to add a new struct led_trigger that
> > > would encapsulate those along wit the on/off delay and the inversion?
> > >
> > > That way those values could be communicated to the core at registration time
> > > instead of hard-coding things.
> >
> > Not sure this goes into the right direction. Looking at the other
> > callers of led_trigger_blink_oneshot() most of them use an arbitrary
> > blink time of 30 or 50ms and the users seem to be happy with it. There
> > doesn't seem to be the desire to make that value configurable. If we
> > want to make it configurable, it's probably better to move the option
> > to the led device rather than putting the burden on every user of the
> > led triggers.
>
> So you did find instances where the blink time wasn't 50ms. To me that's
> a valid reason to not hard code the blink time and proceed differently.
But they are hardcoded to these values. My gut feeling is that the
authors had to pick a value and some used 30ms while others used 50ms.
Making this configurable to me only means that it will be harder to
cleanup later. I'd rather wait until someone comes along who really
can present good reasons to make that configurable.
>
> >
> > I don't think the inversion flag is meant for being configurable. It's
> > rather used for the default state of the LED. The CAN layer for example
> > turns the LED on when the interface is up and then blinks (turns off and
> > on again) on activity. For this it uses the inversion flag.
> >
> > >
> > > > +}
> > > > +
> > > > +/**
> > > > + * uart_add_led_triggers - register LED triggers for a UART
> > > > + * @drv: pointer to the uart low level driver structure for this port
> > > > + * @uport: uart port structure to use for this port.
> > > > + *
> > > > + * Called by the driver to register LED triggers for a UART. It's the
> > > > + * drivers responsibility to call uart_led_trigger_rx/tx on received
> > > > + * and transmitted chars then.
> > > > + */
> > > > +int uart_add_led_triggers(struct uart_driver *drv, struct uart_port *uport)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + if (!IS_ENABLED(CONFIG_LEDS_TRIGGERS))
> > > > + return 0;
> > >
> > > Since this is a public interface, checking for valid led_trigger_tx/rx before
> > > moving on with the rest of the initialisation is probably a good idea.
> >
> > What do you mean? Should we return an error when CONFIG_LEDS_TRIGGERS is
> > disabled?
>
> if (!uport->led_trigger_rx || !uport->led_triggertx)
> return -EINVAL;
uport->led_trigger_rx|tx are structs allocated in this function. It's
the normal case that they are NULL.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v3 2/3] powerpc/reloc64: add support for 32-bit CRC pseudo-symbols
From: Ard Biesheuvel @ 2016-11-25 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87oa13ssqq.fsf@concordia.ellerman.id.au>
On 25 November 2016 at 11:29, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>
>> diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh
>> index ec2d5c835170..2f510fbc87da 100755
>> --- a/arch/powerpc/relocs_check.sh
>> +++ b/arch/powerpc/relocs_check.sh
>> @@ -43,7 +43,8 @@ R_PPC_ADDR16_HA
>> R_PPC_RELATIVE
>> R_PPC_NONE' |
>> grep -E -v '\<R_PPC64_ADDR64[[:space:]]+mach_' |
>> - grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_'
>> + grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_' |
>> + grep -E -v '\<R_PPC64_ADDR32[[:space:]]+\*ABS\*'
>
> I'm still getting:
>
> WARNING: 24 bad relocations
> c000000000d307c4 R_PPC64_ADDR32 __crc___arch_hweight16
> c000000000d307c8 R_PPC64_ADDR32 __crc___arch_hweight32
> c000000000d307cc R_PPC64_ADDR32 __crc___arch_hweight64
> c000000000d307d0 R_PPC64_ADDR32 __crc___arch_hweight8
> c000000000d30848 R_PPC64_ADDR32 __crc___bswapdi2
> c000000000d30854 R_PPC64_ADDR32 __crc___clear_user
> c000000000d30868 R_PPC64_ADDR32 __crc___copy_tofrom_user
> c000000000d30d4c R_PPC64_ADDR32 __crc__mcount
> c000000000d31344 R_PPC64_ADDR32 __crc_copy_page
> c000000000d3141c R_PPC64_ADDR32 __crc_current_stack_pointer
> c000000000d31840 R_PPC64_ADDR32 __crc_empty_zero_page
> c000000000d31a7c R_PPC64_ADDR32 __crc_flush_dcache_range
> c000000000d31a84 R_PPC64_ADDR32 __crc_flush_icache_range
> c000000000d32608 R_PPC64_ADDR32 __crc_load_fp_state
> c000000000d32614 R_PPC64_ADDR32 __crc_load_vr_state
> c000000000d32828 R_PPC64_ADDR32 __crc_memchr
> c000000000d32830 R_PPC64_ADDR32 __crc_memcmp
> c000000000d32834 R_PPC64_ADDR32 __crc_memcpy
> c000000000d32840 R_PPC64_ADDR32 __crc_memmove
> c000000000d32888 R_PPC64_ADDR32 __crc_memset
> c000000000d33c9c R_PPC64_ADDR32 __crc_store_fp_state
> c000000000d33ca0 R_PPC64_ADDR32 __crc_store_vr_state
> c000000000d33cf0 R_PPC64_ADDR32 __crc_strncmp
> c000000000d33cf4 R_PPC64_ADDR32 __crc_strncpy
>
Ah right, my bad. The regex above should switch to ADDR32 as well for
__crc_ symbols.
>
> If I just add those to the whitelist it builds, but then things aren't
> happy at boot:
>
>
> [ 7.607687] kvm: disagrees about version of symbol module_layout
> [ 7.846799] virtio: disagrees about version of symbol module_layout
> [ 22.012615] crc32c_vpmsum: disagrees about version of symbol module_layout
> [ 22.012959] libcrc32c: disagrees about version of symbol module_layout
>
Sigh. I suppose your modversions fixes are queued for v4.10? It's
probably best to revisit this after the v4.10 merge window closes
then, just to make sure I'm not aiming for a moving target.
Thanks,
Ard.
^ 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