With CONFIG_MMCSD_MULTIBLOCK_LIMIT not set. (No limit)
The DMA driver would overwrite the internal buffer.
By adding CONFIG_ARCH_HAVE_SDIO_PREFLIGHT and
CONFIG_FAT_DMAMEMORY we can insure alignment and
maximize performance using no CONFIG_MMCSD_MULTIBLOCK_LIMIT
If a TX DMA completion interrups a forground write.
The TX DMA completion can start a dma_send and it will
then followed by the forground write's dma_send
stoping the,then in progress DMA.
By atomicaly marking the tx dma busy, the forground
write will not perform the dma_send, and will only
enqueue the data. At the next TX dma completion any
data pending in the tx queue will be sent
The 1170 usage of the GPR registers is to select the
between GPIO{2|3} or CM7_GPIO{2|3} where as the 1060
it selected ports between 1-6,2-7..4-9 and uses
different GPR registers.
For the 1170 we are defaulting to GPIO{2|3} and not
supporting the swtich to CM7_GPIO{2|3}.
Fixes is stuttering output.
The use of the semaphore was causing blocking
on non blocking callers. This ensured that
the TX DAM would be restated, but when it
was switched to trywait in 660ac6, it left
data in the xmit queue unsent.
This solution removes the semaphore and restart
the DMA on completion if there is more data in
the xmit queue to be sent.
Fixes stuttering output.
The use of the semaphore was causing blocking
on non blocking callers. This ensured that
the TX DAM would be restated, but when it
was switched to trywait in 8362e314, it left
data in the xmit queue unsent.
This solution removes the semaphore and restart
the DMA on completion if there is more data in
the xmit queue to be sent.
This prevents dma stop operations called of a completion
call back from rentering, the callback and ensures that
the call back will see the idle state.
If using flow control with a high CTS the thread may be
blocked forever on the second transmit attempt due to waiting
on the txdma semaphore. The calling thread can then never
make progress and release any resources it has taken, thus
may cause a deadlock in other parts of the system.
The implementation differs in behavior from interrupt-driven
TX. It should not implicitly wait on a taken semaphore but
return immediately and let the upper layers decide on what to
do next.
If using flow control with a high CTS the thread may be
blocked forever on the second transmit attempt due to waiting
on the txdma semaphore. The calling thread can then never
make progress and release any resources it has taken, thus
may cause a deadlock in other parts of the system.
The implementation differs in behavior from interrupt-driven
TX. It should not implicitly wait on a taken semaphore but
return immediately and let the upper layers decide on what to
do next.
If using flow control with a high CTS the thread may be
blocked forever on the second transmit attempt due to waiting
on the txdma semaphore. The calling thread can then never
make progress and release any resources it has taken, thus
may cause a deadlock in other parts of the system.
The implementation differs in behavior from interrupt-driven
TX. It should not implicitly wait on a taken semaphore but
return immediately and let the upper layers decide on what to
do next.
With TCD set to loop, there is a window where the
DMA has raised Done, but not reloaded the TCD, resetting
count and clearing Done.
In this window imxrt_dmach_getcount could then return 0.
Resulting in imxrt_dma_nextrx returning RXDMA_BUFFER_SIZE.
Which is not a valid index in the FIFO.
Since the count will be set to RXDMA_BUFFER_SIZE. When the DMA
engine completes the TCD reload. The imxrt_dma_nextrx would
return 0. Therefore:
(RXDMA_BUFFER_SIZE - dmaresidual) % RXDMA_BUFFER_SIZE
accomplishes this.
With TCD set to loop, there is a window where the
DMA has raised Done, but not reloaded the TCD, resetting
count and clearing Done.
In this window imxrt_dmach_getcount could then return 0.
Resulting in imxrt_dma_nextrx returning RXDMA_BUFFER_SIZE.
Which is not a valid index in the FIFO.
Since the count will be set to RXDMA_BUFFER_SIZE. When the DMA
engine completes the TCD reload. The imxrt_dma_nextrx would
return 0. Therefore:
(RXDMA_BUFFER_SIZE - dmaresidual) % RXDMA_BUFFER_SIZE
accomplishes this.
With TCD set to loop, there is a window where the
DMA has raised Done, but not reloaded the TCD, resetting
count and clearing Done.
In this window imxrt_dmach_getcount could then return 0.
Resulting in imxrt_dma_nextrx returning RXDMA_BUFFER_SIZE.
Which is not a valid index in the FIFO.
Since the count will be set to RXDMA_BUFFER_SIZE. When the DMA
engine completes the TCD reload. The imxrt_dma_nextrx would
return 0. Therefore:
(RXDMA_BUFFER_SIZE - dmaresidual) % RXDMA_BUFFER_SIZE
accomplishes this.
With DMA enabled on some I2C channels but not all
the Non DMA channels were failing.
The cause was condition the status with only the enabled
interrupts on non DMA chennels. This conditioning needs
to only happen in DMA enabled channels
With DMA enabled on some I2C channels but not all
the Non DMA channels were failing.
The cause was condition the status with only the enabled
interrupts on non DMA chennels. This conditioning needs
to only happen in DMA enabled channels
With DMA enabled on some I2C channels but not all
the Non DMA channels were failing.
The cause was condition the status with only the enabled
interrupts on non DMA chennels. This conditioning needs
to only happen in DMA enabled channels
The DMA can bring in more rx data, than the number of
DMA completions call backs. The call back happen on
idle, 1/2 and full events. But in between these events
the DMA can write more data to the buffers memory that
need to be brought in to the cache. (invalidate)
We do the invalidate on the reads from the fifo memory
if the the DMA as commited since the last read.
If the CONFIG_MMCSD_SDIOWAIT_WRCOMPLETE is enabled and the
card is found to be ready in the waitenable call. Then
we do not need a Watchdog nor to configure the pin for
IRQ to detect ready.
This was reported as an error, and it is not, it simply means
we do not have to wait.
Pinmaps should not have contained GPIO_SPEED_xxx settings and
all pins should have had suffixes to allow any pins attributes to
be set. This is board dependent.
This change adds CONFIG_STM32L5_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps with suffixes.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32L5_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32L5_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings and
all pins should have had suffixes to allow any pins attributes to
be set. This is board dependent.
This change adds CONFIG_STM32WB_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps with suffixes.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32WB_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32WB_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32F0G0L0_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32F0G0L0_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32F0G0L0_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32L4_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32L4_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32L4_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
replace all GPIO_MODE_xxMHz with GPIO_MODE_2MHz provide GPIO_ADJUST_MODE
and add legacy pinmap
For the stm32F1 pinmaps should not have contained GPIO_MODE_50MHz settings
on all pins. Speed is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps that can have the GPIO_MODE_xxMHz set.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h, and use all the defconfigs with the legacy
pinmap and output the required changes that one needs to make to a board.h
file.
Eventually, CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.hf1
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32F7_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32F7_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32F7_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32H7_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32H7_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32H7_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
mmcsd_removed will be called if the card is in invalid state.
This can happen if the card is bad, or vibrations causes a power
loss.
mmcsd_removed resets:
priv->capacity = 0; /* Capacity=0 sometimes means no media */
priv->blocksize = 0;
priv->probed = false;
priv->mediachanged = false;
priv->wrbusy = false;
priv->type = MMCSD_CARDTYPE_UNKNOWN;
priv->rca = 0;
priv->selblocklen = 0;
priv->widebus = false;
If blocksize is set to 0 will cause the log2 to result
in an infinate loop in some drivers.
IS_EMPTY will check for priv->type = MMCSD_CARDTYPE_UNKNOWN
and return ENODEV.
Not all boards have an interrupt line from the phy to
the Soc. This commit allows the phy to be polled for
link status.
This may not work on all MAC/PHY combination that
have mutually exclusive link management and operating
modes. The STM32H7 and LAN8742AI do not have such a
limitation.
Fix typos
The IDMA needs to have 32 bit word alignment, in fact it will
AND off the lower 2 bits of the value stored in IDMABASE0R.
This bug was masked by CONFIG_ARMV7M_DCACHE causing proper word alignment
and also FAT_DMAMEMORY being aligned.
This commit extends the unaligned logic (used for dcache) to take into account
the need for a buffer copy when the buffer is ot 32 bit word.
It leverages the fact that when CONFIG_ARMV7M_DCACHE is not defined the up_xxxxx_dcache are nops.
Kientis:edma Cleanup
Kinetis:EDMA Interrupt on last TCD
Kintis:edma remove dcache operations on passed data
Data can be chained in TCD and both read and write
can be in the chain. So the dmach ttype is not
relevent for all; the TCDs. Therefor we only perform
dcache operations on internal strutures, The caller
must perform dcache operations on their data.
kinetis:EDMA TCD Alignment of 32 Bytes to support Scatter/Gather
