Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1292639 > unrolled thread
| Started by | Mans Rullgard <mans@mansr.com> |
|---|---|
| First post | 2015-12-16 00:30 +0100 |
| Last post | 2015-12-17 16:00 +0100 |
| Articles | 20 on this page of 88 — 6 participants |
Back to article view | Back to linux.kernel
[PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Mans Rullgard <mans@mansr.com> - 2015-12-16 00:30 +0100
[PATCH 3/3] ata: sata_dwc_460ex: get rid of global data Mans Rullgard <mans@mansr.com> - 2015-12-16 00:30 +0100
Re: [PATCH 3/3] ata: sata_dwc_460ex: get rid of global data Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-17 16:10 +0100
Re: [PATCH 3/3] ata: sata_dwc_460ex: get rid of global data Måns Rullgård <mans@mansr.com> - 2015-12-17 16:20 +0100
Re: [PATCH 3/3] ata: sata_dwc_460ex: get rid of global data Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-17 16:40 +0100
Re: [PATCH 3/3] ata: sata_dwc_460ex: get rid of global data Måns Rullgård <mans@mansr.com> - 2015-12-17 17:00 +0100
[PATCH 2/3] ata: sata_dwc_460ex: add phy support Mans Rullgard <mans@mansr.com> - 2015-12-16 00:30 +0100
Re: [PATCH 2/3] ata: sata_dwc_460ex: add phy support Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2015-12-16 12:20 +0100
Re: [PATCH 2/3] ata: sata_dwc_460ex: add phy support Måns Rullgård <mans@mansr.com> - 2015-12-16 12:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-16 00:40 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-17 16:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-17 16:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-17 17:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-17 17:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-17 18:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-17 19:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-17 20:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-18 02:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-18 02:40 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-18 11:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-18 12:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-18 12:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-18 13:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-18 13:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-18 13:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-18 18:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-18 19:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-18 23:40 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-19 00:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-19 03:40 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-19 16:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-19 17:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-19 18:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-19 18:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-19 18:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-19 18:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-19 18:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-19 20:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-19 21:40 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-19 21:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-19 21:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-20 18:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-20 18:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-20 19:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-20 19:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-20 21:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-20 22:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 02:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-21 20:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 20:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-21 22:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 22:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-22 01:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-22 12:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-21 18:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-21 18:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-21 19:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 19:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 19:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-21 20:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 20:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-21 20:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-21 20:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-21 21:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-21 21:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 21:40 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-21 19:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 01:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 02:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 02:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-21 09:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 13:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-21 18:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 19:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-21 20:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 21:00 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 13:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-21 14:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 16:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-21 17:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-21 19:20 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-18 13:40 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-18 13:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-18 15:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Måns Rullgård <mans@mansr.com> - 2015-12-18 15:30 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-18 13:50 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Julian Margetson <runaway@candw.ms> - 2015-12-17 19:10 +0100
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-17 16:00 +0100
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-12-21 20:30 +0100 |
| Message-ID | <qIejE-28Y-27@gated-at.bofh.it> |
| In reply to | #1296139 |
Julian Margetson <runaway@candw.ms> writes: > On 12/21/2015 2:27 PM, Måns Rullgård wrote: >> Julian Margetson <runaway@candw.ms> writes: >> >>> On 12/21/2015 1:55 PM, Andy Shevchenko wrote: >>>> On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson <runaway@candw.ms> wrote: >>>>> On 12/21/2015 12:48 PM, Andy Shevchenko wrote: >>>>>> On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote: >>>>>>> On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko >>>>>>> <andy.shevchenko@gmail.com> wrote: >>>>>>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> >>>>>>>> wrote: >>>>>>>> I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32 >>>>>>>> items on this board, however registers for SATA program it to 64. I >>>>>>>> remember that I got no interrupt when I programmed transfer width >>>>>>>> wrongly (64 bits against 32 bits) when I ported dw_dmac to be used >>>>>>>> on >>>>>>>> Intel SoCs. >>>>>>> One more thing, I have a patch to monitor DMA IO, we may check what >>>>>>> exactly the values are written / read in DMA. I can share it >>>>>>> tomorrow. >>>>>> As promised the patch I have to debug IO of DW DMA. Didn't check though >>>>>> if it applies cleanly on top of recent vanilla kernel. >>>> So, the original driver (with patch from Måns) works, right? >>>> >>> The hard drive is recognized . >>> These system gets unresponsive with USB devices like the mouse and >>> keyboard not responding when I start Gparted. >> Did you disable the SATA and DMA debug messages? >> > It is working. That's good news. Thanks a lot for helping to test this. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Julian Margetson <runaway@candw.ms> |
|---|---|
| Date | 2015-12-21 20:50 +0100 |
| Subject | Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel |
| Message-ID | <qIeCZ-2hx-3@gated-at.bofh.it> |
| In reply to | #1296166 |
On 12/21/2015 3:27 PM, Måns Rullgård wrote: > Julian Margetson <runaway@candw.ms> writes: > >> On 12/21/2015 2:27 PM, Måns Rullgård wrote: >>> Julian Margetson <runaway@candw.ms> writes: >>> >>>> On 12/21/2015 1:55 PM, Andy Shevchenko wrote: >>>>> On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson <runaway@candw.ms> wrote: >>>>>> On 12/21/2015 12:48 PM, Andy Shevchenko wrote: >>>>>>> On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote: >>>>>>>> On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko >>>>>>>> <andy.shevchenko@gmail.com> wrote: >>>>>>>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> >>>>>>>>> wrote: >>>>>>>>> I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32 >>>>>>>>> items on this board, however registers for SATA program it to 64. I >>>>>>>>> remember that I got no interrupt when I programmed transfer width >>>>>>>>> wrongly (64 bits against 32 bits) when I ported dw_dmac to be used >>>>>>>>> on >>>>>>>>> Intel SoCs. >>>>>>>> One more thing, I have a patch to monitor DMA IO, we may check what >>>>>>>> exactly the values are written / read in DMA. I can share it >>>>>>>> tomorrow. >>>>>>> As promised the patch I have to debug IO of DW DMA. Didn't check though >>>>>>> if it applies cleanly on top of recent vanilla kernel. >>>>> So, the original driver (with patch from Måns) works, right? >>>>> >>>> The hard drive is recognized . >>>> These system gets unresponsive with USB devices like the mouse and >>>> keyboard not responding when I start Gparted. >>> Did you disable the SATA and DMA debug messages? >>> >> It is working. > That's good news. Thanks a lot for helping to test this. > No problem. If you can influence anyone of the radeon guys to have a look at the ring test failure on the Sam460ex again, I will be happy to help test in that area as well . http://lists.freedesktop.org/archives/dri-devel/2013-September/045050.html https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-February/125060.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Julian Margetson <runaway@candw.ms> |
|---|---|
| Date | 2015-12-21 20:30 +0100 |
| Subject | Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel |
| Message-ID | <qIejE-28Y-29@gated-at.bofh.it> |
| In reply to | #1296139 |
On 12/21/2015 2:27 PM, Måns Rullgård wrote: > Julian Margetson <runaway@candw.ms> writes: > >> On 12/21/2015 1:55 PM, Andy Shevchenko wrote: >>> On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson <runaway@candw.ms> wrote: >>>> On 12/21/2015 12:48 PM, Andy Shevchenko wrote: >>>>> On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote: >>>>>> On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko >>>>>> <andy.shevchenko@gmail.com> wrote: >>>>>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> >>>>>>> wrote: >>>>>>> I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32 >>>>>>> items on this board, however registers for SATA program it to 64. I >>>>>>> remember that I got no interrupt when I programmed transfer width >>>>>>> wrongly (64 bits against 32 bits) when I ported dw_dmac to be used >>>>>>> on >>>>>>> Intel SoCs. >>>>>> One more thing, I have a patch to monitor DMA IO, we may check what >>>>>> exactly the values are written / read in DMA. I can share it >>>>>> tomorrow. >>>>> As promised the patch I have to debug IO of DW DMA. Didn't check though >>>>> if it applies cleanly on top of recent vanilla kernel. >>> So, the original driver (with patch from Måns) works, right? >>> >> The hard drive is recognized . >> These system gets unresponsive with USB devices like the mouse and >> keyboard not responding when I start Gparted. > Did you disable the SATA and DMA debug messages? > It is working. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Julian Margetson <runaway@candw.ms> |
|---|---|
| Date | 2015-12-21 21:30 +0100 |
| Subject | Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel |
| Message-ID | <qIffI-2KY-11@gated-at.bofh.it> |
| In reply to | #1296169 |
On 12/21/2015 4:25 PM, Andy Shevchenko wrote: > On Mon, 2015-12-21 at 15:19 -0400, Julian Margetson wrote: >> On 12/21/2015 2:27 PM, Måns Rullgård wrote: >>> The hard drive is recognized . >>>> These system gets unresponsive with USB devices like the mouse >>>> and >>>> keyboard not responding when I start Gparted. >>> Did you disable the SATA and DMA debug messages? >>> >> It is working. > Indeed, thanks, Julian! > > I might ask you to test my branch with set of patches when it will be > ready (apparently after Xmas) if you are okay with that. > > Måns, also I would ask you to test on your hardware (AVR32) as well if > you have no objections. > I have no problem testing. Regards Julian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
|---|---|
| Date | 2015-12-21 21:30 +0100 |
| Subject | Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel |
| Message-ID | <qIffI-2KY-13@gated-at.bofh.it> |
| In reply to | #1296169 |
On Mon, 2015-12-21 at 15:19 -0400, Julian Margetson wrote: > On 12/21/2015 2:27 PM, Måns Rullgård wrote: > > The hard drive is recognized . > > > These system gets unresponsive with USB devices like the mouse > > > and > > > keyboard not responding when I start Gparted. > > Did you disable the SATA and DMA debug messages? > > > It is working. Indeed, thanks, Julian! I might ask you to test my branch with set of patches when it will be ready (apparently after Xmas) if you are okay with that. Måns, also I would ask you to test on your hardware (AVR32) as well if you have no objections. -- Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-12-21 21:40 +0100 |
| Message-ID | <qIfpn-2P6-5@gated-at.bofh.it> |
| In reply to | #1296195 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes: > On Mon, 2015-12-21 at 15:19 -0400, Julian Margetson wrote: >> On 12/21/2015 2:27 PM, Måns Rullgård wrote: >> > The hard drive is recognized . >> > > These system gets unresponsive with USB devices like the mouse >> > > and >> > > keyboard not responding when I start Gparted. >> > Did you disable the SATA and DMA debug messages? >> > >> It is working. > > Indeed, thanks, Julian! > > I might ask you to test my branch with set of patches when it will be > ready (apparently after Xmas) if you are okay with that. > > Måns, also I would ask you to test on your hardware (AVR32) as well if > you have no objections. Sure, but it will have to wait until January. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Julian Margetson <runaway@candw.ms> |
|---|---|
| Date | 2015-12-21 19:30 +0100 |
| Subject | Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel |
| Message-ID | <qIdnB-1xE-33@gated-at.bofh.it> |
| In reply to | #1296125 |
On 12/21/2015 1:55 PM, Andy Shevchenko wrote: > On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson <runaway@candw.ms> wrote: >> On 12/21/2015 12:48 PM, Andy Shevchenko wrote: >>> On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote: >>>> On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko >>>> <andy.shevchenko@gmail.com> wrote: >>>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> >>>>> wrote: >>>>> I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32 >>>>> items on this board, however registers for SATA program it to 64. I >>>>> remember that I got no interrupt when I programmed transfer width >>>>> wrongly (64 bits against 32 bits) when I ported dw_dmac to be used >>>>> on >>>>> Intel SoCs. >>>> One more thing, I have a patch to monitor DMA IO, we may check what >>>> exactly the values are written / read in DMA. I can share it >>>> tomorrow. >>> As promised the patch I have to debug IO of DW DMA. Didn't check though >>> if it applies cleanly on top of recent vanilla kernel. > So, the original driver (with patch from Måns) works, right? > The hard drive is recognized . These system gets unresponsive with USB devices like the mouse and keyboard not responding when I start Gparted. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-12-21 01:50 +0100 |
| Message-ID | <qHWPL-7RR-1@gated-at.bofh.it> |
| In reply to | #1295674 |
Andy Shevchenko <andy.shevchenko@gmail.com> writes: > On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> wrote: >> Julian Margetson <runaway@candw.ms> writes: >>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>>> Julian Margetson <runaway@candw.ms> writes: > >>> [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED >> >> Well, that didn't help. I still think it's part of the problem, but >> something else must be wrong as well. The various Master Select fields >> look like a good place to start. > > Master number (which is here would be either 1 or 0) should not affect > as long as they are connected to the same AHB bus (I would be > surprised if they are not). I think they are not. The relevant part of the block diagram for the 460EX looks something like this: +-----+ +-----+ +-----+ +------+ | CPU |<==>| BUS |<==>| DMA |<==>| SATA | +-----+ +-----+ +-----+ +------+ >> Also, the manual says the LLP_SRC_EN >> and LLP_DST_EN flags should be cleared on the last in a chain of blocks. >> The old sata_dwc driver does this whereas dw_dma does not. > > Easy to fix, however I can't get how it might affect. > >> It might be worthwhile to try reverting drivers/ata/sata_dwc_460ex.c to >> v4.0 (leaving the rest at 4.4-rc5) just to make sure that's a good >> reference. I've verified that this builds. > > It would be nice. > > I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32 > items on this board, however registers for SATA program it to 64. I > remember that I got no interrupt when I programmed transfer width > wrongly (64 bits against 32 bits) when I ported dw_dmac to be used on > Intel SoCs. > > -- > With Best Regards, > Andy Shevchenko -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-12-21 02:00 +0100 |
| Message-ID | <qHWZs-7Vb-15@gated-at.bofh.it> |
| In reply to | #1295725 |
Måns Rullgård <mans@mansr.com> writes: > Andy Shevchenko <andy.shevchenko@gmail.com> writes: > >> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> wrote: >>> Julian Margetson <runaway@candw.ms> writes: >>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>>>> Julian Margetson <runaway@candw.ms> writes: >> >>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED >>> >>> Well, that didn't help. I still think it's part of the problem, but >>> something else must be wrong as well. The various Master Select fields >>> look like a good place to start. >> >> Master number (which is here would be either 1 or 0) should not affect >> as long as they are connected to the same AHB bus (I would be >> surprised if they are not). > > I think they are not. The relevant part of the block diagram for the > 460EX looks something like this: Oops, hit send by accident. More soon. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-12-21 02:00 +0100 |
| Message-ID | <qHWZs-7Vb-17@gated-at.bofh.it> |
| In reply to | #1295674 |
Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> wrote:
>> Julian Margetson <runaway@candw.ms> writes:
>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote:
>>>> Julian Margetson <runaway@candw.ms> writes:
>
>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED
>>
>> Well, that didn't help. I still think it's part of the problem, but
>> something else must be wrong as well. The various Master Select fields
>> look like a good place to start.
>
> Master number (which is here would be either 1 or 0) should not affect
> as long as they are connected to the same AHB bus (I would be
> surprised if they are not).
I think they are not. The relevant part of the block diagram for the
460EX looks something like this:
+-----+
| CPU |
+-----+
|
+---------------+
| BUS |
+---------------+
| |
+-----+ +-----+
| DMA | | RAM |
+-----+ +-----+
|
+------+
| SATA |
+------+
The DMA-SATA link is private and ignores the address, which is the only
reason the driver can possibly work (it's programming a CPU virtual
address there).
>> Also, the manual says the LLP_SRC_EN
>> and LLP_DST_EN flags should be cleared on the last in a chain of blocks.
>> The old sata_dwc driver does this whereas dw_dma does not.
>
> Easy to fix, however I can't get how it might affect.
From the Atmel doc:
In Table 17-1 on page 185, all other combinations of LLPx.LOC = 0,
CTLx.LLP_S_EN, CFGx.RELOAD_SR, CTLx.LLP_D_EN, and CFGx.RELOAD_DS are
illegal, and causes indeterminate or erroneous behavior.
Most likely nothing happens, but I think it ought to be fixed. In fact,
I have a patch already.
Come to think of it, I have an AVR32 dev somewhere. Maybe I should dust
it off.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Shevchenko <andy.shevchenko@gmail.com> |
|---|---|
| Date | 2015-12-21 09:50 +0100 |
| Subject | Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel |
| Message-ID | <qI4ki-4cb-7@gated-at.bofh.it> |
| In reply to | #1295728 |
+Viresh On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård <mans@mansr.com> wrote: > Andy Shevchenko <andy.shevchenko@gmail.com> writes: > >> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> wrote: >>> Julian Margetson <runaway@candw.ms> writes: >>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>>>> Julian Margetson <runaway@candw.ms> writes: >> >>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED >>> >>> Well, that didn't help. I still think it's part of the problem, but >>> something else must be wrong as well. The various Master Select fields >>> look like a good place to start. >> >> Master number (which is here would be either 1 or 0) should not affect >> as long as they are connected to the same AHB bus (I would be >> surprised if they are not). > > I think they are not. The relevant part of the block diagram for the > 460EX looks something like this: > > +-----+ > | CPU | > +-----+ > | > +---------------+ > | BUS | > +---------------+ > | | > +-----+ +-----+ > | DMA | | RAM | > +-----+ +-----+ > | > +------+ > | SATA | > +------+ > > The DMA-SATA link is private and ignores the address, which is the only > reason the driver can possibly work (it's programming a CPU virtual > address there). If you look at the original code the SMS and DMS are programmed statically independent on DMA direction, so LLP is programmed always to master 1. I don't think your scheme is reflecting this right. I could imagine two AHB buses, one of them connects CPU, SATA and RAM, and the other CPU and DMA. In any case on all Intel SoCs and AVR32, and as far as I can tell on Spear13xx (Viresh?) there is not a case, that's why I hardly imagine that the problem is in master numbers by themselves. >>> Also, the manual says the LLP_SRC_EN >>> and LLP_DST_EN flags should be cleared on the last in a chain of blocks. >>> The old sata_dwc driver does this whereas dw_dma does not. >> >> Easy to fix, however I can't get how it might affect. > > From the Atmel doc: > > In Table 17-1 on page 185, all other combinations of LLPx.LOC = 0, > CTLx.LLP_S_EN, CFGx.RELOAD_SR, CTLx.LLP_D_EN, and CFGx.RELOAD_DS are > illegal, and causes indeterminate or erroneous behavior. I will check Synospys documentation later on. > Most likely nothing happens, but I think it ought to be fixed. In fact, > I have a patch already. Good. Send with Fixes tag if it's upstream ready. > Come to think of it, I have an AVR32 dev somewhere. Maybe I should dust > it off. I have ATNGW100. P.S. Anyway we have to ask Julian to try the kernel with 8b3444852a2b58129 reverted. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-12-21 13:20 +0100 |
| Message-ID | <qI7Bv-6nS-1@gated-at.bofh.it> |
| In reply to | #1295833 |
Andy Shevchenko <andy.shevchenko@gmail.com> writes: > +Viresh > > On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård <mans@mansr.com> wrote: >> Andy Shevchenko <andy.shevchenko@gmail.com> writes: >> >>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> wrote: >>>> Julian Margetson <runaway@candw.ms> writes: >>>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>>>>> Julian Margetson <runaway@candw.ms> writes: >>> >>>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED >>>> >>>> Well, that didn't help. I still think it's part of the problem, but >>>> something else must be wrong as well. The various Master Select fields >>>> look like a good place to start. >>> >>> Master number (which is here would be either 1 or 0) should not affect >>> as long as they are connected to the same AHB bus (I would be >>> surprised if they are not). >> >> I think they are not. The relevant part of the block diagram for the >> 460EX looks something like this: >> >> +-----+ >> | CPU | >> +-----+ >> | >> +---------------+ >> | BUS | >> +---------------+ >> | | >> +-----+ +-----+ >> | DMA | | RAM | >> +-----+ +-----+ >> | >> +------+ >> | SATA | >> +------+ >> >> The DMA-SATA link is private and ignores the address, which is the only >> reason the driver can possibly work (it's programming a CPU virtual >> address there). > > If you look at the original code the SMS and DMS are programmed > statically independent on DMA direction, so LLP is programmed always > to master 1. I don't think your scheme is reflecting this right. I > could imagine two AHB buses, one of them connects CPU, SATA and RAM, > and the other CPU and DMA. Check the code again. The original code swaps SMS and DMS depending on direction, and it sets LMS to 1. Put differently, it always sets the memory side 1 and the device side to 0. The dw_dma driver sets SMS and DMS to the src/dst_master values provided through dma_request_channel() regardless of the current direction and LMS always zero. If those values didn't matter, why would the fields exist in the first place? > In any case on all Intel SoCs and AVR32, and as far as I can tell on > Spear13xx (Viresh?) there is not a case, that's why I hardly imagine > that the problem is in master numbers by themselves. The 460EX is a PowerPC system. Expect unusual topologies. >>>> Also, the manual says the LLP_SRC_EN >>>> and LLP_DST_EN flags should be cleared on the last in a chain of blocks. >>>> The old sata_dwc driver does this whereas dw_dma does not. >>> >>> Easy to fix, however I can't get how it might affect. >> >> From the Atmel doc: >> >> In Table 17-1 on page 185, all other combinations of LLPx.LOC = 0, >> CTLx.LLP_S_EN, CFGx.RELOAD_SR, CTLx.LLP_D_EN, and CFGx.RELOAD_DS are >> illegal, and causes indeterminate or erroneous behavior. > > I will check Synospys documentation later on. > >> Most likely nothing happens, but I think it ought to be fixed. In fact, >> I have a patch already. > > Good. Send with Fixes tag if it's upstream ready. > >> Come to think of it, I have an AVR32 dev somewhere. Maybe I should dust >> it off. > > I have ATNGW100. I have an AT32ATK1006. Can you suggest a good test to exercise the DMA engine? -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Shevchenko <andy.shevchenko@gmail.com> |
|---|---|
| Date | 2015-12-21 18:30 +0100 |
| Subject | Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel |
| Message-ID | <qIcrx-Yd-21@gated-at.bofh.it> |
| In reply to | #1295942 |
On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård <mans@mansr.com> wrote: > Andy Shevchenko <andy.shevchenko@gmail.com> writes: > >> +Viresh >> >> On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård <mans@mansr.com> wrote: >>> Andy Shevchenko <andy.shevchenko@gmail.com> writes: >>> >>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> wrote: >>>>> Julian Margetson <runaway@candw.ms> writes: >>>>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>>>>>> Julian Margetson <runaway@candw.ms> writes: >>>> >>>>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED >>>>> >>>>> Well, that didn't help. I still think it's part of the problem, but >>>>> something else must be wrong as well. The various Master Select fields >>>>> look like a good place to start. >>>> >>>> Master number (which is here would be either 1 or 0) should not affect >>>> as long as they are connected to the same AHB bus (I would be >>>> surprised if they are not). >>> >>> I think they are not. The relevant part of the block diagram for the >>> 460EX looks something like this: >>> >>> +-----+ >>> | CPU | >>> +-----+ >>> | >>> +---------------+ >>> | BUS | >>> +---------------+ >>> | | >>> +-----+ +-----+ >>> | DMA | | RAM | >>> +-----+ +-----+ >>> | >>> +------+ >>> | SATA | >>> +------+ >>> >>> The DMA-SATA link is private and ignores the address, which is the only >>> reason the driver can possibly work (it's programming a CPU virtual >>> address there). >> >> If you look at the original code the SMS and DMS are programmed >> statically independent on DMA direction, so LLP is programmed always >> to master 1. I don't think your scheme is reflecting this right. I >> could imagine two AHB buses, one of them connects CPU, SATA and RAM, >> and the other CPU and DMA. > > Check the code again. The original code swaps SMS and DMS depending on > direction, and it sets LMS to 1. Put differently, it always sets the > memory side 1 and the device side to 0. The dw_dma driver sets SMS and > DMS to the src/dst_master values provided through dma_request_channel() > regardless of the current direction and LMS always zero. I used to have a patch to implement this in dw_dmac driver. However, I dropped it at some point. Seems we need it back and now I possible have a good explanation why. > If those > values didn't matter, why would the fields exist in the first place? Because someone can have more than one AHB bus on the system and connect DMA to all of them (up to 4). >> In any case on all Intel SoCs and AVR32, and as far as I can tell on >> Spear13xx (Viresh?) there is not a case, that's why I hardly imagine >> that the problem is in master numbers by themselves. > > The 460EX is a PowerPC system. Expect unusual topologies. Yeah, that's right. >>>>> Also, the manual says the LLP_SRC_EN >>>>> and LLP_DST_EN flags should be cleared on the last in a chain of blocks. >>>>> The old sata_dwc driver does this whereas dw_dma does not. >>>> >>>> Easy to fix, however I can't get how it might affect. >>> >>> From the Atmel doc: >>> >>> In Table 17-1 on page 185, all other combinations of LLPx.LOC = 0, >>> CTLx.LLP_S_EN, CFGx.RELOAD_SR, CTLx.LLP_D_EN, and CFGx.RELOAD_DS are >>> illegal, and causes indeterminate or erroneous behavior. >> >> I will check Synospys documentation later on. Yes, we have to clear those bits. I will do a patch or you already have one? >>> Most likely nothing happens, but I think it ought to be fixed. In fact, >>> I have a patch already. >> >> Good. Send with Fixes tag if it's upstream ready. >> >>> Come to think of it, I have an AVR32 dev somewhere. Maybe I should dust >>> it off. >> >> I have ATNGW100. > > I have an AT32ATK1006. Can you suggest a good test to exercise the DMA > engine? On that board I tried MMC (the only available user for me), though it is not reliable, I also tried the dmatest module. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-12-21 19:20 +0100 |
| Message-ID | <qIddT-1tP-9@gated-at.bofh.it> |
| In reply to | #1296097 |
Andy Shevchenko <andy.shevchenko@gmail.com> writes: > On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård <mans@mansr.com> wrote: >> Andy Shevchenko <andy.shevchenko@gmail.com> writes: >> >>> +Viresh >>> >>> On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård <mans@mansr.com> wrote: >>>> Andy Shevchenko <andy.shevchenko@gmail.com> writes: >>>> >>>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> wrote: >>>>>> Julian Margetson <runaway@candw.ms> writes: >>>>>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>>>>>>> Julian Margetson <runaway@candw.ms> writes: >>>>> >>>>>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED >>>>>> >>>>>> Well, that didn't help. I still think it's part of the problem, but >>>>>> something else must be wrong as well. The various Master Select fields >>>>>> look like a good place to start. >>>>> >>>>> Master number (which is here would be either 1 or 0) should not affect >>>>> as long as they are connected to the same AHB bus (I would be >>>>> surprised if they are not). >>>> >>>> I think they are not. The relevant part of the block diagram for the >>>> 460EX looks something like this: >>>> >>>> +-----+ >>>> | CPU | >>>> +-----+ >>>> | >>>> +---------------+ >>>> | BUS | >>>> +---------------+ >>>> | | >>>> +-----+ +-----+ >>>> | DMA | | RAM | >>>> +-----+ +-----+ >>>> | >>>> +------+ >>>> | SATA | >>>> +------+ >>>> >>>> The DMA-SATA link is private and ignores the address, which is the only >>>> reason the driver can possibly work (it's programming a CPU virtual >>>> address there). >>> >>> If you look at the original code the SMS and DMS are programmed >>> statically independent on DMA direction, so LLP is programmed always >>> to master 1. I don't think your scheme is reflecting this right. I >>> could imagine two AHB buses, one of them connects CPU, SATA and RAM, >>> and the other CPU and DMA. >> >> Check the code again. The original code swaps SMS and DMS depending on >> direction, and it sets LMS to 1. Put differently, it always sets the >> memory side 1 and the device side to 0. The dw_dma driver sets SMS and >> DMS to the src/dst_master values provided through dma_request_channel() >> regardless of the current direction and LMS always zero. > > I used to have a patch to implement this in dw_dmac driver. However, I > dropped it at some point. Seems we need it back and now I possible > have a good explanation why. Are you still able to find that patch? Shouldn't be too hard to do from scratch if not. >> If those values didn't matter, why would the fields exist in the >> first place? > > Because someone can have more than one AHB bus on the system and > connect DMA to all of them (up to 4). Which apparently these guys did. Well, not a full-blown AHB bus, but they seem to be using two master interfaces. >>> In any case on all Intel SoCs and AVR32, and as far as I can tell on >>> Spear13xx (Viresh?) there is not a case, that's why I hardly imagine >>> that the problem is in master numbers by themselves. >> >> The 460EX is a PowerPC system. Expect unusual topologies. > > Yeah, that's right. BTW, there's a good reason for wiring it like this. If the source and destination are on different buses, the DMA engine can do a read and a write in each cycle. Otherwise the reads and writes have to be issued alternately. >>>>>> Also, the manual says the LLP_SRC_EN >>>>>> and LLP_DST_EN flags should be cleared on the last in a chain of blocks. >>>>>> The old sata_dwc driver does this whereas dw_dma does not. >>>>> >>>>> Easy to fix, however I can't get how it might affect. >>>> >>>> From the Atmel doc: >>>> >>>> In Table 17-1 on page 185, all other combinations of LLPx.LOC = 0, >>>> CTLx.LLP_S_EN, CFGx.RELOAD_SR, CTLx.LLP_D_EN, and CFGx.RELOAD_DS are >>>> illegal, and causes indeterminate or erroneous behavior. >>> >>> I will check Synospys documentation later on. > > Yes, we have to clear those bits. I will do a patch or you already have one? I'll send the patch soon. >>>> Most likely nothing happens, but I think it ought to be fixed. In fact, >>>> I have a patch already. >>> >>> Good. Send with Fixes tag if it's upstream ready. >>> >>>> Come to think of it, I have an AVR32 dev somewhere. Maybe I should dust >>>> it off. >>> >>> I have ATNGW100. >> >> I have an AT32ATK1006. Can you suggest a good test to exercise the DMA >> engine? > > On that board I tried MMC (the only available user for me), though it > is not reliable, I also tried the dmatest module. Hmm, is there anywhere this damn driver actually works? ;-) -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
|---|---|
| Date | 2015-12-21 20:30 +0100 |
| Subject | Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel |
| Message-ID | <qIejE-28Y-11@gated-at.bofh.it> |
| In reply to | #1296130 |
On Mon, 2015-12-21 at 18:16 +0000, Måns Rullgård wrote: > Andy Shevchenko <andy.shevchenko@gmail.com> writes: > > > On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård <mans@mansr.com> > > wrote: > > > Andy Shevchenko <andy.shevchenko@gmail.com> writes: > > > > > I used to have a patch to implement this in dw_dmac driver. > > However, I > > dropped it at some point. Seems we need it back and now I possible > > have a good explanation why. > > Are you still able to find that patch? Shouldn't be too hard to do > from > scratch if not. Yes, I found a version of it, let me mock up tomorrow something working. > > > > If those values didn't matter, why would the fields exist in the > > > first place? > > > > Because someone can have more than one AHB bus on the system and > > connect DMA to all of them (up to 4). > > Which apparently these guys did. Well, not a full-blown AHB bus, but > they seem to be using two master interfaces. To different buses? Intel HW uses two masters and they are quite equal (at least from OS point of view, it might be HW adjusts it). > > > > > In any case on all Intel SoCs and AVR32, and as far as I can > > > > tell on > > > > Spear13xx (Viresh?) there is not a case, that's why I hardly > > > > imagine > > > > that the problem is in master numbers by themselves. > > > > > > The 460EX is a PowerPC system. Expect unusual topologies. > > > > Yeah, that's right. > > BTW, there's a good reason for wiring it like this. If the source > and > destination are on different buses, the DMA engine can do a read and > a > write in each cycle. Otherwise the reads and writes have to be > issued > alternately. Okay. We need first to have a confirmation. I would try to set other bits under question to see if it helps first (CFG register in DMA). > Most likely nothing happens, but I think it ought to be > > > > > fixed. In fact, > > > > > I have a patch already. > > > > > > > > Good. Send with Fixes tag if it's upstream ready. > > > > > > > > > Come to think of it, I have an AVR32 dev somewhere. Maybe I > > > > > should dust > > > > > it off. > > > > > > > > I have ATNGW100. > > > > > > I have an AT32ATK1006. Can you suggest a good test to exercise > > > the DMA > > > engine? > > > > On that board I tried MMC (the only available user for me), though > > it > > is not reliable, I also tried the dmatest module. > > Hmm, is there anywhere this damn driver actually works? ;-) Yes, on Intel HW. -- Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-12-21 21:00 +0100 |
| Message-ID | <qIeMG-2kK-11@gated-at.bofh.it> |
| In reply to | #1296164 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes: > On Mon, 2015-12-21 at 18:16 +0000, Måns Rullgård wrote: >> Andy Shevchenko <andy.shevchenko@gmail.com> writes: >> >> > On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård <mans@mansr.com> >> > wrote: >> > > Andy Shevchenko <andy.shevchenko@gmail.com> writes: >> > > >> > I used to have a patch to implement this in dw_dmac driver. >> > However, I >> > dropped it at some point. Seems we need it back and now I possible >> > have a good explanation why. >> >> Are you still able to find that patch? Shouldn't be too hard to do >> from scratch if not. > > Yes, I found a version of it, let me mock up tomorrow something > working. > >> >> > > If those values didn't matter, why would the fields exist in the >> > > first place? >> > >> > Because someone can have more than one AHB bus on the system and >> > connect DMA to all of them (up to 4). >> >> Which apparently these guys did. Well, not a full-blown AHB bus, but >> they seem to be using two master interfaces. > > To different buses? Intel HW uses two masters and they are quite equal > (at least from OS point of view, it might be HW adjusts it). Judging by the block diagram in the 460EX datasheet [1], and by the fact that the old SATA driver works despite using an invalid address, the DMA FIFO of the controller isn't connected to the AHB bus at all but directly to master 0 on the DW DMA controller. Master 1 of the DMA controller is connected to the AHB bus, which is bridged to the main system bus. I haven't managed to find a full manual for the 460EX. [1] http://datasheet.octopart.com/PPC460EX-NUB800T-AMCC-datasheet-11553412.pdf -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-12-21 13:20 +0100 |
| Message-ID | <qI7Bw-6nS-17@gated-at.bofh.it> |
| In reply to | #1295833 |
Julian Margetson <runaway@candw.ms> writes: > On 12/21/2015 4:40 AM, Andy Shevchenko wrote: >> +Viresh >> >> On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård <mans@mansr.com> wrote: >>> Andy Shevchenko <andy.shevchenko@gmail.com> writes: >>> >>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> wrote: >>>>> Julian Margetson <runaway@candw.ms> writes: >>>>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>>>>>> Julian Margetson <runaway@candw.ms> writes: >>>>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED >>>>> Well, that didn't help. I still think it's part of the problem, but >>>>> something else must be wrong as well. The various Master Select fields >>>>> look like a good place to start. >>>> Master number (which is here would be either 1 or 0) should not affect >>>> as long as they are connected to the same AHB bus (I would be >>>> surprised if they are not). >>> I think they are not. The relevant part of the block diagram for the >>> 460EX looks something like this: >>> >>> +-----+ >>> | CPU | >>> +-----+ >>> | >>> +---------------+ >>> | BUS | >>> +---------------+ >>> | | >>> +-----+ +-----+ >>> | DMA | | RAM | >>> +-----+ +-----+ >>> | >>> +------+ >>> | SATA | >>> +------+ >>> >>> The DMA-SATA link is private and ignores the address, which is the only >>> reason the driver can possibly work (it's programming a CPU virtual >>> address there). >> If you look at the original code the SMS and DMS are programmed >> statically independent on DMA direction, so LLP is programmed always >> to master 1. I don't think your scheme is reflecting this right. I >> could imagine two AHB buses, one of them connects CPU, SATA and RAM, >> and the other CPU and DMA. >> >> In any case on all Intel SoCs and AVR32, and as far as I can tell on >> Spear13xx (Viresh?) there is not a case, that's why I hardly imagine >> that the problem is in master numbers by themselves. >> >>>>> Also, the manual says the LLP_SRC_EN >>>>> and LLP_DST_EN flags should be cleared on the last in a chain of blocks. >>>>> The old sata_dwc driver does this whereas dw_dma does not. >>>> Easy to fix, however I can't get how it might affect. >>> From the Atmel doc: >>> >>> In Table 17-1 on page 185, all other combinations of LLPx.LOC = 0, >>> CTLx.LLP_S_EN, CFGx.RELOAD_SR, CTLx.LLP_D_EN, and CFGx.RELOAD_DS are >>> illegal, and causes indeterminate or erroneous behavior. >> I will check Synospys documentation later on. >> >>> Most likely nothing happens, but I think it ought to be fixed. In fact, >>> I have a patch already. >> Good. Send with Fixes tag if it's upstream ready. >> >>> Come to think of it, I have an AVR32 dev somewhere. Maybe I should dust >>> it off. >> I have ATNGW100. >> >> P.S. Anyway we have to ask Julian to try the kernel with >> 8b3444852a2b58129 reverted. >> > git revert 8b3444852a2b58129 > error: could not revert 8b34448... sata_dwc_460ex: move to generic DMA driver > hint: after resolving the conflicts, mark the corrected paths > hint: with 'git add <paths>' or 'git rm <paths>' > hint: and commit the result with 'git commit' Yeah, that won't work since there are numerous changes afterward. Just revert the entire file back to 4.0 like this: $ git checkout v4.0 drivers/ata/sata_dwc_460ex.c -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Julian Margetson <runaway@candw.ms> |
|---|---|
| Date | 2015-12-21 14:20 +0100 |
| Subject | Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel |
| Message-ID | <qI8xA-6Yg-11@gated-at.bofh.it> |
| In reply to | #1295947 |
On 12/21/2015 8:16 AM, Måns Rullgård wrote:
> Julian Margetson <runaway@candw.ms> writes:
>
>> On 12/21/2015 4:40 AM, Andy Shevchenko wrote:
>>> +Viresh
>>>
>>> On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård <mans@mansr.com> wrote:
>>>> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
>>>>
>>>>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@mansr.com> wrote:
>>>>>> Julian Margetson <runaway@candw.ms> writes:
>>>>>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote:
>>>>>>>> Julian Margetson <runaway@candw.ms> writes:
>>>>>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED
>>>>>> Well, that didn't help. I still think it's part of the problem, but
>>>>>> something else must be wrong as well. The various Master Select fields
>>>>>> look like a good place to start.
>>>>> Master number (which is here would be either 1 or 0) should not affect
>>>>> as long as they are connected to the same AHB bus (I would be
>>>>> surprised if they are not).
>>>> I think they are not. The relevant part of the block diagram for the
>>>> 460EX looks something like this:
>>>>
>>>> +-----+
>>>> | CPU |
>>>> +-----+
>>>> |
>>>> +---------------+
>>>> | BUS |
>>>> +---------------+
>>>> | |
>>>> +-----+ +-----+
>>>> | DMA | | RAM |
>>>> +-----+ +-----+
>>>> |
>>>> +------+
>>>> | SATA |
>>>> +------+
>>>>
>>>> The DMA-SATA link is private and ignores the address, which is the only
>>>> reason the driver can possibly work (it's programming a CPU virtual
>>>> address there).
>>> If you look at the original code the SMS and DMS are programmed
>>> statically independent on DMA direction, so LLP is programmed always
>>> to master 1. I don't think your scheme is reflecting this right. I
>>> could imagine two AHB buses, one of them connects CPU, SATA and RAM,
>>> and the other CPU and DMA.
>>>
>>> In any case on all Intel SoCs and AVR32, and as far as I can tell on
>>> Spear13xx (Viresh?) there is not a case, that's why I hardly imagine
>>> that the problem is in master numbers by themselves.
>>>
>>>>>> Also, the manual says the LLP_SRC_EN
>>>>>> and LLP_DST_EN flags should be cleared on the last in a chain of blocks.
>>>>>> The old sata_dwc driver does this whereas dw_dma does not.
>>>>> Easy to fix, however I can't get how it might affect.
>>>> From the Atmel doc:
>>>>
>>>> In Table 17-1 on page 185, all other combinations of LLPx.LOC = 0,
>>>> CTLx.LLP_S_EN, CFGx.RELOAD_SR, CTLx.LLP_D_EN, and CFGx.RELOAD_DS are
>>>> illegal, and causes indeterminate or erroneous behavior.
>>> I will check Synospys documentation later on.
>>>
>>>> Most likely nothing happens, but I think it ought to be fixed. In fact,
>>>> I have a patch already.
>>> Good. Send with Fixes tag if it's upstream ready.
>>>
>>>> Come to think of it, I have an AVR32 dev somewhere. Maybe I should dust
>>>> it off.
>>> I have ATNGW100.
>>>
>>> P.S. Anyway we have to ask Julian to try the kernel with
>>> 8b3444852a2b58129 reverted.
>>>
>> git revert 8b3444852a2b58129
>> error: could not revert 8b34448... sata_dwc_460ex: move to generic DMA driver
>> hint: after resolving the conflicts, mark the corrected paths
>> hint: with 'git add <paths>' or 'git rm <paths>'
>> hint: and commit the result with 'git commit'
> Yeah, that won't work since there are numerous changes afterward. Just
> revert the entire file back to 4.0 like this:
>
> $ git checkout v4.0 drivers/ata/sata_dwc_460ex.c
>
CC [M] drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c:467:36: error: macro "dma_request_channel"
requires 3 arguments, but only 1 given
static int dma_request_channel(void)
^
drivers/ata/sata_dwc_460ex.c:468:1: error: expected ‘=’, ‘,’,
‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
{
^
drivers/ata/sata_dwc_460ex.c: In function ‘dma_dwc_xfer_setup’:
drivers/ata/sata_dwc_460ex.c:758:31: error: macro "dma_request_channel"
requires 3 arguments, but only 1 given
dma_ch = dma_request_channel();
^
drivers/ata/sata_dwc_460ex.c:758:11: error: ‘dma_request_channel’
undeclared (first use in this function)
dma_ch = dma_request_channel();
^
drivers/ata/sata_dwc_460ex.c:758:11: note: each undeclared identifier is
reported only once for each function it appears in
drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_dma_filter’:
drivers/ata/sata_dwc_460ex.c:1282:35: error: ‘struct
sata_dwc_device_port’ has no member named ‘dws’
struct dw_dma_slave *dws = hsdevp->dws;
^
drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_port_start’:
drivers/ata/sata_dwc_460ex.c:1325:17: warning: unused variable
‘mask’ [-Wunused-variable]
dma_cap_mask_t mask;
^
drivers/ata/sata_dwc_460ex.c: At top level:
drivers/ata/sata_dwc_460ex.c:345:28: warning: ‘sata_dwc_dma_dws’
defined but not used [-Wunused-variable]
static struct dw_dma_slave sata_dwc_dma_dws = {
^
drivers/ata/sata_dwc_460ex.c:1279:13: warning: ‘sata_dwc_dma_filter’
defined but not used [-Wunused-function]
static bool sata_dwc_dma_filter(struct dma_chan *chan, void *param)
^
make[2]: *** [drivers/ata/sata_dwc_460ex.o] Error 1
make[1]: *** [drivers/ata] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-12-21 16:30 +0100 |
| Message-ID | <qIazo-8bx-9@gated-at.bofh.it> |
| In reply to | #1295978 |
[Multipart message — attachments visible in raw view] — view raw
Julian Margetson <runaway@candw.ms> writes:
> On 12/21/2015 9:24 AM, Måns Rullgård wrote:
>> Julian Margetson <runaway@candw.ms> writes:
>>
>>>>>> P.S. Anyway we have to ask Julian to try the kernel with
>>>>>> 8b3444852a2b58129 reverted.
>>>>>>
>>>>> git revert 8b3444852a2b58129
>>>>> error: could not revert 8b34448... sata_dwc_460ex: move to generic DMA driver
>>>>> hint: after resolving the conflicts, mark the corrected paths
>>>>> hint: with 'git add <paths>' or 'git rm <paths>'
>>>>> hint: and commit the result with 'git commit'
>>>> Yeah, that won't work since there are numerous changes afterward. Just
>>>> revert the entire file back to 4.0 like this:
>>>>
>>>> $ git checkout v4.0 drivers/ata/sata_dwc_460ex.c
>>>>
>>> CC [M] drivers/ata/sata_dwc_460ex.o
>>> drivers/ata/sata_dwc_460ex.c:467:36: error: macro
>>> "dma_request_channel" requires 3 arguments, but only 1 given
>>> static int dma_request_channel(void)
>>> ^
>>> drivers/ata/sata_dwc_460ex.c:468:1: error: expected ‘=’, ‘,’,
>>> ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
>>> {
>>> ^
>>> drivers/ata/sata_dwc_460ex.c: In function ‘dma_dwc_xfer_setup’:
>>> drivers/ata/sata_dwc_460ex.c:758:31: error: macro
>>> "dma_request_channel" requires 3 arguments, but only 1 given
>>> dma_ch = dma_request_channel();
>>> ^
>>> drivers/ata/sata_dwc_460ex.c:758:11: error: ‘dma_request_channel’
>>> undeclared (first use in this function)
>>> dma_ch = dma_request_channel();
>>> ^
>>> drivers/ata/sata_dwc_460ex.c:758:11: note: each undeclared identifier
>>> is reported only once for each function it appears in
>>> drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_dma_filter’:
>>> drivers/ata/sata_dwc_460ex.c:1282:35: error: ‘struct
>>> sata_dwc_device_port’ has no member named ‘dws’
>>> struct dw_dma_slave *dws = hsdevp->dws;
>>> ^
>>> drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_port_start’:
>>> drivers/ata/sata_dwc_460ex.c:1325:17: warning: unused variable
>>> ‘mask’ [-Wunused-variable]
>>> dma_cap_mask_t mask;
>>> ^
>>> drivers/ata/sata_dwc_460ex.c: At top level:
>>> drivers/ata/sata_dwc_460ex.c:345:28: warning: ‘sata_dwc_dma_dws’
>>> defined but not used [-Wunused-variable]
>>> static struct dw_dma_slave sata_dwc_dma_dws = {
>>> ^
>>> drivers/ata/sata_dwc_460ex.c:1279:13: warning:
>>> ‘sata_dwc_dma_filter’ defined but not used [-Wunused-function]
>>> static bool sata_dwc_dma_filter(struct dma_chan *chan, void *param)
>>> ^
>> Those messages do not match the contents of the file from v4.0.
>> For your convenience, here's the file as it should be.
>>
>> $ sha1sum drivers/ata/sata_dwc_460ex.c
>> 0f54dfa3a91591101f5de434c3a631a5cd20ff1a drivers/ata/sata_dwc_460ex.c
>
> [ 16.119186] BUG: spinlock recursion on CPU#0, kworker/u2:1/85
> [ 16.124935] lock: 0xedd2f910, .magic: dead4ead, .owner: kworker/u2:1/85, .owner_cpu: 0
> [ 16.132947] CPU: 0 PID: 85 Comm: kworker/u2:1 Not tainted 4.4.0-rc5-Sam460ex-dirty #3
> [ 16.140793] Workqueue: events_unbound async_run_entry_fn
> [ 16.146119] Call Trace:
> [ 16.148582] [ee3cf8c0] [c0049238] do_raw_spin_lock+0x4c/0x100 (unreliable)
> [ 16.155491] [ee3cf8e0] [c068af98] _raw_spin_lock_irqsave+0x2c/0x38
> [ 16.161721] [ee3cf8f0] [f6a0fd98] sata_dwc_exec_command_by_tag.constprop.9+0x80/0xb4 [sata_dwc_460ex]
> [ 16.170954] [ee3cf920] [f6a108c0] sata_dwc_qc_issue+0x6a4/0x6c4 [sata_dwc_460ex]
> [ 16.178380] [ee3cf9d0] [c043bdf8] ata_qc_issue+0x338/0x3a0
> [ 16.183883] [ee3cfa00] [c0440c84] ata_scsi_translate+0xf4/0x150
> [ 16.189813] [ee3cfa20] [c0444080] ata_scsi_queuecmd+0x1e8/0x238
> [ 16.195750] [ee3cfa40] [c042511c] scsi_dispatch_cmd+0xd4/0x110
> [ 16.201602] [ee3cfa50] [c0427a9c] scsi_request_fn+0x52c/0x55c
Oh, that one again. My patch still applies. Here it is as applied to
that revision of the file.
From what I can tell, that bug has always been there. Probably nobody
ever tested the driver in a PREEMPT or SMP build, nor with lock
debugging enabled.
--
Måns Rullgård
[toc] | [prev] | [next] | [standalone]
| From | Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
|---|---|
| Date | 2015-12-21 17:50 +0100 |
| Subject | Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel |
| Message-ID | <qIbOO-vL-3@gated-at.bofh.it> |
| In reply to | #1296036 |
On Mon, 2015-12-21 at 15:24 +0000, Måns Rullgård wrote: > Julian Margetson <runaway@candw.ms> writes: > > > Oh, that one again. My patch still applies. Here it is as applied > to > that revision of the file. > > From what I can tell, that bug has always been there. Probably > nobody > ever tested the driver in a PREEMPT or SMP build, nor with lock > debugging enabled. I guess it's a time to submit this one to upstream with proper Fixes: tag (which I suppose the initial commit of the driver). -- Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | linux.kernel
csiph-web