* 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: trivial: move info banner to latest probe action" to the spi tree
From: Mark Brown @ 2016-11-25 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e259bb1c87e32c67295747f868f8684c1e929d68.1479985886.git.nicolas.ferre@atmel.com>
The patch
spi: atmel: trivial: move info banner to latest probe action
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 ce24a513fb142e855b4aa77f91334c2f203c0d99 Mon Sep 17 00:00:00 2001
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Thu, 24 Nov 2016 12:24:57 +0100
Subject: [PATCH] spi: atmel: trivial: move info banner to latest probe action
The info banner is here to tell that everything went well, so place
it at the very end of the probe function.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-atmel.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index b2931493cab2..a9ae1836e1e2 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1654,10 +1654,6 @@ static int atmel_spi_probe(struct platform_device *pdev)
spi_writel(as, CR, SPI_BIT(FIFOEN));
}
- /* go! */
- dev_info(&pdev->dev, "Atmel SPI Controller at 0x%08lx (irq %d)\n",
- (unsigned long)regs->start, irq);
-
pm_runtime_set_autosuspend_delay(&pdev->dev, AUTOSUSPEND_TIMEOUT);
pm_runtime_use_autosuspend(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
@@ -1667,6 +1663,10 @@ static int atmel_spi_probe(struct platform_device *pdev)
if (ret)
goto out_free_dma;
+ /* go! */
+ dev_info(&pdev->dev, "Atmel SPI Controller at 0x%08lx (irq %d)\n",
+ (unsigned long)regs->start, irq);
+
return 0;
out_free_dma:
--
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:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <092f44ee-4560-be17-25f7-00948dba3cfa@free.fr>
Mason <slash.tmp@free.fr> writes:
> On 25/11/2016 05:55, Vinod Koul wrote:
>
>> On Wed, Nov 23, 2016 at 11:25:44AM +0100, Mason wrote:
>>
>>> On my platform, setting up a DMA transfer is a two-step process:
>>>
>>> 1) configure the "switch box" to connect a device to a memory channel
>>> 2) configure the transfer details (address, size, command)
>>>
>>> When the transfer is done, the sbox setup can be torn down,
>>> and the DMA driver can start another transfer.
>>>
>>> The current software architecture for my NFC (NAND Flash controller)
>>> driver is as follows (for one DMA transfer).
>>>
>>> sg_init_one
>>> dma_map_sg
>>> dmaengine_prep_slave_sg
>>> dmaengine_submit
>>> dma_async_issue_pending
>>> configure_NFC_transfer
>>> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
>>> wait_for_NFC_idle
>>> dma_unmap_sg
>>
>> 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.
>
> It seems there is a disconnect between what Linux expects - an IRQ
> when the transfer is complete - and the quirks of this HW :-(
>
> On this system, there are MBUS "agents" connected via a "switch box".
> An agent fires an IRQ when it has dealt with its *half* of the transfer.
>
> SOURCE_AGENT <---> SBOX <---> DESTINATION_AGENT
>
> Here are the steps for a transfer, in the general case:
>
> 1) setup the sbox to connect SOURCE TO DEST
> 2) configure source to send N bytes
> 3) configure dest to receive N bytes
>
> When SOURCE_AGENT has sent N bytes, it fires an IRQ
> When DEST_AGENT has received N bytes, it fires an IRQ
> The sbox connection can be torn down only when the destination
> agent has received all bytes.
> (And the twist is that some agents do not have an IRQ line.)
>
> The system provides 3 RAM-to-sbox agents (read channels)
> and 3 sbox-to-RAM agents (write channels).
>
> The NAND Flash controller read and write agents do not have
> IRQ lines.
>
> So for a NAND-to-memory transfer (read from device)
> - nothing happens when the NFC has finished sending N bytes to the sbox
> - the write channel fires an IRQ when it has received N bytes
>
> In that case, one IRQ fires when the transfer is complete,
> like Linux expects.
>
> For a memory-to-NAND transfer (write to device)
> - the read channel fires an IRQ when it has sent N bytes
> - the NFC driver is supposed to poll the NFC to determine
> when the controller has finished writing N bytes
>
> In that case, the IRQ does not indicate that the transfer
> is complete, merely that the sending half has finished
> its part.
When does your NAND controller signal completion? When it has received
the DMA data, or only when it has finished the actual write operation?
> I think it is possible to have a generic solution:
> Right now, the callback is called from tasklet context.
> If we can have a new flag to have the callback invoked
> directly from the ISR, then the driver for the client
> device can do what is required.
No, that won't work. The callback shouldn't run in interrupt context.
--
M?ns Rullg?rd
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Russell King - ARM Linux @ 2016-11-25 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xtwav9092.fsf@unicorn.mansr.com>
On Fri, Nov 25, 2016 at 01:07:05PM +0000, M?ns Rullg?rd wrote:
> 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.
What I understood from the original mail is:
| The problem is that the DMA driver tears down the sbox setup
| as soon as it receives the IRQ. However, when writing to the
| device, the interrupt only means "I have pushed all data from
| memory to the memory channel". These data have not reached
| the device yet, and may still be "in flight". Thus the sbox
| setup can only be torn down after the NFC is idle.
The interrupt comes in after it's read the the last data from memory,
but the data is still sitting in the engine's buffers and has not yet
been passed to the device.
It sounds like the DMA engine buffers the data on its way to the device,
and it's not clear from the description whether that is done in
response to a request from the device or whether the data is prefetched.
IOW, what the lifetime of the data in the dma engine is.
It seems odd that the DMA engine provides no way to know whether the
channel still contains data that is in-flight to the device, whether
by interrupt (from the descriptions the IRQ is way too early) or by
polling some status register within the DMA engine itself.
If the delay is predictable, why not use a delayed workqueue or a
hrtimer to wait a period after the IRQ before completing the DMA
transaction? If it's not predictable and you haven't some status
register in the DMA engine hardware that indicates whether there's
remaining data, then the design really is screwed up, and I don't
think there's a reasonable solution to the problem - anything
would be a horrid hack that would be specific to this SoC.
It would be unfair to augment the API and add the burden on everyone
for the new API when 99.999% of the world doesn't require it.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 0/7] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: David Laight @ 2016-11-25 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl@googlemail.com>
From: Martin Blumenstingl
> Sent: 25 November 2016 13:02
> 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...
...
Interesting thought.
Can you test phy loopback with different delays?
It might be then possible to default to 'auto'.
David
^ permalink raw reply
* [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Ziji Hu @ 2016-11-25 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFoqyF5QkJy+PmGa-b8JhaUmVXeoqBfv+pdupFiJBgyiLg@mail.gmail.com>
Hi Ulf,
On 2016/11/25 21:06, Ulf Hansson wrote:
> [...]
>
>>>>>>> +
>>>>>>> + /*
>>>>>>> + * 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
>
Great!
I will try this mmc-card sub-node.
Thank you very much.
Best regards,
Hu Ziji
>>
>> 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 5/7] efi: Get the secure boot status [ver #3]
From: Ard Biesheuvel @ 2016-11-25 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <31374.1480078855@warthog.procyon.org.uk>
On 25 November 2016 at 13:00, David Howells <dhowells@redhat.com> wrote:
> 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?
>
The firmware will ensure that these variables only ever assume the
documented values.
> 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;
val == 0 is better imo, since that will prevent unexpected values from
being interpreted as 'secure boot disabled'
> + }
> +
> /* 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
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125133436.GK14217@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> On Fri, Nov 25, 2016 at 01:07:05PM +0000, M?ns Rullg?rd wrote:
>> 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.
>
> What I understood from the original mail is:
>
> | The problem is that the DMA driver tears down the sbox setup
> | as soon as it receives the IRQ. However, when writing to the
> | device, the interrupt only means "I have pushed all data from
> | memory to the memory channel". These data have not reached
> | the device yet, and may still be "in flight". Thus the sbox
> | setup can only be torn down after the NFC is idle.
>
> The interrupt comes in after it's read the the last data from memory,
> but the data is still sitting in the engine's buffers and has not yet
> been passed to the device.
>
> It sounds like the DMA engine buffers the data on its way to the device,
> and it's not clear from the description whether that is done in
> response to a request from the device or whether the data is prefetched.
> IOW, what the lifetime of the data in the dma engine is.
It's not clear from the information I have exactly when the interrupt
fires, only that it appears to be somewhat too early.
> It seems odd that the DMA engine provides no way to know whether the
> channel still contains data that is in-flight to the device, whether
> by interrupt (from the descriptions the IRQ is way too early) or by
> polling some status register within the DMA engine itself.
>
> If the delay is predictable, why not use a delayed workqueue or a
> hrtimer to wait a period after the IRQ before completing the DMA
> transaction? If it's not predictable and you haven't some status
> register in the DMA engine hardware that indicates whether there's
> remaining data, then the design really is screwed up, and I don't
> think there's a reasonable solution to the problem - anything
> would be a horrid hack that would be specific to this SoC.
This would hardly be the first screwed up hardware design. There is a
completion indicator, just not in the dma engine. For some idiotic
reason, the designers put this responsibility on the client devices and
their respective drivers.
> It would be unfair to augment the API and add the burden on everyone
> for the new API when 99.999% of the world doesn't require it.
I don't think making this particular dma driver wait for the descriptor
callback to return before reusing a channel quite amounts to a horrid
hack. It certainly wouldn't burden anyone other than the poor drivers
for devices connected to it, all of which are specific to Sigma AFAIK.
--
M?ns Rullg?rd
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Russell King - ARM Linux @ 2016-11-25 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xlgw78y8k.fsf@unicorn.mansr.com>
On Fri, Nov 25, 2016 at 01:50:35PM +0000, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> > It would be unfair to augment the API and add the burden on everyone
> > for the new API when 99.999% of the world doesn't require it.
>
> I don't think making this particular dma driver wait for the descriptor
> callback to return before reusing a channel quite amounts to a horrid
> hack. It certainly wouldn't burden anyone other than the poor drivers
> for devices connected to it, all of which are specific to Sigma AFAIK.
Except when you stop to think that delaying in a tasklet is exactly
the same as randomly delaying in an interrupt handler - the tasklet
runs on the return path back to the parent context of an interrupt
handler. Even if you sleep in the tasklet, you're sleeping on behalf
of the currently executing thread - if it's a RT thread, you effectively
destroy the RT-ness of the thread. Let's hope no one cares about RT
performance on that hardware...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125135830.GL14217@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> On Fri, Nov 25, 2016 at 01:50:35PM +0000, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>> > It would be unfair to augment the API and add the burden on everyone
>> > for the new API when 99.999% of the world doesn't require it.
>>
>> I don't think making this particular dma driver wait for the descriptor
>> callback to return before reusing a channel quite amounts to a horrid
>> hack. It certainly wouldn't burden anyone other than the poor drivers
>> for devices connected to it, all of which are specific to Sigma AFAIK.
>
> Except when you stop to think that delaying in a tasklet is exactly
> the same as randomly delaying in an interrupt handler - the tasklet
> runs on the return path back to the parent context of an interrupt
> handler. Even if you sleep in the tasklet, you're sleeping on behalf
> of the currently executing thread - if it's a RT thread, you effectively
> destroy the RT-ness of the thread. Let's hope no one cares about RT
> performance on that hardware...
That's why I suggested to do this only if the needed delay is known to
be no more than a few bus cycles. The completion callback is currently
the only post-transfer interaction we have between the dma and device
drivers. To handle an arbitrarily long delay, some new interface will
be required.
--
M?ns Rullg?rd
^ permalink raw reply
* [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Adrian Hunter @ 2016-11-25 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFr9uEjVQmTNP0KK8Zj9mxCW3i564E=47vTK0RLvXCjw3Q@mail.gmail.com>
On 24/11/16 15:34, Ulf Hansson wrote:
> On 24 November 2016 at 13:41, Ziji Hu <huziji@marvell.com> wrote:
>> On 2016/11/24 18:43, Ulf Hansson wrote:
>>> On 31 October 2016 at 12:09, Gregory CLEMENT
>>> <gregory.clement@free-electrons.com> wrote:
>>>> From: Ziji Hu <huziji@marvell.com>
>>>> +static int xenon_start_signal_voltage_switch(struct mmc_host *mmc,
>>>> + struct mmc_ios *ios)
>>>> +{
>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>> +
>>>> + /*
>>>> + * Before SD/SDIO set signal voltage, SD bus clock should be
>>>> + * disabled. However, sdhci_set_clock will also disable the Internal
>>>> + * clock in mmc_set_signal_voltage().
>>>
>>> If that's the case then that is wrong in the generic sdhci code.
>>> What's the reason why it can't be fixed there instead of having this
>>> workaround?
>>>
>> In my very own opinion, SD Spec doesn't specify whether SDCLK should be
>> enabled or not during power setting.
>> Enabling SDCLK might be a special condition only required by our SDHC.
>> I try to avoid breaking other vendors' SDHC functionality
>> if their SDHCs require SDCLK disabled.
>> Thus I prefer to keep it inside our SDHC driver.
>
> I let Adrian comment on this.
>
> For sure we should avoid breaking other sdhci variant, but on the
> other hand *if* the generic code is wrong we should fix it!
Yes, this looks like something that could perhaps be fixed in sdhci. I will
look into it.
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Mason @ 2016-11-25 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xa8cnai0p.fsf@unicorn.mansr.com>
On 25/11/2016 12:57, M?ns Rullg?rd wrote:
> The same DMA unit is also used for SATA, which is an off the shelf
> Designware controller with an in-kernel driver. This interrupt timing
> glitch can actually explain some intermittent errors I've observed with
> it.
FWIW, newer chips embed an AHCI controller, with a dedicated
memory channel.
FWIW2, the HW dev said memory channels are "almost free", and he
would have no problem giving each device their own private channel
read/write pair.
Regards.
^ permalink raw reply
* [PATCH] bus: imx-weim: Fix the "fsl,weim-cs-gpr" lookup method
From: Fabio Estevam @ 2016-11-25 14:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Commit 1be81ea5860744520 ("ARM: dts: imx6: Add imx-weim parameters to
dtsi's") causes the following probe error when the weim node is not
present on the board dts (such as imx6q-sabresd):
imx-weim 21b8000.weim: Invalid 'ranges' configuration
imx-weim: probe of 21b8000.weim failed with error
As the "fsl,weim-cs-gpr" property changed the location from the individual
board dts "&weim" node to the common dtsi node we can no longer reach it
via syscon_regmap_lookup_by_phandle(), so use
syscon_regmap_lookup_by_compatible() instead, which will successfully
find the "fsl,weim-cs-gpr" property.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
drivers/bus/imx-weim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index 4bd361d..9824c58 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -76,7 +76,7 @@ static int __init imx_weim_gpr_setup(struct platform_device *pdev)
int cs = 0;
int i = 0;
- gpr = syscon_regmap_lookup_by_phandle(np, "fsl,weim-cs-gpr");
+ gpr = syscon_regmap_lookup_by_compatible("fsl,weim-cs-gpr");
if (IS_ERR(gpr)) {
dev_dbg(&pdev->dev, "failed to find weim-cs-gpr\n");
return 0;
--
2.7.4
^ permalink raw reply related
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ae97a212-a91e-5e0a-c9b6-2dba3b79ddc5@free.fr>
Mason <slash.tmp@free.fr> writes:
> On 25/11/2016 12:57, M?ns Rullg?rd wrote:
>
>> The same DMA unit is also used for SATA, which is an off the shelf
>> Designware controller with an in-kernel driver. This interrupt timing
>> glitch can actually explain some intermittent errors I've observed with
>> it.
>
> FWIW, newer chips embed an AHCI controller, with a dedicated
> memory channel.
>
> FWIW2, the HW dev said memory channels are "almost free", and he
> would have no problem giving each device their own private channel
> read/write pair.
We still need to deal with the existing hardware.
--
M?ns Rullg?rd
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Russell King - ARM Linux @ 2016-11-25 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xh96v8xnb.fsf@unicorn.mansr.com>
On Fri, Nov 25, 2016 at 02:03:20PM +0000, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>
> > On Fri, Nov 25, 2016 at 01:50:35PM +0000, M?ns Rullg?rd wrote:
> >> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> >> > It would be unfair to augment the API and add the burden on everyone
> >> > for the new API when 99.999% of the world doesn't require it.
> >>
> >> I don't think making this particular dma driver wait for the descriptor
> >> callback to return before reusing a channel quite amounts to a horrid
> >> hack. It certainly wouldn't burden anyone other than the poor drivers
> >> for devices connected to it, all of which are specific to Sigma AFAIK.
> >
> > Except when you stop to think that delaying in a tasklet is exactly
> > the same as randomly delaying in an interrupt handler - the tasklet
> > runs on the return path back to the parent context of an interrupt
> > handler. Even if you sleep in the tasklet, you're sleeping on behalf
> > of the currently executing thread - if it's a RT thread, you effectively
> > destroy the RT-ness of the thread. Let's hope no one cares about RT
> > performance on that hardware...
>
> That's why I suggested to do this only if the needed delay is known to
> be no more than a few bus cycles. The completion callback is currently
> the only post-transfer interaction we have between the dma and device
> drivers. To handle an arbitrarily long delay, some new interface will
> be required.
And now we're back at the point I made a few emails ago about undue
burden which is just about quoted above...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] pinctrl: sx150x: use new nested IRQ infrastructure
From: Linus Walleij @ 2016-11-25 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Use the new gpiochip_irqchip_add_nested() and
gpiochip_set_nested_irqchip() calls to properly created
a nested irqchip and mark all child irqs properly with
their parent IRQ.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-sx150x.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 1a1c8b51a992..36cb0f1ed538 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -1219,9 +1219,9 @@ static int sx150x_probe(struct i2c_client *client,
* plus it will be instantly noticeable if it is ever
* called (should not happen)
*/
- ret = gpiochip_irqchip_add(&pctl->gpio,
- &pctl->irq_chip, 0,
- handle_bad_irq, IRQ_TYPE_NONE);
+ ret = gpiochip_irqchip_add_nested(&pctl->gpio,
+ &pctl->irq_chip, 0,
+ handle_bad_irq, IRQ_TYPE_NONE);
if (ret) {
dev_err(dev, "could not connect irqchip to gpiochip\n");
return ret;
@@ -1234,6 +1234,10 @@ static int sx150x_probe(struct i2c_client *client,
pctl->irq_chip.name, pctl);
if (ret < 0)
return ret;
+
+ gpiochip_set_nested_irqchip(&pctl->gpio,
+ &pctl->irq_chip,
+ client-irq);
}
/* Pinctrl_desc */
--
2.7.4
^ permalink raw reply related
* Tearing down DMA transfer setup after DMA client has finished
From: Mason @ 2016-11-25 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xpolj9021.fsf@unicorn.mansr.com>
On 25/11/2016 14:11, M?ns Rullg?rd wrote:
> Mason writes:
>
>> It seems there is a disconnect between what Linux expects - an IRQ
>> when the transfer is complete - and the quirks of this HW :-(
>>
>> On this system, there are MBUS "agents" connected via a "switch box".
>> An agent fires an IRQ when it has dealt with its *half* of the transfer.
>>
>> SOURCE_AGENT <---> SBOX <---> DESTINATION_AGENT
>>
>> Here are the steps for a transfer, in the general case:
>>
>> 1) setup the sbox to connect SOURCE TO DEST
>> 2) configure source to send N bytes
>> 3) configure dest to receive N bytes
>>
>> When SOURCE_AGENT has sent N bytes, it fires an IRQ
>> When DEST_AGENT has received N bytes, it fires an IRQ
>> The sbox connection can be torn down only when the destination
>> agent has received all bytes.
>> (And the twist is that some agents do not have an IRQ line.)
>>
>> The system provides 3 RAM-to-sbox agents (read channels)
>> and 3 sbox-to-RAM agents (write channels).
>>
>> The NAND Flash controller read and write agents do not have
>> IRQ lines.
>>
>> So for a NAND-to-memory transfer (read from device)
>> - nothing happens when the NFC has finished sending N bytes to the sbox
>> - the write channel fires an IRQ when it has received N bytes
>>
>> In that case, one IRQ fires when the transfer is complete,
>> like Linux expects.
>>
>> For a memory-to-NAND transfer (write to device)
>> - the read channel fires an IRQ when it has sent N bytes
>> - the NFC driver is supposed to poll the NFC to determine
>> when the controller has finished writing N bytes
>>
>> In that case, the IRQ does not indicate that the transfer
>> is complete, merely that the sending half has finished
>> its part.
>
> When does your NAND controller signal completion? When it has received
> the DMA data, or only when it has finished the actual write operation?
The NAND controller provides a STATUS register.
Bit 31 is the CMD_READY bit.
This bit goes to 0 when the controller is busy, and to 1
when the controller is ready to accept the next command.
The NFC driver is doing:
res = wait_for_completion_timeout(&tx_done, HZ);
if (res > 0)
err = readl_poll_timeout(addr, val, val & CMD_READY, 0, 1000);
So basically, sleep until the memory agent IRQ falls,
then spin until the controller is idle.
Did you see that adding a 10 ?s delay at the start of
tangox_dma_pchan_detach() makes the system no longer
fail (passes an mtd_speedtest).
>> I think it is possible to have a generic solution:
>> Right now, the callback is called from tasklet context.
>> If we can have a new flag to have the callback invoked
>> directly from the ISR, then the driver for the client
>> device can do what is required.
>
> No, that won't work. The callback shouldn't run in interrupt context.
What if the callback only spun for, at most, 10 ?s ?
readl_poll_timeout(addr, val, val & CMD_READY, 0, 10);
Regards.
^ permalink raw reply
* [PATCH v5 0/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-25 14:26 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This is basicly my v3 plus some of the changes that Tomas changed for
his RFC patch (implicitly "v4"). So compared to v3 the following
changed:
- Add more documentation (mostly from Tomas)
- Add more mbus ranges (by Tomas)
- Move link to schematic below copyright header (suggested by Andrew)
- reenable rtc as this is not that broken on production board
- fix spi chip select pinmuxing
Uwe Kleine-K?nig (2):
devicetree: Add vendor prefix for CZ.NIC
ARM: dts: add support for Turris Omnia
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 334 +++++++++++++++++++++
3 files changed, 336 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
--
2.10.2
^ permalink raw reply
* [PATCH v5 1/2] devicetree: Add vendor prefix for CZ.NIC
From: Uwe Kleine-König @ 2016-11-25 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125142658.21690-1-uwe@kleine-koenig.org>
Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..ae9fce9fed03 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -67,6 +67,7 @@ creative Creative Technology Ltd
crystalfontz Crystalfontz America, Inc.
cubietech Cubietech, Ltd.
cypress Cypress Semiconductor Corporation
+cznic CZ.NIC, z.s.p.o.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
--
2.10.2
^ permalink raw reply related
* [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-25 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125142658.21690-1-uwe@kleine-koenig.org>
This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.
Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 334 ++++++++++++++++++++++++++
2 files changed, 335 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..f1d3b9ff257e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
+ armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 000000000000..bcc10c285889
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,334 @@
+/*
+ * Device Tree file for the Turris Omnia
+ *
+ * Copyright (C) 2016 Uwe Kleine-K?nig <uwe@kleine-koenig.org>
+ * Copyright (C) 2016 Tomas Hlavacek <tmshlvkc@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+ model = "Turris Omnia";
+ compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>; /* 1024 MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
+ MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+ MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+
+ internal-regs {
+
+ /* USB part of the PCIe2/USB 2.0 port */
+ usb at 58000 {
+ status = "okay";
+ };
+
+ sata at a8000 {
+ status = "okay";
+ };
+
+ sdhci at d8000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhci_pins>;
+ status = "okay";
+
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ };
+
+ usb3 at f0000 {
+ status = "okay";
+ };
+
+ usb3 at f8000 {
+ status = "okay";
+ };
+ };
+
+ pcie-controller {
+ status = "okay";
+
+ pcie at 1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ pcie at 2,0 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+ };
+
+ pcie at 3,0 {
+ /* Port 2, Lane 0 */
+ status = "okay";
+ };
+ };
+ };
+};
+
+/* Connected to 88E6176 switch, port 6 */
+ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* Connected to 88E6176 switch, port 5 */
+ð1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge1_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* WAN port */
+ð2 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy = <&phy1>;
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ i2cmux at 70 {
+ compatible = "nxp,pca9547";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ status = "okay";
+
+ i2c at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ /* STM32F0 command interface at address 0x2a */
+ /* leds device (in STM32F0) at address 0x2b */
+
+ eeprom at 54 {
+ compatible = "at,24c64";
+ reg = <0x54>;
+
+ /* The EEPROM contains data for bootloader.
+ * Contents:
+ * struct omnia_eeprom {
+ * u32 magic; (=0x0341a034 in LE)
+ * u32 ramsize; (in GiB)
+ * char regdomain[4];
+ * u32 crc32;
+ * };
+ */
+ };
+ };
+
+ i2c at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ /* routed to PCIe0/mSATA connector (CN7A) */
+ };
+
+ i2c at 2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ /* routed to PCIe1/USB2 connector (CN61A) */
+ };
+
+ i2c at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ /* routed to PCIe2 connector (CN62A) */
+ };
+
+ i2c at 4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ /* routed to SFP+ */
+ };
+
+ i2c at 5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ /* ATSHA204A at address 0x64 */
+ };
+
+ i2c at 6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ /* exposed on pin header */
+ };
+
+ i2c at 7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ pcawan: gpio at 71 {
+ /*
+ * GPIO expander for SFP+ signals and
+ * and phy irq
+ */
+ compatible = "nxp,pca9538";
+ reg = <0x71>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcawan_pins>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
+};
+
+&mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ status = "okay";
+
+ phy1: phy at 1 {
+ status = "okay";
+ compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+
+ /* irq is connected to &pcawan pin 7 */
+ };
+
+ /* Switch MV88E7176 at address 0x10 */
+};
+
+&pinctrl {
+ pcawan_pins: pcawan-pins {
+ marvell,pins = "mpp46";
+ marvell,function = "gpio";
+ };
+
+ spi0cs0_pins: spi0cs0-pins {
+ marvell,pins = "mpp25";
+ marvell,function = "spi0";
+ };
+
+ spi0cs1_pins: spi0cs1-pins {
+ marvell,pins = "mpp26";
+ marvell,function = "spi0";
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins &spi0cs0_pins>;
+ status = "okay";
+
+ spi-nor at 0 {
+ compatible = "spansion,s25fl164k", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+
+ partition at 0 {
+ reg = <0x0 0x00100000>;
+ label = "U-Boot";
+ };
+
+ partition at 1 {
+ reg = <0x00100000 0x00700000>;
+ label = "Rescue system";
+ };
+ };
+
+ /* MISO, MOSI, SCLK and CS1 are routed to pin header CN11 */
+};
+
+&uart0 {
+ /* Pin header CN10 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart1 {
+ /* Pin header CN11 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "okay";
+};
--
2.10.2
^ permalink raw reply related
* Tearing down DMA transfer setup after DMA client has finished
From: Mason @ 2016-11-25 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xd1hj8x7i.fsf@unicorn.mansr.com>
On 25/11/2016 15:12, M?ns Rullg?rd wrote:
> Mason writes:
>
>> On 25/11/2016 12:57, M?ns Rullg?rd wrote:
>>
>>> The same DMA unit is also used for SATA, which is an off the shelf
>>> Designware controller with an in-kernel driver. This interrupt timing
>>> glitch can actually explain some intermittent errors I've observed with
>>> it.
>>
>> FWIW, newer chips embed an AHCI controller, with a dedicated
>> memory channel.
>>
>> FWIW2, the HW dev said memory channels are "almost free", and he
>> would have no problem giving each device their own private channel
>> read/write pair.
>
> We still need to deal with the existing hardware.
Can you confirm that your MBUS driver, in its current form,
does not support memcpy-type transfers, which generate two
IRQs (one from send agent, one from receive agent)?
Do you plan to support that, or is it just too quirky?
Regards.
^ permalink raw reply
* [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-25 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125142658.21690-3-uwe@kleine-koenig.org>
On Fri, Nov 25, 2016 at 03:26:58PM +0100, Uwe Kleine-K?nig wrote:
> This machine is an open hardware router by cz.nic driven by a
> Marvell Armada 385.
>
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v17 08/15] clocksource/drivers/arm_arch_timer: move arch_timer_needs_of_probing into DT init call
From: kbuild test robot @ 2016-11-25 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125084623.22515-9-fu.wei@linaro.org>
Hi Fu,
[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.9-rc6]
[cannot apply to tip/timers/core next-20161125]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/fu-wei-linaro-org/acpi-clocksource-add-GTDT-driver-and-GTDT-support-in-arm_arch_timer/20161125-171111
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: the linux-review/fu-wei-linaro-org/acpi-clocksource-add-GTDT-driver-and-GTDT-support-in-arm_arch_timer/20161125-171111 HEAD 498f1f2503da21841b0e7679ddbdb86a40451bdb builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_acpi_init':
>> drivers/clocksource/arm_arch_timer.c:1071:2: error: 'ret' undeclared (first use in this function)
ret = arch_timer_register();
^~~
drivers/clocksource/arm_arch_timer.c:1071:2: note: each undeclared identifier is reported only once for each function it appears in
vim +/ret +1071 drivers/clocksource/arm_arch_timer.c
1065 return -EINVAL;
1066 }
1067
1068 /* Always-on capability */
1069 arch_timer_c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
1070
> 1071 ret = arch_timer_register();
1072 if (ret)
1073 return ret;
1074
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 31917 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161125/cf2e05c2/attachment-0001.gz>
^ permalink raw reply
* [RFC PATCH] ARM: dts: Add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-25 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480078151.381.4@smtp.gmail.com>
Hello,
[trimmed Cc: a bit to annoy less]
On 11/25/2016 01:49 PM, Tomas Hlavacek wrote:
> 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.
To keep the dice rolling I sent a v5 with is somewhere in the middle
between my v3 and Tomas RFC patch. Assuming Tomas is happy with this
change, can we still get it into 4.10? This would help me to put this in
the Debian kernel for the next release.
>>> > 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.
Ack, the leds are one of the less critical things for the machine. I'd
like to tackle the switch next.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161125/05e21cc2/attachment.sig>
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-25 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28bb9925-d0d7-9261-27fb-aa79345a19f1@free.fr>
Mason <slash.tmp@free.fr> writes:
> On 25/11/2016 14:11, M?ns Rullg?rd wrote:
>
>> Mason writes:
>>
>>> It seems there is a disconnect between what Linux expects - an IRQ
>>> when the transfer is complete - and the quirks of this HW :-(
>>>
>>> On this system, there are MBUS "agents" connected via a "switch box".
>>> An agent fires an IRQ when it has dealt with its *half* of the transfer.
>>>
>>> SOURCE_AGENT <---> SBOX <---> DESTINATION_AGENT
>>>
>>> Here are the steps for a transfer, in the general case:
>>>
>>> 1) setup the sbox to connect SOURCE TO DEST
>>> 2) configure source to send N bytes
>>> 3) configure dest to receive N bytes
>>>
>>> When SOURCE_AGENT has sent N bytes, it fires an IRQ
>>> When DEST_AGENT has received N bytes, it fires an IRQ
>>> The sbox connection can be torn down only when the destination
>>> agent has received all bytes.
>>> (And the twist is that some agents do not have an IRQ line.)
>>>
>>> The system provides 3 RAM-to-sbox agents (read channels)
>>> and 3 sbox-to-RAM agents (write channels).
>>>
>>> The NAND Flash controller read and write agents do not have
>>> IRQ lines.
>>>
>>> So for a NAND-to-memory transfer (read from device)
>>> - nothing happens when the NFC has finished sending N bytes to the sbox
>>> - the write channel fires an IRQ when it has received N bytes
>>>
>>> In that case, one IRQ fires when the transfer is complete,
>>> like Linux expects.
>>>
>>> For a memory-to-NAND transfer (write to device)
>>> - the read channel fires an IRQ when it has sent N bytes
>>> - the NFC driver is supposed to poll the NFC to determine
>>> when the controller has finished writing N bytes
>>>
>>> In that case, the IRQ does not indicate that the transfer
>>> is complete, merely that the sending half has finished
>>> its part.
>>
>> When does your NAND controller signal completion? When it has received
>> the DMA data, or only when it has finished the actual write operation?
>
> The NAND controller provides a STATUS register.
> Bit 31 is the CMD_READY bit.
> This bit goes to 0 when the controller is busy, and to 1
> when the controller is ready to accept the next command.
>
> The NFC driver is doing:
>
> res = wait_for_completion_timeout(&tx_done, HZ);
> if (res > 0)
> err = readl_poll_timeout(addr, val, val & CMD_READY, 0, 1000);
>
> So basically, sleep until the memory agent IRQ falls,
> then spin until the controller is idle.
This doesn't answer my question. Waiting for the entire operation to
finish isn't necessary. The dma driver only needs to wait until all the
data has been received by the nand controller, not until the controller
is completely finished with the command. Does the nand controller
provide an indication for completion of the dma independently of the
progress of the write command? The dma glue Sigma added to the
Designware sata controller does this.
> Did you see that adding a 10 ?s delay at the start of
> tangox_dma_pchan_detach() makes the system no longer
> fail (passes an mtd_speedtest).
Yes, but maybe that's much longer than is actually necessary.
>>> I think it is possible to have a generic solution:
>>> Right now, the callback is called from tasklet context.
>>> If we can have a new flag to have the callback invoked
>>> directly from the ISR, then the driver for the client
>>> device can do what is required.
>>
>> No, that won't work. The callback shouldn't run in interrupt context.
>
> What if the callback only spun for, at most, 10 ?s ?
>
> readl_poll_timeout(addr, val, val & CMD_READY, 0, 10);
That's far too long to wait in interrupt of tasklet context.
--
M?ns Rullg?rd
^ 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