Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1331743 > unrolled thread

Re: commit 271e1b86e691 is breaking DMA uart on SoCFPGA

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: commit 271e1b86e691 is breaking DMA uart on SoCFPGA Vinod Koul <vinod.koul@intel.com> - 2016-02-11 10:00 +0100
    Re: commit 271e1b86e691 is breaking DMA uart on SoCFPGA Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> - 2016-02-17 12:20 +0100
      Re: commit 271e1b86e691 is breaking DMA uart on SoCFPGA Alexander Kochetkov <al.kochet@gmail.com> - 2016-02-18 17:10 +0100
      Re: commit 271e1b86e691 is breaking DMA uart on SoCFPGA Alexander Kochetkov <al.kochet@gmail.com> - 2016-02-19 08:00 +0100

#1331743 — Re: commit 271e1b86e691 is breaking DMA uart on SoCFPGA

On Wed, Feb 10, 2016 at 03:56:17PM -0600, Dinh Nguyen wrote:
> Hi Vinod,
> 
> It appears that commit 271e1b86e691 "dmaengine: pl330: add quirk for
> broken no flushp" is breaking uart dma on SoCFPGA. This commit is in
> linux-next(next-20160210).
> 
> Doing a bisect pointed to commit 271e1b86e691, but I had to also revert
> the following commits (86a8ce7d4103 "dmaengine: pl330: add max burst for
> dmaengine") and (848e9776fee4 "dmaengine: pl330: support burst mode for
> dev-to-mem and mem-to-dev transmit") as well because the build would
> fail if I only revert 271e1b86e691.
> 
> The SoCFPGA platform is being tested on Olof's board farm and is failing
> multi_v7_defconfig build because the PL330 DMA is enabled in this defconfig.
> 
> After doing reverts of those 3 commits, the socfpga platform is able
> boot completely again with multi_v7_defconfig.

Okay I am removing this topic from next. Also I can drop the series unless
someone sends me a fix in couple of days..

Thanks
-- 
~Vinod

[toc] | [next] | [standalone]

#1336264

Hi,

On Thursday, February 11, 2016 02:27:51 PM Vinod Koul wrote:
> On Wed, Feb 10, 2016 at 03:56:17PM -0600, Dinh Nguyen wrote:
> > Hi Vinod,
> > 
> > It appears that commit 271e1b86e691 "dmaengine: pl330: add quirk for
> > broken no flushp" is breaking uart dma on SoCFPGA. This commit is in
> > linux-next(next-20160210).
> > 
> > Doing a bisect pointed to commit 271e1b86e691, but I had to also revert
> > the following commits (86a8ce7d4103 "dmaengine: pl330: add max burst for
> > dmaengine") and (848e9776fee4 "dmaengine: pl330: support burst mode for
> > dev-to-mem and mem-to-dev transmit") as well because the build would
> > fail if I only revert 271e1b86e691.
> > 
> > The SoCFPGA platform is being tested on Olof's board farm and is failing
> > multi_v7_defconfig build because the PL330 DMA is enabled in this defconfig.
> > 
> > After doing reverts of those 3 commits, the socfpga platform is able
> > boot completely again with multi_v7_defconfig.
> 
> Okay I am removing this topic from next. Also I can drop the series unless
> someone sends me a fix in couple of days..

I've noticed that these commits also break UART DMA on Samsung Exynos4412
SoCs (I got similar bisection results as Dinh when I've noticed issue
with next-20160211 kernel).

Caesar, please keep me on Cc: for potential fix(es) / revised patches
(I'll be happy to test them).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

[toc] | [prev] | [next] | [standalone]

#1337489

Hello!

Bartlomiej, could you please tell what uart driver is used on Samsung
Exynos4412?
Dinh, could you please tell what uart driver is used on SoCFPGA?

Could you make two test?

1) Checkout tree at commit 848e9776fee4 "dmaengine: pl330: support
burst mode for
 dev-to-mem and mem-to-dev transmit", make it buildable and see is it
works. In order to make in buildable remove bursts argument from the
line:

    if (*bursts == 1)
    - return _bursts(pl330, dry_run, buf, pxs, 1);
    + return _bursts(dry_run, buf, pxs, 1);

2) Checkout next-20160211 kernel tree and set src_maxburst and
dst_maxburst to 1 inside UART driver to see is it works?

Regards,
Alexander.

[toc] | [prev] | [next] | [standalone]

#1337933

Hello, here comments from Shawn Lin:

19 февр. 2016 г., в 9:46, Shawn Lin <shawn.lin@kernel-upstream.org> написал(а):

Seriously review the patch again, commit 271e1b86e691 "dmaengine:
pl330: add quirk for broken no flushp" has not chance to break
the platforms which don't add quirk inside the dts stuff.
as well as the other works from rockchip.

But refer to Boojin Kim's patch,
dmaengine: pl330: support burst mode for dev-to-mem and mem-to-dev transmit

may some platforms can't support multi-burst? If that's the case,
the been-broken driver should limit the maxburst.

2016-02-17 14:12 GMT+03:00 Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>:
>
> Hi,
>
> On Thursday, February 11, 2016 02:27:51 PM Vinod Koul wrote:
>> On Wed, Feb 10, 2016 at 03:56:17PM -0600, Dinh Nguyen wrote:
>> > Hi Vinod,
>> >
>> > It appears that commit 271e1b86e691 "dmaengine: pl330: add quirk for
>> > broken no flushp" is breaking uart dma on SoCFPGA. This commit is in
>> > linux-next(next-20160210).
>> >
>> > Doing a bisect pointed to commit 271e1b86e691, but I had to also revert
>> > the following commits (86a8ce7d4103 "dmaengine: pl330: add max burst for
>> > dmaengine") and (848e9776fee4 "dmaengine: pl330: support burst mode for
>> > dev-to-mem and mem-to-dev transmit") as well because the build would
>> > fail if I only revert 271e1b86e691.
>> >
>> > The SoCFPGA platform is being tested on Olof's board farm and is failing
>> > multi_v7_defconfig build because the PL330 DMA is enabled in this defconfig.
>> >
>> > After doing reverts of those 3 commits, the socfpga platform is able
>> > boot completely again with multi_v7_defconfig.
>>
>> Okay I am removing this topic from next. Also I can drop the series unless
>> someone sends me a fix in couple of days..
>
> I've noticed that these commits also break UART DMA on Samsung Exynos4412
> SoCs (I got similar bisection results as Dinh when I've noticed issue
> with next-20160211 kernel).
>
> Caesar, please keep me on Cc: for potential fix(es) / revised patches
> (I'll be happy to test them).
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web