Am Mittwoch, den 05.08.2015, 18:31 +0900 schrieb Jiada Wang:
> Hi Lucas
>
> On 08/05/2015 06:21 PM, Lucas Stach wrote:
> > Am Mittwoch, den 05.08.2015, 18:09 +0900 schrieb Jiada Wang:
> >> Hello Lucas
> >>
> >> On 08/03/2015 07:37 PM, Lucas Stach wrote:
> >>> Hello Dirk,
> >>>
> >>> Am Freitag, den 31.07.2015, 10:13 +0200 schrieb Dirk Behme:
> >>>> On 31.07.2015 09:40, Lucas Stach wrote:
> >>>>> Hi Dirk,
> >>>>>
> >>>>> Am Freitag, den 31.07.2015, 08:40 +0200 schrieb Dirk Behme:
> >>>>>> On 19.05.2015 14:16, Fabio Estevam wrote:
> >>>>>>> Hi Philipp,
> >>>>>>>
> >>>>>>> On Tue, May 19, 2015 at 5:54 AM, Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote:
> >>>>>>>> The driver configures the IDLE condition to interrupt the SDMA engine.
> >>>>>>>> Since the SDMA UART ROM script doesn't clear the IDLE bit itself, this
> >>>>>>>> caused repeated 1-byte DMA transfers, regardless of available data in the
> >>>>>>>> RX FIFO. Also, when returning due to the IDLE condition, the UART ROM
> >>>>>>>> script already increased its counter, causing residue to be off by one.
> >>>>>>>>
> >>>>>>>> This patch clears the IDLE condition to avoid repeated 1-byte DMA transfers
> >>>>>>>> and decreases count by when the DMA transfer was aborted due to the IDLE
> >>>>>>>> condition, fixing serial transfers using DMA on i.MX6Q.
> >>>>>>>>
> >>>>>>>> Reported-by: Peter Seiderer <ps.report@xxxxxxx>
> >>>>>>>> Signed-off-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>
> >>>>>>>
> >>>>>>> Thanks for the fix. Tested on a imx6sl-warp, where I could not use DMA
> >>>>>>> to access a Bluetooth device using the ROM SDMA firmware.
> >>>>>>>
> >>>>>>> Tested-by: Fabio Estevam <fabio.estevam@xxxxxxxxxxxxx>
> >>>>>>>
> >>>>>>> Could you please also Cc stable?
> >>>>>>
> >>>>>>
> >>>>>> Just fyi: We got this patch via -stable, and found that it results in
> >>>>>> issues for us. So we had to revert it in our local tree.
> >>>>>>
> >>>>>> We are using the DMA with baud rates > 2Mbit/s. Having a quick look at
> >>>>>> the registers in the ARM Reference Manual, USR2_IDLE seems to be a flag
> >>>>>> that is set when the RX line has been idle for at least a defined amount
> >>>>>> of time.
> >>>>>>
> >>>>>> For us this commit is dangerous because it fails to check whether the
> >>>>>> IDLE CONDITION feature is being used. We don't use the RX IDLE CONDITION
> >>>>>> feature, therefore it is likely to cause the last received character to
> >>>>>> be discarded causing corruption of data.
> >>>>>>
> >>>>> >From your description it's not clear to me why this commit is causing
> >>>>> issues for you. The idle condition signaling is automatically enabled
> >>>>> when using DMA.
> >>>>>
> >>>>> The idle signaling should only ever fire if the line has been idle for
> >>>>> 32byte durations. The aging timer, that expires after data is sitting in
> >>>>> the FIFO for 8 byte durations, should have flushed out all data at this
> >>>>> point.
> >>>>>
> >>>>> Do you use a RAM SDMA firmware or do you rely on the internal one.
> >>>>
> >>>> To my understanding we are using a RAM SDMA firmware. If I read the
> >>>> various mailing list thread correctly, the difference between the RAM
> >>>> SDMA firmware and the internal one was already often a root cause for
> >>>> different behavior.
> >>>>
> >>> Can you please check that the attached patches fix the problem for your
> >>> use-case? They correct the DMA setup to not use the idle condition
> >>> detect at all and instead fix the aging timer to work properly.
> >>>
> >>> That's what the reference manual says how things should be done. This
> >>> should work both with and without external SDMA firmware, but I only
> >>> tested the ROM firmware case so far.
> >>
> >> I did some tests with your patch set,
> >> and found some issues
> >>
> >> 1. imx_setup_ufcr() in imx_poll_init() is not updated to have new
> >> parameters, which cause compile failure
> >>
> > Thanks, will fix.
> >
> >> 2. in RX DMA, rx_watermark is set to RXTL_DMA (9), so USR1_RRDY will be
> >> set only when data in RXFIFO is above 9, this means no rx_dma
> >> transfer will occur, when only data size below 9 is received
> >>
> > This is not true, at least with the ROM firmware.
> >
> > If there are bytes sitting idle in the FIFO for 8 byte lengths without
> > reaching the watermark level the aging timer will trigger a DMA request.
> > In this case the SDMA script will drain the FIFO and signal DMA
> > completion.
> >
> > This is the documented behavior of the SDMA script and works as expected
> > with the ROM firmware, if it doesn't work with the RAM firmware then
> > this one is seriously broken.
> Yes, what you have mentioned is correct,
> but the issue is, in imx_int(),
> ...
> if (sts & USR1_RRDY) {
> if (sport->dma_is_enabled)
> imx_dma_rxint(sport);
> else
> imx_rxint(irq, dev_id);
> }
> ...
> uart driver will call imx_dma_rxint(), only when USR1_RRDY is set,
> IMO, in order to support AGTIM, USR1_AGTIM flag need to be checked as
> well, otherwise imx_dma_rxint() won't be called.
>
> >
> >> 3. as DMA Idle detected interrupt is disabled, so RX DMA will always
> >> waiting for data, if there is no data coming, please notice AGTIM bit
> >> will be set when at least one data is in RXFIFO
> >>
> > The serial core triggers a DMA request at the same time it sets the
> > AGTIM bit, there is no need to use the idle detection logic and in fact
> > the reference manual states that idle detection should not be used when
> > using the SDMA to fetch the data.
> >
> Current implementation of dma_rx_callback() is,
> ...
> if (count) {
> // continue rx dma
> } else {
> // rx dma done
> }
> ...
> as a end condition for RX DMA, UART driver will fire a RX DMA
> transaction, only when the 'count' is 0, rx_callback will finish RX DMA,
> in this case AGTIM flag won't be set, thus serial core won't trigger DMA
> request. so in order to remove idle detection logic,
> rx_callback need to be updated as well.
>
Oh, right.
While I think it would make sense to just always have a RX DMA pending
as long as the device is open and not wait for the serial DMA IRQ to
start the transfer, that can be addressed separately.
Your analysis is correct and I will adapt the patches accordingly.
Thanks for testing.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
