Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Fri, Jan 22, 2016 at 2:05 PM, Måns Rullgård wrote: > Andy Shevchenko writes: >> On Fri, 2016-01-22 at 11:13 +, Måns Rullgård wrote: >>> Andy Shevchenko writes: >>> > On Wed, 2016-01-20 at 20:07 +, Måns Rullgård wrote: >>> > > Andy Shevchenko writes: >> + u8 _dms = (_is_slave && _dwc->direction == DMA_MEM_TO_DEV) ? >>\ >> + _dwc->p_master : _dwc->m_master; >>\ >> + u8 _sms = (_is_slave && _dwc->direction == DMA_DEV_TO_MEM) ? >>\ >> + _dwc->p_master : _dwc->m_master; >>\ > Oh, I see it now. Two lines have a space rather than a tab since a tab > would push them over 80 columns. Now those lines could be shortened by > simply dropping the "_is_slave" since this is necessarily true if the > other half of the && is. Yes, direction is precisely from the _is_slave space. -- With Best Regards, Andy Shevchenko
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Fri, 2016-01-22 at 11:13 +, Måns Rullgård wrote: >> Andy Shevchenko writes: >> > On Wed, 2016-01-20 at 20:07 +, Måns Rullgård wrote: >> > > Andy Shevchenko writes: > >> > In DWC_DEFAULT_CTLLO() can we do tab indentation for \ ? >> >> Is there a wrong indentation somewhere? I don't see it. > > My git diff shows this in particular: > > --- a/drivers/dma/dw/core.c > +++ b/drivers/dma/dw/core.c > @@ -45,10 +45,10 @@ > DW_DMA_MSIZE_16;\ > u8 _dmsize = _is_slave ? _sconfig->dst_maxburst : \ > DW_DMA_MSIZE_16;\ > - u8 _dms = (_is_slave && _dwc->direction == DMA_MEM_TO_DEV) ? \ > - _dwc->p_master : _dwc->m_master;\ > - u8 _sms = (_is_slave && _dwc->direction == DMA_DEV_TO_MEM) ? \ > - _dwc->p_master : _dwc->m_master;\ > + u8 _dms = (_is_slave && _dwc->direction == DMA_MEM_TO_DEV) ? > \ > + _dwc->p_master : _dwc->m_master; > \ > + u8 _sms = (_is_slave && _dwc->direction == DMA_DEV_TO_MEM) ? > \ > + _dwc->p_master : _dwc->m_master; > \ > > Means in your case the ' \' is used, in mine — '\t\' at the end of > lines. Oh, I see it now. Two lines have a space rather than a tab since a tab would push them over 80 columns. Now those lines could be shortened by simply dropping the "_is_slave" since this is necessarily true if the other half of the && is. >> Now the question: who do you prefer to submit the series (dw_dmac)? >> > Me >> > or you? >> > >> > In case you would like to do it (what I see in your dwc-sata branch >> > today): >> > Acked-by: Andy Shevchenko >> >> I'll fix the above, give your changes a review, and add my sign-off >> before sending the series, today or during the weekend. > > OK. > > Just to be sure we are on the same page. I assume your dwc-sata branch > as for submitting. Yes, I'm not aware of anything that needs to change in that branch. -- Måns Rullgård
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Fri, 2016-01-22 at 11:13 +, Måns Rullgård wrote: > Andy Shevchenko writes: > > On Wed, 2016-01-20 at 20:07 +, Måns Rullgård wrote: > > > Andy Shevchenko writes: > > In DWC_DEFAULT_CTLLO() can we do tab indentation for \ ? > > Is there a wrong indentation somewhere? I don't see it. My git diff shows this in particular: --- a/drivers/dma/dw/core.c +++ b/drivers/dma/dw/core.c @@ -45,10 +45,10 @@ DW_DMA_MSIZE_16;\ u8 _dmsize = _is_slave ? _sconfig->dst_maxburst : \ DW_DMA_MSIZE_16;\ - u8 _dms = (_is_slave && _dwc->direction == DMA_MEM_TO_DEV) ? \ - _dwc->p_master : _dwc- >m_master;\ - u8 _sms = (_is_slave && _dwc->direction == DMA_DEV_TO_MEM) ? \ - _dwc->p_master : _dwc- >m_master;\ + u8 _dms = (_is_slave && _dwc->direction == DMA_MEM_TO_DEV) ?\ + _dwc->p_master : _dwc- >m_master; \ + u8 _sms = (_is_slave && _dwc->direction == DMA_DEV_TO_MEM) ?\ + _dwc->p_master : _dwc- >m_master; \ Means in your case the ' \' is used, in mine — '\t\' at the end of lines. > Now the question: who do you prefer to submit the series (dw_dmac)? > > Me > > or you? > > > > In case you would like to do it (what I see in your dwc-sata branch > > today): > > Acked-by: Andy Shevchenko > > I'll fix the above, give your changes a review, and add my sign-off > before sending the series, today or during the weekend. OK. Just to be sure we are on the same page. I assume your dwc-sata branch as for submitting. -- Andy Shevchenko Intel Finland Oy
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Wed, 2016-01-20 at 20:07 +, Måns Rullgård wrote: >> Andy Shevchenko writes: >> >> > > > > > One comment still regarding to lli types. We can avoid >> > > > > > warnings by >> > > > > > using (__force u32) in macros. >> > > > > >> > > > > But that won't give the benefits of having the types checked. >> > > > >> > > > You mean if we access the lli->field directly? I didn't quite >> > > > get what >> > > > use case you are keeping in mind. >> > > >> > > Yes, accessing any of those fields directly with my patch gives a >> > > sparse >> > > warning. It's situations like these those checks are intended >> > > for. >> > > Defeating them seems foolish to me. >> > >> > Otherwise it makes that struct looks ugly. >> > Why not union, though it still ugly, but less. >> >> What's so ugly about it? IMO data should be declared as the type it >> actually is, and here we have fields that might have a different byte >> order from the host CPU. The __be32 and __le32 types were invented >> to >> make such situations clear and allow automatic (sparse) >> checking. I'd >> say the price of one small typedef is well worth it. The actual code >> is >> not impacted since it must use the accessor macros anyhow. > > Okay, let's move with current state. > > I have few style minors and a question. > > So, in type definitions can we use __dw32 instead of dw_u32? Sure, no problem. > In DWC_DEFAULT_CTLLO() can we do tab indentation for \ ? Is there a wrong indentation somewhere? I don't see it. > Now the question: who do you prefer to submit the series (dw_dmac)? Me > or you? > > In case you would like to do it (what I see in your dwc-sata branch > today): > Acked-by: Andy Shevchenko I'll fix the above, give your changes a review, and add my sign-off before sending the series, today or during the weekend. -- Måns Rullgård
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Mon, 2015-12-21 at 16:29 -0400, Julian Margetson wrote: > 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. Can you test now what Måns has in his dwc-sata branch? https://bitbucket.org/mansr/linux-dwc/branch/dwc-sata -- Andy Shevchenko Intel Finland Oy
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Wed, 2016-01-20 at 20:07 +, Måns Rullgård wrote: > Andy Shevchenko writes: > > > > > > > One comment still regarding to lli types. We can avoid > > > > > > warnings by > > > > > > using (__force u32) in macros. > > > > > > > > > > But that won't give the benefits of having the types checked. > > > > > > > > You mean if we access the lli->field directly? I didn't quite > > > > get what > > > > use case you are keeping in mind. > > > > > > Yes, accessing any of those fields directly with my patch gives a > > > sparse > > > warning. It's situations like these those checks are intended > > > for. > > > Defeating them seems foolish to me. > > > > Otherwise it makes that struct looks ugly. > > Why not union, though it still ugly, but less. > > What's so ugly about it? IMO data should be declared as the type it > actually is, and here we have fields that might have a different byte > order from the host CPU. The __be32 and __le32 types were invented > to > make such situations clear and allow automatic (sparse) > checking. I'd > say the price of one small typedef is well worth it. The actual code > is > not impacted since it must use the accessor macros anyhow. Okay, let's move with current state. I have few style minors and a question. So, in type definitions can we use __dw32 instead of dw_u32? In DWC_DEFAULT_CTLLO() can we do tab indentation for \ ? Now the question: who do you prefer to submit the series (dw_dmac)? Me or you? In case you would like to do it (what I see in your dwc-sata branch today): Acked-by: Andy Shevchenko -- Andy Shevchenko Intel Finland Oy
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Wed, Jan 20, 2016 at 9:46 PM, Måns Rullgård wrote: > > One comment still regarding to lli types. We can avoid warnings by > using (__force u32) in macros. But that won't give the benefits of having the types checked. >>> >>> You mean if we access the lli->field directly? I didn't quite get what >>> use case you are keeping in mind. >> >> Yes, accessing any of those fields directly with my patch gives a sparse >> warning. It's situations like these those checks are intended for. >> Defeating them seems foolish to me. > > Otherwise it makes that struct looks ugly. > Why not union, though it still ugly, but less. What's so ugly about it? IMO data should be declared as the type it actually is, and here we have fields that might have a different byte order from the host CPU. The __be32 and __le32 types were invented to make such situations clear and allow automatic (sparse) checking. I'd say the price of one small typedef is well worth it. The actual code is not impacted since it must use the accessor macros anyhow. -- Måns Rullgård
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Wed, Jan 20, 2016 at 9:46 PM, Måns Rullgård wrote: One comment still regarding to lli types. We can avoid warnings by using (__force u32) in macros. >>> >>> But that won't give the benefits of having the types checked. >> >> You mean if we access the lli->field directly? I didn't quite get what >> use case you are keeping in mind. > > Yes, accessing any of those fields directly with my patch gives a sparse > warning. It's situations like these those checks are intended for. > Defeating them seems foolish to me. Otherwise it makes that struct looks ugly. Why not union, though it still ugly, but less. -- With Best Regards, Andy Shevchenko
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Wed, Jan 20, 2016 at 9:24 PM, Måns Rullgård wrote: >> Andy Shevchenko writes: >> >>> On Wed, 2016-01-20 at 18:50 +, Måns Rullgård wrote: Andy Shevchenko writes: > > Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver). > > > > Code here: > > https://bitbucket.org/mansr/linux-dwc/branch/dwc-sata > > Thanks for testing! Have you had time to look any more at these patches? >>> >>> Not yet. >>> I will look soon for sure. >>> >>> One comment still regarding to lli types. We can avoid warnings by >>> using (__force u32) in macros. >> >> But that won't give the benefits of having the types checked. > > You mean if we access the lli->field directly? I didn't quite get what > use case you are keeping in mind. Yes, accessing any of those fields directly with my patch gives a sparse warning. It's situations like these those checks are intended for. Defeating them seems foolish to me. -- Måns Rullgård
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Wed, Jan 20, 2016 at 9:24 PM, Måns Rullgård wrote: > Andy Shevchenko writes: > >> On Wed, 2016-01-20 at 18:50 +, Måns Rullgård wrote: >>> Andy Shevchenko writes: >>> >>> > > Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver). >>> > > >>> > > Code here: >>> > > https://bitbucket.org/mansr/linux-dwc/branch/dwc-sata >>> > >>> > Thanks for testing! >>> >>> Have you had time to look any more at these patches? >> >> Not yet. >> I will look soon for sure. >> >> One comment still regarding to lli types. We can avoid warnings by >> using (__force u32) in macros. > > But that won't give the benefits of having the types checked. You mean if we access the lli->field directly? I didn't quite get what use case you are keeping in mind. -- With Best Regards, Andy Shevchenko
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Wed, 2016-01-20 at 18:50 +, Måns Rullgård wrote: >> Andy Shevchenko writes: >> >> > > Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver). >> > > >> > > Code here: >> > > https://bitbucket.org/mansr/linux-dwc/branch/dwc-sata >> > >> > Thanks for testing! >> >> Have you had time to look any more at these patches? > > Not yet. > I will look soon for sure. > > One comment still regarding to lli types. We can avoid warnings by > using (__force u32) in macros. But that won't give the benefits of having the types checked. -- Måns Rullgård
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Wed, 2016-01-20 at 18:50 +, Måns Rullgård wrote: > Andy Shevchenko writes: > > > > Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver). > > > > > > Code here: > > > https://bitbucket.org/mansr/linux-dwc/branch/dwc-sata > > > > Thanks for testing! > > Have you had time to look any more at these patches? Not yet. I will look soon for sure. One comment still regarding to lli types. We can avoid warnings by using (__force u32) in macros. -- Andy Shevchenko Intel Finland Oy
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: >> Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver). >> >> Code here: >> https://bitbucket.org/mansr/linux-dwc/branch/dwc-sata > > Thanks for testing! Have you had time to look any more at these patches? -- Måns Rullgård
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Wed, 2016-01-06 at 19:36 +0200, Andy Shevchenko wrote: > On Wed, Jan 6, 2016 at 6:26 PM, Måns Rullgård wrote: > > Andy Shevchenko writes: > > > > > On Tue, 2015-12-22 at 00:08 +, Måns Rullgård wrote: > > > > Andy Shevchenko writes: > > > > > > > > > Here's what I have: https://bitbucket.org/mansr/linux-dwc > > > > Bitbucket because Github won't let me have more than one Linux > > > > repo. > > > > > > Thanks, got it. > > > > > > Will base my stuff on what you had done already. > > > > I've revived my AVR32 board, and after patching up some unrelated > > regressions, the MMC controller is working with the DMA driver as > > of 4.4-rc8 as well as with my patches applied. > > I'm going to publish my branch tomorrow. It has been tested a bit on > Intel hw, and works fine (yours patches are included with some slight > changes) So, Måns, Julian, I just have published my repository containing Måns' and my patches regarding dw_dmac and sata_dwc_460ex drivers here https://bitbucket.org/andy-shev/linux/branch/topic%2Fdw%2Fnext -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Wed, Jan 6, 2016 at 6:26 PM, Måns Rullgård wrote: > Andy Shevchenko writes: > >> On Tue, 2015-12-22 at 00:08 +, Måns Rullgård wrote: >>> Andy Shevchenko writes: >>> >>> > On Mon, 2015-12-21 at 19:27 +, Måns Rullgård wrote: >>> > > Andy Shevchenko writes: >>> > > >>> > > > I can share my working branch with a set of patches regarding >>> > > > to dw_dmac. We may do our work based on that code and after >>> > > > I'll submit everything to upstream. Does it sound okay for you, >>> > > > guys? >>> > > >>> > > I'm going away for the holidays, so I won't be able to do any >>> > > serious work on this until January, but I'll keep an eye on >>> > > emails and may even reply occasionally. Before I go, I'll >>> > > publish my patches so far whatever shape they're in. >>> > >>> > Okay, thanks! I will include them in my branch which I'm going to >>> > publish on GitHUB. >>> >>> Here's what I have: https://bitbucket.org/mansr/linux-dwc >>> Bitbucket because Github won't let me have more than one Linux >>> repo. >> >> Thanks, got it. >> >> Will base my stuff on what you had done already. > > I've revived my AVR32 board, and after patching up some unrelated > regressions, the MMC controller is working with the DMA driver as > of 4.4-rc8 as well as with my patches applied. I'm going to publish my branch tomorrow. It has been tested a bit on Intel hw, and works fine (yours patches are included with some slight changes) -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Tue, 2015-12-22 at 00:08 +, Måns Rullgård wrote: >> Andy Shevchenko writes: >> >> > On Mon, 2015-12-21 at 19:27 +, Måns Rullgård wrote: >> > > Andy Shevchenko writes: >> > > >> > > > I can share my working branch with a set of patches regarding >> > > > to dw_dmac. We may do our work based on that code and after >> > > > I'll submit everything to upstream. Does it sound okay for you, >> > > > guys? >> > > >> > > I'm going away for the holidays, so I won't be able to do any >> > > serious work on this until January, but I'll keep an eye on >> > > emails and may even reply occasionally. Before I go, I'll >> > > publish my patches so far whatever shape they're in. >> > >> > Okay, thanks! I will include them in my branch which I'm going to >> > publish on GitHUB. >> >> Here's what I have: https://bitbucket.org/mansr/linux-dwc >> Bitbucket because Github won't let me have more than one Linux >> repo. > > Thanks, got it. > > Will base my stuff on what you had done already. I've revived my AVR32 board, and after patching up some unrelated regressions, the MMC controller is working with the DMA driver as of 4.4-rc8 as well as with my patches applied. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Tue, 2015-12-22 at 00:08 +, Måns Rullgård wrote: > Andy Shevchenko writes: > > > On Mon, 2015-12-21 at 19:27 +, Måns Rullgård wrote: > > > Andy Shevchenko writes: > > > > > > > I can share my working branch with a set of patches regarding > > > > to > > > > dw_dmac. We may do our work based on that code and after I'll > > > > submit > > > > everything to upstream. Does it sound okay for you, guys? > > > > > > I'm going away for the holidays, so I won't be able to do any > > > serious > > > work on this until January, but I'll keep an eye on emails and > > > may > > > even reply occasionally. Before I go, I'll publish my patches so > > > far > > > whatever shape they're in. > > > > Okay, thanks! I will include them in my branch which I'm going to > > publish on GitHUB. > > Here's what I have: https://bitbucket.org/mansr/linux-dwc > Bitbucket because Github won't let me have more than one Linux > repo. Thanks, got it. Will base my stuff on what you had done already. -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Mon, 2015-12-21 at 19:27 +, Måns Rullgård wrote: >> Andy Shevchenko writes: >> >> > I can share my working branch with a set of patches regarding to >> > dw_dmac. We may do our work based on that code and after I'll >> > submit >> > everything to upstream. Does it sound okay for you, guys? >> >> I'm going away for the holidays, so I won't be able to do any serious >> work on this until January, but I'll keep an eye on emails and may >> even reply occasionally. Before I go, I'll publish my patches so far >> whatever shape they're in. > > Okay, thanks! I will include them in my branch which I'm going to > publish on GitHUB. Here's what I have: https://bitbucket.org/mansr/linux-dwc Bitbucket because Github won't let me have more than one Linux repo. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: >> > 4. CHECK: PROTCTL bit (documentation says that recommended value is >> > 0x01) >> >> Any idea what the value of 0x3 used by the old sata driver means? >> Presumably that's decided by the bus. > > Nope, documentation says that it is direct representation of hprot[3:1] > wires on the master interface. Also it refers to AMBA spec, so, if you > have access to AMBA spec I think we might get it from there. That's assuming AMCC didn't change something. >> > 5. CHECK: Other bits in CFG register (FIFO_MODE, FCMODE) >> > 6. CHECK: Block interrupts vs. one interrupt at the end of block >> > chain >> > (Måns, I missed how any of them is ignored) >> >> The interrupt handler looks at the StatusTfr and StatusErr registers >> and ignores StatusBlock. > > I have to refresh my memory, since BLOCK interrupts should be enabled > (unmasked) separately. I have forgotten which type of interrupt is > generated in this case, BLOCK, or XFER after each block, or only one > XFER at the last block (LLP.LOC = 0) and BLOCK are ignored. So, will > check later. I interpreted the, admittedly a bit vague, documentation as meaning BLOCK interrupts are signalled after each block and XFER interrupts after the last block. >> > 7. AR: Test everything on Intel SoCs such as Baytrail, CherryTrail, >> > etc (SPI, UART, dmatest), AVR32 (MMC, dmatest), PPC 460EX (Onboard >> > SATA) >> >> I can test on AVR32. That is as far as I know the only system I have >> with this DMA engine. > > If you have Intel Haswell, BayTrail, Braswell, CherryTrail, Broadwell, > you have it as well as long you have LPSS block there. (Most of them > are Atoms). I don't have any of those (or any Atom hardware). -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Mon, 2015-12-21 at 19:27 +, Måns Rullgård wrote: > Andy Shevchenko writes: > > > On Mon, 2015-12-21 at 01:19 +, Måns Rullgård wrote: > > > Andy Shevchenko writes: > > > > > > > P.S. I also noticed that original driver enables interrupt per > > > > each > > > > block > > > > > > And then ignores all but the transfer complete interrupt. > > > > > > > and sets protection control bits. > > > > > > With no indication what the value it sets is supposed to mean. > > > > Okay, let's summarize what we have: > > > > 0. AR: Get a working reference for PPC 460EX SATA driver > > Do we consider Julian's latest result working? I think so. > > > 1. AR: Clear LLP_EN bits at the last block of LLP transfer > > Patch sent. Acked. > > > 2. AR: Rename masters to 'memory' and 'peripheral' and change them > > per > > DMA direction > > Good idea. I'd call them memory and device though to match existing > dmaengine nomenclature. I remember how I called in my patch. So, there is no problem to rename, but will see. > > > 3. AR: Set LMS (LLP master) to 'memory' when do LLP transfers > > I started working on a patch for that already. Thanks. > > > 4. CHECK: PROTCTL bit (documentation says that recommended value is > > 0x01) > > Any idea what the value of 0x3 used by the old sata driver means? > Presumably that's decided by the bus. Nope, documentation says that it is direct representation of hprot[3:1] wires on the master interface. Also it refers to AMBA spec, so, if you have access to AMBA spec I think we might get it from there. > > > 5. CHECK: Other bits in CFG register (FIFO_MODE, FCMODE) > > 6. CHECK: Block interrupts vs. one interrupt at the end of block > > chain > > (Måns, I missed how any of them is ignored) > > The interrupt handler looks at the StatusTfr and StatusErr registers > and > ignores StatusBlock. I have to refresh my memory, since BLOCK interrupts should be enabled (unmasked) separately. I have forgotten which type of interrupt is generated in this case, BLOCK, or XFER after each block, or only one XFER at the last block (LLP.LOC = 0) and BLOCK are ignored. So, will check later. > > > 7. AR: Test everything on Intel SoCs such as Baytrail, CherryTrail, > > etc > > (SPI, UART, dmatest), AVR32 (MMC, dmatest), PPC 460EX (Onboard > > SATA) > > I can test on AVR32. That is as far as I know the only system I have > with this DMA engine. If you have Intel Haswell, BayTrail, Braswell, CherryTrail, Broadwell, you have it as well as long you have LPSS block there. (Most of them are Atoms). > > > I can share my working branch with a set of patches regarding to > > dw_dmac. We may do our work based on that code and after I'll > > submit > > everything to upstream. Does it sound okay for you, guys? > > I'm going away for the holidays, so I won't be able to do any serious > work on this until January, but I'll keep an eye on emails and may > even > reply occasionally. Before I go, I'll publish my patches so far > whatever shape they're in. Okay, thanks! I will include them in my branch which I'm going to publish on GitHUB. Happy holidays! -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
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 Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Mon, 2015-12-21 at 18:16 +, Måns Rullgård wrote: >> Andy Shevchenko writes: >> >> > On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård >> > wrote: >> > > Andy Shevchenko 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/21/2015 3:27 PM, Måns Rullgård wrote: Julian Margetson writes: On 12/21/2015 2:27 PM, Måns Rullgård wrote: Julian Margetson writes: On 12/21/2015 1:55 PM, Andy Shevchenko wrote: On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson 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 wrote: On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > On 12/21/2015 2:27 PM, Måns Rullgård wrote: >> Julian Margetson writes: >> >>> On 12/21/2015 1:55 PM, Andy Shevchenko wrote: On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson 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 >>> wrote: On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Mon, 2015-12-21 at 01:19 +, Måns Rullgård wrote: >> Andy Shevchenko writes: >> >> > P.S. I also noticed that original driver enables interrupt per each >> > block >> >> And then ignores all but the transfer complete interrupt. >> >> > and sets protection control bits. >> >> With no indication what the value it sets is supposed to mean. > > Okay, let's summarize what we have: > > 0. AR: Get a working reference for PPC 460EX SATA driver Do we consider Julian's latest result working? > 1. AR: Clear LLP_EN bits at the last block of LLP transfer Patch sent. > 2. AR: Rename masters to 'memory' and 'peripheral' and change them per > DMA direction Good idea. I'd call them memory and device though to match existing dmaengine nomenclature. > 3. AR: Set LMS (LLP master) to 'memory' when do LLP transfers I started working on a patch for that already. > 4. CHECK: PROTCTL bit (documentation says that recommended value is > 0x01) Any idea what the value of 0x3 used by the old sata driver means? Presumably that's decided by the bus. > 5. CHECK: Other bits in CFG register (FIFO_MODE, FCMODE) > 6. CHECK: Block interrupts vs. one interrupt at the end of block chain > (Måns, I missed how any of them is ignored) The interrupt handler looks at the StatusTfr and StatusErr registers and ignores StatusBlock. > 7. AR: Test everything on Intel SoCs such as Baytrail, CherryTrail, etc > (SPI, UART, dmatest), AVR32 (MMC, dmatest), PPC 460EX (Onboard SATA) I can test on AVR32. That is as far as I know the only system I have with this DMA engine. > I can share my working branch with a set of patches regarding to > dw_dmac. We may do our work based on that code and after I'll submit > everything to upstream. Does it sound okay for you, guys? I'm going away for the holidays, so I won't be able to do any serious work on this until January, but I'll keep an eye on emails and may even reply occasionally. Before I go, I'll publish my patches so far whatever shape they're in. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Mon, 2015-12-21 at 18:16 +, Måns Rullgård wrote: > Andy Shevchenko writes: > > > On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård > > wrote: > > > Andy Shevchenko 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 Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/21/2015 2:27 PM, Måns Rullgård wrote: Julian Margetson writes: On 12/21/2015 1:55 PM, Andy Shevchenko wrote: On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson 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 wrote: On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/21/2015 2:27 PM, Måns Rullgård wrote: Julian Margetson writes: On 12/21/2015 1:55 PM, Andy Shevchenko wrote: On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson 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 wrote: On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 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? Ah. Will try with debug disabled. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Mon, 2015-12-21 at 01:19 +, Måns Rullgård wrote: > Andy Shevchenko writes: > > > P.S. I also noticed that original driver enables interrupt per each > > block > > And then ignores all but the transfer complete interrupt. > > > and sets protection control bits. > > With no indication what the value it sets is supposed to mean. Okay, let's summarize what we have: 0. AR: Get a working reference for PPC 460EX SATA driver 1. AR: Clear LLP_EN bits at the last block of LLP transfer 2. AR: Rename masters to 'memory' and 'peripheral' and change them per DMA direction 3. AR: Set LMS (LLP master) to 'memory' when do LLP transfers 4. CHECK: PROTCTL bit (documentation says that recommended value is 0x01) 5. CHECK: Other bits in CFG register (FIFO_MODE, FCMODE) 6. CHECK: Block interrupts vs. one interrupt at the end of block chain (Måns, I missed how any of them is ignored) 7. AR: Test everything on Intel SoCs such as Baytrail, CherryTrail, etc (SPI, UART, dmatest), AVR32 (MMC, dmatest), PPC 460EX (Onboard SATA) I can share my working branch with a set of patches regarding to dw_dmac. We may do our work based on that code and after I'll submit everything to upstream. Does it sound okay for you, guys? -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > On 12/21/2015 1:55 PM, Andy Shevchenko wrote: >> On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson 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 > wrote: >> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård >> 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? -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson 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 wrote: > > On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård > 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? Looks that way to me. At least it's able to read the partition table. What happens after that is hard to tell, but I don't see any obvious errors. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/21/2015 1:55 PM, Andy Shevchenko wrote: On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson 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 wrote: On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Mon, 2015-12-21 at 15:24 +, Måns Rullgård wrote: >> Julian Margetson 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). Done. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård wrote: >> Andy Shevchenko writes: >> >>> +Viresh >>> >>> On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård wrote: Andy Shevchenko writes: > On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: >> Julian Margetson writes: >>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: Julian Margetson 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Mon, Dec 21, 2015 at 7:26 PM, Julian Margetson 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 >>> wrote: On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 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? -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Mon, Dec 21, 2015 at 2:15 PM, Måns Rullgård wrote: > Andy Shevchenko writes: > >> +Viresh >> >> On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård wrote: >>> Andy Shevchenko writes: >>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: > Julian Margetson writes: >> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>> Julian Margetson 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
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 wrote: On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård 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. patch -p1 -R <../0001-dw_dmac-debug-dma-controller-IO.patch patching file drivers/dma/dw/core.c Hunk #1 succeeded at 543 (offset -27 lines). Hunk #2 FAILED at 1571. Hunk #3 FAILED at 1717. 2 out of 3 hunks FAILED -- saving rejects to file drivers/dma/dw/core.c.rej patching file drivers/dma/dw/regs.h Hunk #1 succeeded at 114 (offset -16 lines). Hunk #2 succeeded at 262 (offset -39 lines). Hunk #3 succeeded at 293 (offset -40 lines). root@julian-VirtualBox:/usr/src/linux-test# patch -p1 <../0001-dw_dmac-debug-dma-controller-IO.patch patching file drivers/dma/dw/core.c Hunk #1 succeeded at 543 (offset -27 lines). Hunk #2 FAILED at 1572. Hunk #3 FAILED at 1716. 2 out of 3 hunks FAILED -- saving rejects to file drivers/dma/dw/core.c.rej patching file drivers/dma/dw/regs.h Hunk #1 succeeded at 114 (offset -16 lines). Hunk #2 succeeded at 264 (offset -39 lines). Hunk #3 succeeded at 307 (offset -40 lines). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Sun, 2015-12-20 at 22:55 +0200, Andy Shevchenko wrote:
> On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko
> wrote:
> > On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård
> > 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.
--
Andy Shevchenko
Intel Finland Oy
From c824845238f0e027d480bfc3b9ad482ae901b78b Mon Sep 17 00:00:00 2001
From: Andy Shevchenko
Date: Mon, 4 Jun 2012 10:14:50 +0300
Subject: [PATCH v2] dw_dmac: debug dma controller IO
Signed-off-by: Andy Shevchenko
---
drivers/dma/dw/core.c | 8 +---
drivers/dma/dw/regs.h | 26 ++
2 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index dcf19f0..d50c39c 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -570,9 +570,10 @@ static void dwc_handle_cyclic(struct dw_dma *dw, struct dw_dma_chan *dwc,
if (dwc->mask) {
void (*callback)(void *param);
void *callback_param;
+ dma_addr_t llp = channel_readl(dwc, LLP);
- dev_vdbg(chan2dev(&dwc->chan), "new cyclic period llp 0x%08x\n",
-channel_readl(dwc, LLP));
+ dev_vdbg(chan2dev(&dwc->chan), "new cyclic period llp %pad\n",
+&llp);
callback = dwc->cdesc->period_callback;
callback_param = dwc->cdesc->period_callback_param;
@@ -1571,6 +1572,8 @@ int dw_dma_probe(struct dw_dma_chip *chip, struct dw_dma_platform_data *pdata)
pm_runtime_get_sync(chip->dev);
+ dw->dma.dev = chip->dev;
+
dw_params = dma_read_byaddr(chip->regs, DW_PARAMS);
autocfg = dw_params >> DW_PARAMS_EN & 0x1;
@@ -1715,7 +1718,6 @@ int dw_dma_probe(struct dw_dma_chip *chip, struct dw_dma_platform_data *pdata)
dma_cap_set(DMA_SLAVE, dw->dma.cap_mask);
if (pdata->is_private)
dma_cap_set(DMA_PRIVATE, dw->dma.cap_mask);
- dw->dma.dev = chip->dev;
dw->dma.device_alloc_chan_resources = dwc_alloc_chan_resources;
dw->dma.device_free_chan_resources = dwc_free_chan_resources;
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index 3a3a5e1..a3b881c 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -130,6 +130,8 @@ struct dw_dma_regs {
#define dma_writel_native writel
#endif
+#define DW_DMAC_IO_DEBUG
+
/* To access the registers in early stage of probe */
#define dma_read_byaddr(addr, name) \
dma_readl_native((addr) + offsetof(struct dw_dma_regs, name))
@@ -301,10 +303,22 @@ __dwc_regs(struct dw_dma_chan *dwc)
return dwc->ch_regs;
}
+#ifdef DW_DMAC_IO_DEBUG
+#define channel_readl(dwc, name) ({ \
+ unsigned int val = dma_readl_native(&(__dwc_regs(dwc)->name)); \
+ dev_dbg(chan2dev(&dwc->chan), "readl: " #name " 0x%08x\n", (u32)val); \
+ val; \
+})
+#define channel_writel(dwc, name, val) ({ \
+ dev_dbg(chan2dev(&dwc->chan), "writel: " #name " 0x%08x\n", (u32)val); \
+ dma_writel_native((val), &(__dwc_regs(dwc)->name)); \
+})
+#else
#define channel_readl(dwc, name) \
dma_readl_native(&(__dwc_regs(dwc)->name))
#define channel_writel(dwc, name, val) \
dma_writel_native((val), &(__dwc_regs(dwc)->name))
+#endif
static inline struct dw_dma_chan *to_dw_dma_chan(struct dma_chan *chan)
{
@@ -333,10 +347,22 @@ static inline struct dw_dma_regs __iomem *__dw_regs(struct dw_dma *dw)
return dw->regs;
}
+#ifdef DW_DMAC_IO_DEBUG
+#define dma_readl(dw, name) ({ \
+ unsigned int val = dma_readl_native(&(__dw_regs(dw)->name)); \
+ dev_dbg(dw->dma.dev, "readl: " #name " 0x%08x\n", (u32)val); \
+ val;\
+})
+#define dma_writel(dw, name, val) ({ \
+ dev_dbg(dw->dma.dev, "writel: " #name " 0x%08x\n", (u32)val); \
+ dma_writel_native((val), &(__dw_regs(dw)->name)); \
+})
+#else
#define dma_readl(dw, name) \
dma_readl_native(&(__dw_regs(dw)->name))
#define dma_writel(dw, name, val) \
dma_writel_native((val), &(__dw_regs(dw)->name))
+#endif
#define channel_set_bit(dw, reg, mask) \
dma_writel(dw, reg, ((mask) << 8) | (mask))
--
2.1.3
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Mon, 2015-12-21 at 15:24 +, Måns Rullgård wrote: > Julian Margetson 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 Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/21/2015 9:24 AM, Måns Rullgård wrote:
>> Julian Margetson 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 ' or 'git rm '
> 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
>From 53f3cf096f959a58fe6339f4f8b57b6e749b283e Mon Sep 17 00:00:00 2001
From: Mans Rullgard
Date: Sat, 19 Dec 2015 15:26:23 +
Subject: [PATCH] ata: sata_dwc_460ex: remove incorrect locking
This lock is already taken in ata_scsi_queuecmd() a few levels up the
call stack so attempting to take it here is an error. Moreover, it is
pointless in the first place since it only protects a single, atomic
assignment.
Signed-off-by: Mans Rullgard
---
drivers/ata/sata_dwc_460ex.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index fdb0f28..d404af8 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -1403,15 +1403,13 @@ static void sata_dwc_exec_command_by_tag(struct ata_port *a
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson 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 ' or 'git rm '
>>> 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
--
Måns Rullgård
/*
* drivers/ata/sata_dwc_460ex.c
*
* Synopsys DesignWare Cores (DWC) SATA host driver
*
* Author: Mark Miesfeld
*
* Ported from 2.6.19.2 to 2.6.25/26 by Stefan Roese
* Copyright 2008 DENX Software Engineering
*
* Based on versions provided by AMCC and Synopsys which are:
* Copyright 2006 Applied Micro Circuits Corporation
* COPYRIGHT (C) 2005 SYNOPSYS, INC. ALL RIGHTS RESERVED
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
#ifdef CONFIG_SATA_DWC_DEBUG
#define DEBUG
#endif
#ifdef CONFIG_SATA_DWC_VDEBUG
#define VERBOSE_DEBUG
#define DEBUG_NCQ
#endif
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "libata.h"
#include
#include
/* These two are defined in "libata.h" */
#undef DRV_NAME
#undef DRV_VERSION
#define DRV_NAME"sata-dwc"
#define DRV_VERSION "1.3"
#ifndef out_le32
#define out_le32(a, v) __raw_writel(__cpu_to_le32(v), (void __iomem *)(a))
#endif
#ifndef in_le32
#define in_le32(a) __le32_to_cpu(__raw_readl((void __iomem *)(a)))
#endif
#ifndef NO_IRQ
#define NO_IRQ 0
#endif
/* SATA DMA driver Globals */
#define DMA_NUM_CHANS 1
#define DMA_NUM_CHAN_REGS 8
/* SATA DMA Register definitions */
#define AHB_DMA_BRST_DFLT 64 /* 16 data items burst length*/
struct dmareg {
u32 low; /* Low bits 0-31 */
u32 high; /* High bits 32-63 */
};
/* DMA Per Channel registers */
struct dma_chan_regs {
struct dmareg sar; /* Source Address */
struct dmareg dar; /* Destination address */
struct dmareg llp; /* Linked List Pointer */
struct dmareg ctl; /* Control */
struct dmareg sstat; /* Source Status not implemented in core */
struct dmareg dstat; /* Destination Status not implemented in core*/
struct dmareg sstatar; /* Source Status Address not impl in core */
struct dmareg dstatar; /* Destination Status Address not implemente */
struct dmareg cfg; /* Config */
struct dmareg sgr; /* Source Gather */
struct dmareg dsr; /* Destination Scatter */
};
/* Generic Interrupt Registers */
struct dma_interrupt_regs {
struct dmareg tfr; /* Transfer In
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/21/2015 8:16 AM, Måns Rullgård wrote:
Julian Margetson 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 wrote:
Andy Shevchenko writes:
On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/20/2015 1:11 PM, Måns Rullgård wrote:
Julian Margetson 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 ' or 'git rm '
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 unsubsc
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson 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 wrote: >>> Andy Shevchenko writes: >>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: > Julian Margetson writes: >> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>> Julian Margetson 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 ' or 'git rm ' > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > +Viresh > > On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård wrote: >> Andy Shevchenko writes: >> >>> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: Julian Margetson writes: > On 12/20/2015 1:11 PM, Måns Rullgård wrote: >> Julian Margetson 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
+Viresh On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård wrote: > Andy Shevchenko writes: > >> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: >>> Julian Margetson writes: On 12/20/2015 1:11 PM, Måns Rullgård wrote: > Julian Margetson 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko > wrote: >> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: >>> Julian Margetson writes: On 12/20/2015 1:11 PM, Måns Rullgård wrote: > Julian Margetson 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). >> >>> 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. > > 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. > > P.S. I also noticed that original driver enables interrupt per each > block And then ignores all but the transfer complete interrupt. > and sets protection control bits. With no indication what the value it sets is supposed to mean. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Måns Rullgård writes: > Andy Shevchenko writes: > >> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: >>> Julian Margetson writes: On 12/20/2015 1:11 PM, Måns Rullgård wrote: > Julian Margetson 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: >> Julian Margetson writes: >>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: Julian Margetson 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: >> Julian Margetson writes: >>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: Julian Margetson 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko wrote: > On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: >> Julian Margetson writes: >>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: Julian Margetson 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). > >> 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. 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. P.S. I also noticed that original driver enables interrupt per each block and sets protection control bits. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård wrote: > Julian Margetson writes: >> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>> Julian Margetson 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). > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > On 12/20/2015 1:11 PM, Måns Rullgård wrote: >> Julian Margetson writes: >> >>> On 12/19/2015 4:41 PM, Måns Rullgård wrote: Andy Shevchenko writes: > On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson > wrote: >> On 12/19/2015 3:07 PM, Måns Rullgård wrote: >>> Julian Margetson writes: Total pages: 522752 [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg >>> Please add ignore_log_level. >>> >> Had to truncate the kernel command line to add it. > I guess Måns meant 'ignore_loglevel' Obviously. I can never remember where the underscores go. >>> [ 18.362244] sd 3:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 >>> GB/465 GiB) >>> [ 18.372454] sd 3:0:0:0: Attached scsi generic sg3 type 0 >>> [ 18.405433] sd 3:0:0:0: [sdc] Write Protect is off >>> [ 18.420654] sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 >>> [ 18.461731] sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, >>> doesn't support DPO or FUA >>> [ 18.502918] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: port=0 dma >>> dir=from device n_elem=1 >>> [ 18.511807] dma dma0chan0: dwc_prep_slave_sg >>> [ 18.516083] dma dma0chan0: scanned 1 descriptors on freelist >>> [ 18.521753] sata-dwc 4bffd1000.sata: dma_dwc_xfer_setup sg: 0xedeaa800, >>> count: 1 addr: 0xf6a14400 >>> [ 18.531327] sata-dwc 4bffd1000.sata: sata_dwc_qc_issue: tag=0 >>> ap->link.sactive = 0x0001 sactive=0x0001 >>> [ 18.541359] sata-dwc 4bffd1000.sata: sata_dwc_exec_command_by_tag >>> cmd(0x60): READ FPDMA QUEUED tag=0 >>> [ 18.553703] sata-dwc 4bffd1000.sata: sata_dwc_isr intpr=0x0082 >>> active_tag=-84148995 >>> [ 18.561717] sata-dwc 4bffd1000.sata: sata_dwc_isr: NEWFP tag=0 >>> [ 18.567561] sata-dwc 4bffd1000.sata: sata_dwc_bmdma_start_by_tag >>> qc=ed2340b8 tag: 0 cmd: 0x60 dma_dir: from device start_dma? 1 >>> [ 18.579043] sata-dwc 4bffd1000.sata: taskfile cmd: 0x60 protocol: ATA >>> NCQ flags: 0x17 device: 40 >>> [ 18.587836] sata-dwc 4bffd1000.sata: feature: 0x08 nsect: 0x0 lbal: 0x0 >>> lbam: 0x0 lbah: 0x0 >>> [ 18.596196] sata-dwc 4bffd1000.sata: hob_feature: 0x00 hob_nsect: 0x0 >>> hob_lbal: 0x0 hob_lbam: 0x0 hob_lbah: 0x0 >>> [ 18.606292] dma dma0chan0: dwc_tx_submit: queued 2 >>> [ 18.611091] dma dma0chan0: dwc_dostart_first_queued: started 2 >>> [ 48.748614] ata3: lost interrupt (Status 0x40) >> Now we're getting somewhere. The dma transfer is set up and initiated, >> but then nothing happens. Comparing the old sata_dwc driver, from >> before the switch to dmaengine, with the dw_dma driver, I noticed an >> obvious problem: the descriptors are filled in using the wrong byte >> order. This patch might fix that. > > [ 18.534844] ata3.00: configured for UDMA/133 > [ 18.538182] scsi 3:0:0:0: Direct-Access ATA WDC WD5000AAKS-0 3B01 > PQ: 0 ANSI: 5 > [ 18.539025] sd 3:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 > GB/465 GiB) > [ 18.539236] sd 3:0:0:0: [sdc] Write Protect is off > [ 18.539245] sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 > [ 18.539338] sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, > doesn't support DPO or FUA > [ 18.540049] sd 3:0:0:0: Attached scsi generic sg3 type 0 > [ 18.540362] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: port=0 dma > dir=from device n_elem=1 > [ 18.540370] dma dma0chan0: dwc_prep_slave_sg > [ 18.540378] dma dma0chan0: scanned 1 descriptors on freelist > [ 18.540387] sata-dwc 4bffd1000.sata: dma_dwc_xfer_setup sg: 0xed37f200, > count: 1 addr: 0xf6a18400 > [ 18.540395] sata-dwc 4bffd1000.sata: sata_dwc_qc_issue: tag=0 > ap->link.sactive = 0x0001 sactive=0x0001 > [ 18.540426] sata-dwc 4bffd1000.sata: sata_dwc_exec_command_by_tag > cmd(0x60): READ FPDMA QUEUED tag=0 > [ 18.556592] sata-dwc 4bffd1000.sata: sata_dwc_isr intpr=0x0082 > active_tag=-84148995 > [ 18.556599] sata-dwc 4bffd1000.sata: sata_dwc_isr: NEWFP tag=0 > [ 18.556609] sata-dwc 4bffd1000.sata: sata_dwc_bmdma_start_by_tag > qc=ed2180b8 tag: 0 cmd: 0x60 dma_dir: from device start_dma? 1 > [ 18.556616] sata-dwc 4bffd1000.sata: taskfile cmd: 0x60 protocol: ATA NCQ > flags: 0x17 device: 40 > [ 18.556623] sata-dwc 4bffd1000.sata: feature: 0x08 nsect: 0x0 lbal: 0x0 > lbam: 0x0 lbah: 0x0 > [ 18.556631] sata-dwc 4bffd1000.sata: hob_feature: 0x00 hob_nsect: 0x0 > hob_lbal: 0x0 hob_lbam: 0x0 hob_lbah: 0x0 > [ 18.556639] dma dma0chan0: dwc_tx_submit: queued 2 > [ 18.556646] dma dma0chan0: dwc_dostart_first_queued: started 2 > [ 48.748634] ata3: lost interrupt (Status 0x40) > [ 48.753465] sata-dwc 4bffd1000.sata: sata_dwc_scr_read: id=3 reg=1 > val=val=0x > [ 48.761369] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 > frozen > [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED Well, that didn't he
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Sun, Dec 20, 2015 at 7:11 PM, Måns Rullgård wrote: >> Julian Margetson writes: >> >>> On 12/19/2015 4:41 PM, Måns Rullgård wrote: Andy Shevchenko writes: > On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson > wrote: >> On 12/19/2015 3:07 PM, Måns Rullgård wrote: >>> Julian Margetson writes: > >>> [ 18.606292] dma dma0chan0: dwc_tx_submit: queued 2 >>> [ 18.611091] dma dma0chan0: dwc_dostart_first_queued: started 2 >>> [ 48.748614] ata3: lost interrupt (Status 0x40) >> >> Now we're getting somewhere. The dma transfer is set up and initiated, >> but then nothing happens. Comparing the old sata_dwc driver, from >> before the switch to dmaengine, with the dw_dma driver, I noticed an >> obvious problem: the descriptors are filled in using the wrong byte >> order. > > So, it means we have IO in little endian, but DMA reads data from > memory in big endian? No, it means the IO is little endian, and the DMA reads from memory in little endian while the host CPU is big endian. >> This patch might fix that. > > In case it works I have to test it on AVR32. Unless I made a mistake, there should be no difference there. Still got to test it of course. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Sun, Dec 20, 2015 at 7:11 PM, Måns Rullgård wrote: > Julian Margetson writes: > >> On 12/19/2015 4:41 PM, Måns Rullgård wrote: >>> Andy Shevchenko writes: >>> On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson wrote: > On 12/19/2015 3:07 PM, Måns Rullgård wrote: >> Julian Margetson writes: >> [ 18.606292] dma dma0chan0: dwc_tx_submit: queued 2 >> [ 18.611091] dma dma0chan0: dwc_dostart_first_queued: started 2 >> [ 48.748614] ata3: lost interrupt (Status 0x40) > > Now we're getting somewhere. The dma transfer is set up and initiated, > but then nothing happens. Comparing the old sata_dwc driver, from > before the switch to dmaengine, with the dw_dma driver, I noticed an > obvious problem: the descriptors are filled in using the wrong byte > order. So, it means we have IO in little endian, but DMA reads data from memory in big endian? > This patch might fix that. In case it works I have to test it on AVR32. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/19/2015 4:41 PM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>> On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson wrote:
On 12/19/2015 3:07 PM, Måns Rullgård wrote:
> Julian Margetson writes:
>> Total pages: 522752
>> [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200
>> console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg
> Please add ignore_log_level.
>
Had to truncate the kernel command line to add it.
>>> I guess Måns meant 'ignore_loglevel'
>> Obviously. I can never remember where the underscores go.
>
> [ 18.362244] sd 3:0:0:0: [sdc] 976773168 512-byte logical blocks: (500
> GB/465 GiB)
> [ 18.372454] sd 3:0:0:0: Attached scsi generic sg3 type 0
> [ 18.405433] sd 3:0:0:0: [sdc] Write Protect is off
> [ 18.420654] sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
> [ 18.461731] sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled,
> doesn't support DPO or FUA
> [ 18.502918] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: port=0 dma
> dir=from device n_elem=1
> [ 18.511807] dma dma0chan0: dwc_prep_slave_sg
> [ 18.516083] dma dma0chan0: scanned 1 descriptors on freelist
> [ 18.521753] sata-dwc 4bffd1000.sata: dma_dwc_xfer_setup sg: 0xedeaa800,
> count: 1 addr: 0xf6a14400
> [ 18.531327] sata-dwc 4bffd1000.sata: sata_dwc_qc_issue: tag=0
> ap->link.sactive = 0x0001 sactive=0x0001
> [ 18.541359] sata-dwc 4bffd1000.sata: sata_dwc_exec_command_by_tag
> cmd(0x60): READ FPDMA QUEUED tag=0
> [ 18.553703] sata-dwc 4bffd1000.sata: sata_dwc_isr intpr=0x0082
> active_tag=-84148995
> [ 18.561717] sata-dwc 4bffd1000.sata: sata_dwc_isr: NEWFP tag=0
> [ 18.567561] sata-dwc 4bffd1000.sata: sata_dwc_bmdma_start_by_tag
> qc=ed2340b8 tag: 0 cmd: 0x60 dma_dir: from device start_dma? 1
> [ 18.579043] sata-dwc 4bffd1000.sata: taskfile cmd: 0x60 protocol: ATA NCQ
> flags: 0x17 device: 40
> [ 18.587836] sata-dwc 4bffd1000.sata: feature: 0x08 nsect: 0x0 lbal: 0x0
> lbam: 0x0 lbah: 0x0
> [ 18.596196] sata-dwc 4bffd1000.sata: hob_feature: 0x00 hob_nsect: 0x0
> hob_lbal: 0x0 hob_lbam: 0x0 hob_lbah: 0x0
> [ 18.606292] dma dma0chan0: dwc_tx_submit: queued 2
> [ 18.611091] dma dma0chan0: dwc_dostart_first_queued: started 2
> [ 48.748614] ata3: lost interrupt (Status 0x40)
Now we're getting somewhere. The dma transfer is set up and initiated,
but then nothing happens. Comparing the old sata_dwc driver, from
before the switch to dmaengine, with the dw_dma driver, I noticed an
obvious problem: the descriptors are filled in using the wrong byte
order. This patch might fix that.
--
Måns Rullgård
>From 04b444b301c8b2db732dbf259dddb3dc87d622c8 Mon Sep 17 00:00:00 2001
From: Mans Rullgard
Date: Sun, 20 Dec 2015 16:54:21 +
Subject: [PATCH] dmaengine: dw: fix byte order of hw descriptor fields
If the DMA controller uses a different byte order than the host CPU,
the hardware linked list descriptor fields need to be byte-swapped.
This patch makes the driver write these fields using the same byte
order it uses for mmio accesses to the DMA engine. I do not know
if this is guaranteed to always be correct.
Signed-off-by: Mans Rullgard
---
drivers/dma/dw/core.c | 84 +++
drivers/dma/dw/regs.h | 26 +++-
2 files changed, 63 insertions(+), 47 deletions(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 7067b6d..b954904 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -209,12 +209,12 @@ static inline void dwc_do_single_block(struct dw_dma_chan *dwc,
* Software emulation of LLP mode relies on interrupts to continue
* multi block transfer.
*/
- ctllo = desc->lli.ctllo | DWC_CTLL_INT_EN;
+ ctllo = dw_lli_read(desc->lli.ctllo) | DWC_CTLL_INT_EN;
- channel_writel(dwc, SAR, desc->lli.sar);
- channel_writel(dwc, DAR, desc->lli.dar);
+ channel_writel(dwc, SAR, dw_lli_read(desc->lli.sar));
+ channel_writel(dwc, DAR, dw_lli_read(desc->lli.dar));
channel_writel(dwc, CTL_LO, ctllo);
- channel_writel(dwc, CTL_HI, desc->lli.ctlhi);
+ channel_writel(dwc, CTL_HI, dw_lli_read(desc->lli.ctlhi));
channel_set_bit(dw, CH_EN, dwc->mask);
/* Move pointer to next descriptor */
@@ -432,7 +432,7 @@ static void dwc_scan_descriptors(struct dw_dma *dw, struct dw_dma_chan *dwc)
}
/* Check first descriptors llp */
- if (desc->lli.llp == llp) {
+ if (dw_lli_read(desc->lli.llp) == llp) {
/* This one is currently in progress */
dwc->residue -= dwc_get_sent(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
@@ -441,7 +441,7 @@ static void dwc_scan_descriptors(struct dw_dma *dw, struct dw_dma_chan *dwc)
dwc->residue -= desc->len;
list_for_each_entry(child, &desc->tx_list, desc_node) {
- if (child->lli.llp == llp) {
+ if (dw_lli_read(child->lli.llp) == llp) {
/* Currently in progress */
dwc->residue -= dwc_get_sent(dwc);
spin_unlock_irqrestore(&dwc->
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/19/2015 4:41 PM, Måns Rullgård wrote: Andy Shevchenko writes: On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson wrote: On 12/19/2015 3:07 PM, Måns Rullgård wrote: Julian Margetson writes: Total pages: 522752 [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg Please add ignore_log_level. Had to truncate the kernel command line to add it. I guess Måns meant 'ignore_loglevel' Obviously. I can never remember where the underscores go. :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: > On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson wrote: >> On 12/19/2015 3:07 PM, Måns Rullgård wrote: >>> Julian Margetson writes: > Total pages: 522752 [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg >>> >>> Please add ignore_log_level. >>> >> Had to truncate the kernel command line to add it. > > I guess Måns meant 'ignore_loglevel' Obviously. I can never remember where the underscores go. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Sat, Dec 19, 2015 at 10:16 PM, Julian Margetson wrote: > On 12/19/2015 3:07 PM, Måns Rullgård wrote: >> Julian Margetson writes: >>> Total pages: 522752 >>> [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 >>> console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg >> >> Please add ignore_log_level. >> > Had to truncate the kernel command line to add it. I guess Måns meant 'ignore_loglevel' -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/19/2015 3:07 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/19/2015 1:19 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/19/2015 1:05 PM, Måns Rullgård wrote:
Andy Shevchenko writes:
On Sat, Dec 19, 2015 at 5:40 PM, Måns Rullgård wrote:
OK, I've found something. The dma setup errors are benign, caused by
the driver calling dmaengine_prep_slave_sg() even for non-dma
operations.
I suppose the following is a quick fix to avoid preparing descriptor
for non-DMA operations (not tested anyhow)
a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -1041,6 +1041,9 @@ static void sata_dwc_qc_prep_by_tag(struct
ata_queued_cmd *qc, u8 tag)
__func__, ap->port_no, get_dma_dir_descript(qc->dma_dir),
qc->n_elem);
+ if (!is_slave_direction(qc->dma_dir))
+ return;
+
desc = dma_dwc_xfer_setup(qc);
if (!desc) {
dev_err(ap->dev, "%s: dma_dwc_xfer_setup returns NULL\n",
I already have a better patch sitting here.
The real error is the lock recursion that's reported
later. I wasn't seeing it since I was running a UP non-preempt kernel.
With lock debugging enabled, I get the same error. This patch should
fix it.
- spin_lock_irqsave(&ap->host->lock, flags);
hsdevp->cmd_issued[tag] = cmd_issued;
- spin_unlock_irqrestore(&ap->host->lock, flags);
+
This will create a second empty line, though I don't care it is so minor.
The patch leaves one blank line before the following block comment. I
think it looks better that way.
Still can't get the patch applied .
Sorry, didn't realise it conflicted with an intervening patch I had in
my tree. Try this one.
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.19 14:44:52 =~=~=~=~=~=~=~=~=~=~=~=
U-Boot 2015.a (May 16 2015 - 14:20:11)
CPU: AMCC PowerPC 460EX Rev. B at 1155 MHz (PLB=231 OPB=115 EBC=115)
No Security/Kasumi support
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
Internal PCI arbiter enabled
32 kB I-Cache 32 kB D-Cache
Board: Sam460ex/cr, PCIe 4x + SATA-2
I2C: ready
DRAM: 2 GiB (ECC not enabled, 462 MHz, CL4)
PCI: Bus Dev VenId DevId Class Int
00 04 1095 3512 0104 00
00 06 126f 0501 0380 00
PCIE1: successfully set as root-complex
02 00 1002 683f 0300 ff
Net: ppc_4xx_eth0
FPGA: Revision 03 (2010-10-07)
SM502: found
PERMD2:not found
VGA: 1
VESA: OK
[0.00] Using Canyonlands machine description
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) (gcc
version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #1 PREEMPT Sat Dec 19 14:25:55 AST 2015
[0.00] Zone ranges:
[0.00] DMA [mem 0x-0x2fff]
[0.00] Normal empty
[0.00] HighMem [mem 0x3000-0x7fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x-0x7fff]
[0.00] Initmem setup node 0 [mem 0x-0x7fff]
[0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 522752
[0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200
console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg
Please add ignore_log_level.
Had to truncate the kernel command line to add it.
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.19 15:59:55 =~=~=~=~=~=~=~=~=~=~=~=
U-Boot 2015.a (May 16 2015 - 14:20:11)
CPU: AMCC PowerPC 460EX Rev. B at 1155 MHz (PLB=231 OPB=115 EBC=115)
No Security/Kasumi support
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
Internal PCI arbiter enabled
32 kB I-Cache 32 kB D-Cache
Board: Sam460ex/cr, PCIe 4x + SATA-2
I2C: ready
DRAM: 2 GiB (ECC not enabled, 462 MHz, CL4)
PCI: Bus Dev VenId DevId Class Int
00 04 1095 3512 0104 00
00 06 126f 0501 0380 00
PCIE1: successfully set as root-complex
02 00 1002 683f 0300 ff
Net: ppc_4xx_eth0
FPGA: Revision 03 (2010-10-07)
SM502: found
PERMD2:not found
VGA: 1
VESA: OK
[0.00] Using Canyonlands machine description
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) (gcc
version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #1 PREEMPT Sat Dec 19 14:25:55 AST 2015
[0.00] Zone ranges:
[0.00] DMA [mem 0x-0x2fff]
[0.00] Normal empty
[0.00] HighMem [mem 0x3000-0x7fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x-0x7fff]
[0.00] Initmem setup node 0 [mem 0x-0x7fff]
[
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/19/2015 1:19 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/19/2015 1:05 PM, Måns Rullgård wrote:
Andy Shevchenko writes:
> On Sat, Dec 19, 2015 at 5:40 PM, Måns Rullgård wrote:
>
>> OK, I've found something. The dma setup errors are benign, caused by
>> the driver calling dmaengine_prep_slave_sg() even for non-dma
>> operations.
> I suppose the following is a quick fix to avoid preparing descriptor
> for non-DMA operations (not tested anyhow)
>
> a/drivers/ata/sata_dwc_460ex.c
> +++ b/drivers/ata/sata_dwc_460ex.c
> @@ -1041,6 +1041,9 @@ static void sata_dwc_qc_prep_by_tag(struct
> ata_queued_cmd *qc, u8 tag)
> __func__, ap->port_no,
> get_dma_dir_descript(qc->dma_dir),
>qc->n_elem);
>
> + if (!is_slave_direction(qc->dma_dir))
> + return;
> +
> desc = dma_dwc_xfer_setup(qc);
> if (!desc) {
> dev_err(ap->dev, "%s: dma_dwc_xfer_setup returns
> NULL\n",
I already have a better patch sitting here.
>> The real error is the lock recursion that's reported
>> later. I wasn't seeing it since I was running a UP non-preempt kernel.
>> With lock debugging enabled, I get the same error. This patch should
>> fix it.
>> - spin_lock_irqsave(&ap->host->lock, flags);
>> hsdevp->cmd_issued[tag] = cmd_issued;
>> - spin_unlock_irqrestore(&ap->host->lock, flags);
>> +
> This will create a second empty line, though I don't care it is so minor.
The patch leaves one blank line before the following block comment. I
think it looks better that way.
>>> Still can't get the patch applied .
>> Sorry, didn't realise it conflicted with an intervening patch I had in
>> my tree. Try this one.
>>
>
>
> =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.19 14:44:52 =~=~=~=~=~=~=~=~=~=~=~=
>
> U-Boot 2015.a (May 16 2015 - 14:20:11)
>
> CPU: AMCC PowerPC 460EX Rev. B at 1155 MHz (PLB=231 OPB=115 EBC=115)
>No Security/Kasumi support
>Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
>Internal PCI arbiter enabled
>32 kB I-Cache 32 kB D-Cache
> Board: Sam460ex/cr, PCIe 4x + SATA-2
> I2C: ready
> DRAM: 2 GiB (ECC not enabled, 462 MHz, CL4)
> PCI: Bus Dev VenId DevId Class Int
> 00 04 1095 3512 0104 00
> 00 06 126f 0501 0380 00
> PCIE1: successfully set as root-complex
> 02 00 1002 683f 0300 ff
> Net: ppc_4xx_eth0
> FPGA: Revision 03 (2010-10-07)
> SM502: found
> PERMD2:not found
> VGA: 1
> VESA: OK
> [0.00] Using Canyonlands machine description
> [0.00] Initializing cgroup subsys cpu
> [0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) (gcc
> version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #1 PREEMPT Sat Dec 19 14:25:55 AST
> 2015
> [0.00] Zone ranges:
> [0.00] DMA [mem 0x-0x2fff]
> [0.00] Normal empty
> [0.00] HighMem [mem 0x3000-0x7fff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00] node 0: [mem 0x-0x7fff]
> [0.00] Initmem setup node 0 [mem
> 0x-0x7fff]
> [0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts
> [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
> pages: 522752
> [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200
> console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg
Please add ignore_log_level.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/19/2015 1:19 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/19/2015 1:05 PM, Måns Rullgård wrote:
Andy Shevchenko writes:
On Sat, Dec 19, 2015 at 5:40 PM, Måns Rullgård wrote:
OK, I've found something. The dma setup errors are benign, caused by
the driver calling dmaengine_prep_slave_sg() even for non-dma
operations.
I suppose the following is a quick fix to avoid preparing descriptor
for non-DMA operations (not tested anyhow)
a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -1041,6 +1041,9 @@ static void sata_dwc_qc_prep_by_tag(struct
ata_queued_cmd *qc, u8 tag)
__func__, ap->port_no, get_dma_dir_descript(qc->dma_dir),
qc->n_elem);
+ if (!is_slave_direction(qc->dma_dir))
+ return;
+
desc = dma_dwc_xfer_setup(qc);
if (!desc) {
dev_err(ap->dev, "%s: dma_dwc_xfer_setup returns NULL\n",
I already have a better patch sitting here.
The real error is the lock recursion that's reported
later. I wasn't seeing it since I was running a UP non-preempt kernel.
With lock debugging enabled, I get the same error. This patch should
fix it.
- spin_lock_irqsave(&ap->host->lock, flags);
hsdevp->cmd_issued[tag] = cmd_issued;
- spin_unlock_irqrestore(&ap->host->lock, flags);
+
This will create a second empty line, though I don't care it is so minor.
The patch leaves one blank line before the following block comment. I
think it looks better that way.
Still can't get the patch applied .
Sorry, didn't realise it conflicted with an intervening patch I had in
my tree. Try this one.
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.19 14:44:52 =~=~=~=~=~=~=~=~=~=~=~=
U-Boot 2015.a (May 16 2015 - 14:20:11)
CPU: AMCC PowerPC 460EX Rev. B at 1155 MHz (PLB=231 OPB=115 EBC=115)
No Security/Kasumi support
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
Internal PCI arbiter enabled
32 kB I-Cache 32 kB D-Cache
Board: Sam460ex/cr, PCIe 4x + SATA-2
I2C: ready
DRAM: 2 GiB (ECC not enabled, 462 MHz, CL4)
PCI: Bus Dev VenId DevId Class Int
00 04 1095 3512 0104 00
00 06 126f 0501 0380 00
PCIE1: successfully set as root-complex
02 00 1002 683f 0300 ff
Net: ppc_4xx_eth0
FPGA: Revision 03 (2010-10-07)
SM502: found
PERMD2:not found
VGA: 1
VESA: OK
[0.00] Using Canyonlands machine description
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) (gcc
version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #1 PREEMPT Sat Dec 19 14:25:55 AST 2015
[0.00] Zone ranges:
[0.00] DMA [mem 0x-0x2fff]
[0.00] Normal empty
[0.00] HighMem [mem 0x3000-0x7fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x-0x7fff]
[0.00] Initmem setup node 0 [mem 0x-0x7fff]
[0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 522752
[0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200
console=tty1 dw_dmac_core.dyndbg dw_dmac.dyndbg
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 2068868K/2097152K available (6732K kernel code, 332K
rwdata, 3232K rodata, 236K init, 368K bss, 28284K reserved, 0K cma-reserved,
1310720K highmem)
[0.00] Kernel virtual memory layout:
[0.00] * 0xfffcf000..0xf000 : fixmap
[0.00] * 0xffc0..0xffe0 : highmem PTEs
[0.00] * 0xffa0..0xffc0 : consistent mem
[0.00] * 0xffa0..0xffa0 : early ioremap
[0.00] * 0xf100..0xffa0 : vmalloc & ioremap
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00] Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:512 nr_irqs:512 16
[0.00] UIC0 (32 IRQ sources) at DCR 0xc0
[0.00] UIC1 (32 IRQ sources) at DCR 0xd0
[0.00] UIC2 (32 IRQ sources) at DCR 0xe0
[0.00] UIC3 (32 IRQ sources) at DCR 0xf0
[0.13] clocksource: timebase: mask: 0x max_cycles:
0x10a60dda894, max_idle_ns: 440795207041 ns
[0.23] clocksource: timebase mult[dda520] shift[24] registered
[0.000144] Console: colour dummy device 80x25
[0.000712] console [tty1] enabled
[0.000749] pid_max: default: 32768 minimum: 301
[0.000859] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/19/2015 1:05 PM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>> On Sat, Dec 19, 2015 at 5:40 PM, Måns Rullgård wrote:
>>>
OK, I've found something. The dma setup errors are benign, caused by
the driver calling dmaengine_prep_slave_sg() even for non-dma
operations.
>>> I suppose the following is a quick fix to avoid preparing descriptor
>>> for non-DMA operations (not tested anyhow)
>>>
>>> a/drivers/ata/sata_dwc_460ex.c
>>> +++ b/drivers/ata/sata_dwc_460ex.c
>>> @@ -1041,6 +1041,9 @@ static void sata_dwc_qc_prep_by_tag(struct
>>> ata_queued_cmd *qc, u8 tag)
>>> __func__, ap->port_no, get_dma_dir_descript(qc->dma_dir),
>>> qc->n_elem);
>>>
>>> + if (!is_slave_direction(qc->dma_dir))
>>> + return;
>>> +
>>> desc = dma_dwc_xfer_setup(qc);
>>> if (!desc) {
>>> dev_err(ap->dev, "%s: dma_dwc_xfer_setup returns NULL\n",
>> I already have a better patch sitting here.
>>
The real error is the lock recursion that's reported
later. I wasn't seeing it since I was running a UP non-preempt kernel.
With lock debugging enabled, I get the same error. This patch should
fix it.
- spin_lock_irqsave(&ap->host->lock, flags);
hsdevp->cmd_issued[tag] = cmd_issued;
- spin_unlock_irqrestore(&ap->host->lock, flags);
+
>>> This will create a second empty line, though I don't care it is so minor.
>> The patch leaves one blank line before the following block comment. I
>> think it looks better that way.
>>
>
> Still can't get the patch applied .
Sorry, didn't realise it conflicted with an intervening patch I had in
my tree. Try this one.
--
Måns Rullgård
>From 97c1cdb8a6b933bad2c35b9461c2c15935f2a514 Mon Sep 17 00:00:00 2001
From: Mans Rullgard
Date: Sat, 19 Dec 2015 15:26:23 +
Subject: [PATCH] ata: sata_dwc_460ex: remove incorrect locking
This lock is already taken in ata_scsi_queuecmd() a few levels up the
call stack so attempting to take it here is an error. Moreover, it is
pointless in the first place since it only protects a single, atomic
assignment.
Signed-off-by: Mans Rullgard
---
drivers/ata/sata_dwc_460ex.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index 9985749..19d1c5e 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -995,15 +995,13 @@ static void sata_dwc_exec_command_by_tag(struct ata_port *ap,
struct ata_taskfile *tf,
u8 tag, u32 cmd_issued)
{
- unsigned long flags;
struct sata_dwc_device_port *hsdevp = HSDEVP_FROM_AP(ap);
dev_dbg(ap->dev, "%s cmd(0x%02x): %s tag=%d\n", __func__, tf->command,
ata_get_cmd_descript(tf->command), tag);
- spin_lock_irqsave(&ap->host->lock, flags);
hsdevp->cmd_issued[tag] = cmd_issued;
- spin_unlock_irqrestore(&ap->host->lock, flags);
+
/*
* Clear SError before executing a new command.
* sata_dwc_scr_write and read can not be used here. Clearing the PM
--
2.6.3
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Sat, Dec 19, 2015 at 7:09 PM, Julian Margetson wrote: > Still can't get the patch applied . It might be faster if you just edit (remove 3 lines) directly in the file. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/19/2015 1:05 PM, Måns Rullgård wrote:
Andy Shevchenko writes:
On Sat, Dec 19, 2015 at 5:40 PM, Måns Rullgård wrote:
OK, I've found something. The dma setup errors are benign, caused by
the driver calling dmaengine_prep_slave_sg() even for non-dma
operations.
I suppose the following is a quick fix to avoid preparing descriptor
for non-DMA operations (not tested anyhow)
a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -1041,6 +1041,9 @@ static void sata_dwc_qc_prep_by_tag(struct
ata_queued_cmd *qc, u8 tag)
__func__, ap->port_no, get_dma_dir_descript(qc->dma_dir),
qc->n_elem);
+ if (!is_slave_direction(qc->dma_dir))
+ return;
+
desc = dma_dwc_xfer_setup(qc);
if (!desc) {
dev_err(ap->dev, "%s: dma_dwc_xfer_setup returns NULL\n",
I already have a better patch sitting here.
The real error is the lock recursion that's reported
later. I wasn't seeing it since I was running a UP non-preempt kernel.
With lock debugging enabled, I get the same error. This patch should
fix it.
- spin_lock_irqsave(&ap->host->lock, flags);
hsdevp->cmd_issued[tag] = cmd_issued;
- spin_unlock_irqrestore(&ap->host->lock, flags);
+
This will create a second empty line, though I don't care it is so minor.
The patch leaves one blank line before the following block comment. I
think it looks better that way.
Still can't get the patch applied .
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes:
> On Sat, Dec 19, 2015 at 5:40 PM, Måns Rullgård wrote:
>
>> OK, I've found something. The dma setup errors are benign, caused by
>> the driver calling dmaengine_prep_slave_sg() even for non-dma
>> operations.
>
> I suppose the following is a quick fix to avoid preparing descriptor
> for non-DMA operations (not tested anyhow)
>
> a/drivers/ata/sata_dwc_460ex.c
> +++ b/drivers/ata/sata_dwc_460ex.c
> @@ -1041,6 +1041,9 @@ static void sata_dwc_qc_prep_by_tag(struct
> ata_queued_cmd *qc, u8 tag)
> __func__, ap->port_no, get_dma_dir_descript(qc->dma_dir),
> qc->n_elem);
>
> + if (!is_slave_direction(qc->dma_dir))
> + return;
> +
> desc = dma_dwc_xfer_setup(qc);
> if (!desc) {
> dev_err(ap->dev, "%s: dma_dwc_xfer_setup returns NULL\n",
I already have a better patch sitting here.
>> The real error is the lock recursion that's reported
>> later. I wasn't seeing it since I was running a UP non-preempt kernel.
>> With lock debugging enabled, I get the same error. This patch should
>> fix it.
>
>> - spin_lock_irqsave(&ap->host->lock, flags);
>> hsdevp->cmd_issued[tag] = cmd_issued;
>> - spin_unlock_irqrestore(&ap->host->lock, flags);
>
>> +
>
> This will create a second empty line, though I don't care it is so minor.
The patch leaves one blank line before the following block comment. I
think it looks better that way.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Sat, Dec 19, 2015 at 5:40 PM, Måns Rullgård wrote:
> OK, I've found something. The dma setup errors are benign, caused by
> the driver calling dmaengine_prep_slave_sg() even for non-dma
> operations.
I suppose the following is a quick fix to avoid preparing descriptor
for non-DMA operations (not tested anyhow)
a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -1041,6 +1041,9 @@ static void sata_dwc_qc_prep_by_tag(struct
ata_queued_cmd *qc, u8 tag)
__func__, ap->port_no, get_dma_dir_descript(qc->dma_dir),
qc->n_elem);
+ if (!is_slave_direction(qc->dma_dir))
+ return;
+
desc = dma_dwc_xfer_setup(qc);
if (!desc) {
dev_err(ap->dev, "%s: dma_dwc_xfer_setup returns NULL\n",
> The real error is the lock recursion that's reported
> later. I wasn't seeing it since I was running a UP non-preempt kernel.
> With lock debugging enabled, I get the same error. This patch should
> fix it.
> - spin_lock_irqsave(&ap->host->lock, flags);
> hsdevp->cmd_issued[tag] = cmd_issued;
> - spin_unlock_irqrestore(&ap->host->lock, flags);
> +
This will create a second empty line, though I don't care it is so minor.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/19/2015 11:40 AM, Måns Rullgård wrote:
>> OK, I've found something. The dma setup errors are benign, caused by
>> the driver calling dmaengine_prep_slave_sg() even for non-dma
>> operations. The real error is the lock recursion that's reported
>> later. I wasn't seeing it since I was running a UP non-preempt kernel.
>> With lock debugging enabled, I get the same error. This patch should
>> fix it.
>>
>> ---8<---
>> >From 94c4769d2171ce66079fd486a45e09dd64db62c0 Mon Sep 17 00:00:00 2001
>> From: Mans Rullgard
>> Date: Sat, 19 Dec 2015 15:26:23 +
>> Subject: [PATCH] ata: sata_dwc_460ex: remove incorrect locking
>>
>> This lock is already taken in ata_scsi_queuecmd() a few levels up the
>> call stack so attempting to take it here is an error. Moreover, it is
>> pointless in the first place since it only protects a single, atomic
>> assignment.
>>
>> Signed-off-by: Mans Rullgard
>> ---
>> drivers/ata/sata_dwc_460ex.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
>> index 799df86..5696f39 100644
>> --- a/drivers/ata/sata_dwc_460ex.c
>> +++ b/drivers/ata/sata_dwc_460ex.c
>> @@ -1001,16 +1001,14 @@ static void sata_dwc_exec_command_by_tag(struct
>> ata_port *ap,
>> struct ata_taskfile *tf,
>> u8 tag, u32 cmd_issued)
>> {
>> -unsigned long flags;
>> struct sata_dwc_device_port *hsdevp = HSDEVP_FROM_AP(ap);
>> struct sata_dwc_device *hsdev = HSDEV_FROM_AP(ap);
>> dev_dbg(ap->dev, "%s cmd(0x%02x): %s tag=%d\n", __func__,
>> tf->command,
>> ata_get_cmd_descript(tf->command), tag);
>> - spin_lock_irqsave(&ap->host->lock, flags);
>> hsdevp->cmd_issued[tag] = cmd_issued;
>> -spin_unlock_irqrestore(&ap->host->lock, flags);
>> +
>> /*
>> * Clear SError before executing a new command.
>> * sata_dwc_scr_write and read can not be used here. Clearing the PM
> having a problem applying the patch .
>
> patching file drivers/ata/sata_dwc_460ex.c
> Hunk #1 FAILED at 1001 (different line endings).
OK, attaching it instead.
--
Måns Rullgård
>From 94c4769d2171ce66079fd486a45e09dd64db62c0 Mon Sep 17 00:00:00 2001
From: Mans Rullgard
Date: Sat, 19 Dec 2015 15:26:23 +
Subject: [PATCH] ata: sata_dwc_460ex: remove incorrect locking
This lock is already taken in ata_scsi_queuecmd() a few levels up the
call stack so attempting to take it here is an error. Moreover, it is
pointless in the first place since it only protects a single, atomic
assignment.
Signed-off-by: Mans Rullgard
---
drivers/ata/sata_dwc_460ex.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index 799df86..5696f39 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -1001,16 +1001,14 @@ static void sata_dwc_exec_command_by_tag(struct ata_port *ap,
struct ata_taskfile *tf,
u8 tag, u32 cmd_issued)
{
- unsigned long flags;
struct sata_dwc_device_port *hsdevp = HSDEVP_FROM_AP(ap);
struct sata_dwc_device *hsdev = HSDEV_FROM_AP(ap);
dev_dbg(ap->dev, "%s cmd(0x%02x): %s tag=%d\n", __func__, tf->command,
ata_get_cmd_descript(tf->command), tag);
- spin_lock_irqsave(&ap->host->lock, flags);
hsdevp->cmd_issued[tag] = cmd_issued;
- spin_unlock_irqrestore(&ap->host->lock, flags);
+
/*
* Clear SError before executing a new command.
* sata_dwc_scr_write and read can not be used here. Clearing the PM
--
2.6.3
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > On 12/18/2015 10:34 PM, Andy Shevchenko wrote: >> On Sat, Dec 19, 2015 at 1:16 AM, Måns Rullgård wrote: >>> Julian Margetson writes: >>> On 12/18/2015 6:33 PM, Måns Rullgård wrote: > Julian Margetson writes: > >> On 12/18/2015 1:18 PM, Måns Rullgård wrote: >>> Julian Margetson writes: >>> On 12/18/2015 8:49 AM, Måns Rullgård wrote: > Andy Shevchenko writes: > [5.206125] Unable to handle kernel paging request for data at address 0x [5.228546] Faulting instruction address: 0xc043a2c8 [5.248577] Vector: 300 (Data Access) at [eddafae0] [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204 >>> Well, that's not good. Can you translate that address to a line of >>> code? >> Besides that, can you enable DYNAMIC_DEBUG in the config and append >> 'dw_dmac_core.dyndbg dw_dmac.dyndbg' to the kernel cmdline? > Enabling debug messages in the sata_dwc driver might also be > informative. > Changed the sata-dwc to a module . [ 18.475140] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL [ 18.535698] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL >>> That's strange. The only way that can happen is if >>> dmaengine_prep_slave_sg() return NULL, and that really shouldn't be >>> happening. Did you turn on debug messages in dw_dma? You can enable >>> some extra debug messages by adding "#define VERBOSE_DEBUG" at the top >>> of drivers/dma/dw/core.c >>> >> [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL >> [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL >> [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL > Could you post the entire kernel log? There might be important > information before the errors start. > =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.18 15:01:48 =~=~=~=~=~=~=~=~=~=~=~= [0.00] Using Canyonlands machine description [0.00] Initializing cgroup subsys cpu [0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) (gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #8 PREEMPT Fri Dec 18 13:36:34 AST 2015 [0.00] Zone ranges: [0.00] DMA [mem 0x-0x2fff] [0.00] Normal empty [0.00] HighMem [mem 0x3000-0x7fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x7fff] [0.00] Initmem setup node 0 [mem 0x-0x7fff] [0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522752 [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 console=tty0 dw_dmac_core.dyndbg dw_dmac.dyndbg >> I would suggest to use console=tty1 instead of console=tty0. >> >>> [...] >>> [ 13.643415] systemd[1]: Mounted Configuration File System. [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL >>> This log is weird. The sata_dwc_probe() function prints several things >>> (one using dev_notice()), for instance this: >>> >>> /* Read the ID and Version Registers */ >>> idr = in_le32(&hsdev->sata_dwc_regs->idr); >>> versionr = in_le32(&hsdev->sata_dwc_regs->versionr); >>> dev_notice(&ofdev->dev, "id %d, controller version %c.%c%c\n", >>> idr, ver[0], ver[1], ver[2]); >>> >>> The dw_dma_probe() function also prints a line: >>> >>> dev_info(chip->dev, "DesignWare DMA Controller, %d channels\n", >>> pdata->nr_channels); >>> >>> These messages are nowhere to be seen in your log, nor are numerous >>> others that really must appear before before sata_dwc_qc_prep_by_tag() >>> can be called. >>> >> It would be better to add 'ignore_loglevel' to the cmdline as well. OK, I've found something. The dma setup errors are benign, caused by the driver calling dmaengine_prep_slave_sg() even for non-dma operations. The real error is the lock recursion that's reported later. I wasn't seeing it since I was running a UP non-preempt kernel. With lock debugging enabl
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Sat, Dec 19, 2015 at 1:16 AM, Måns Rullgård wrote: > Julian Margetson writes: > >> On 12/18/2015 6:33 PM, Måns Rullgård wrote: >>> Julian Margetson writes: >>> On 12/18/2015 1:18 PM, Måns Rullgård wrote: > Julian Margetson writes: > >> On 12/18/2015 8:49 AM, Måns Rullgård wrote: >>> Andy Shevchenko writes: >>> >> [5.206125] Unable to handle kernel paging request for data at >> address 0x >> [5.228546] Faulting instruction address: 0xc043a2c8 >> [5.248577] Vector: 300 (Data Access) at [eddafae0] >> [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204 > Well, that's not good. Can you translate that address to a line of > code? Besides that, can you enable DYNAMIC_DEBUG in the config and append 'dw_dmac_core.dyndbg dw_dmac.dyndbg' to the kernel cmdline? >>> Enabling debug messages in the sata_dwc driver might also be >>> informative. >>> >> Changed the sata-dwc to a module . >> >> [ 18.475140] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL >> [ 18.535698] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL > That's strange. The only way that can happen is if > dmaengine_prep_slave_sg() return NULL, and that really shouldn't be > happening. Did you turn on debug messages in dw_dma? You can enable > some extra debug messages by adding "#define VERBOSE_DEBUG" at the top > of drivers/dma/dw/core.c > [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL >>> Could you post the entire kernel log? There might be important >>> information before the errors start. >>> >> >> >> =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.18 15:01:48 =~=~=~=~=~=~=~=~=~=~=~= >> [0.00] Using Canyonlands machine description >> [0.00] Initializing cgroup subsys cpu >> [0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) >> (gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #8 PREEMPT Fri Dec 18 13:36:34 >> AST 2015 >> [0.00] Zone ranges: >> [0.00] DMA [mem 0x-0x2fff] >> [0.00] Normal empty >> [0.00] HighMem [mem 0x3000-0x7fff] >> [0.00] Movable zone start for each node >> [0.00] Early memory node ranges >> [0.00] node 0: [mem 0x-0x7fff] >> [0.00] Initmem setup node 0 [mem >> 0x-0x7fff] >> [0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts >> [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total >> pages: 522752 >> [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 >> console=tty0 dw_dmac_core.dyndbg dw_dmac.dyndbg I would suggest to use console=tty1 instead of console=tty0. > > [...] > >> [ 13.643415] systemd[1]: Mounted Configuration File System. >> [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL >> [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL >> [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL > > This log is weird. The sata_dwc_probe() function prints several things > (one using dev_notice()), for instance this: > > /* Read the ID and Version Registers */ > idr = in_le32(&hsdev->sata_dwc_regs->idr); > versionr = in_le32(&hsdev->sata_dwc_regs->versionr); > dev_notice(&ofdev->dev, "id %d, controller version %c.%c%c\n", >idr, ver[0], ver[1], ver[2]); > > The dw_dma_probe() function also prints a line: > > dev_info(chip->dev, "DesignWare DMA Controller, %d channels\n", > pdata->nr_channels); > > These messages are nowhere to be seen in your log, nor are numerous > others that really must appear before before sata_dwc_qc_prep_by_tag() > can be called. > It would be better to add 'ignore_loglevel' to the cmdline as well. > I'd like to note that the driver works on my Sigma Designs based system > using a different DMA controller, so it's not completely broken. The > DMA driver could still be faulty, but that still doesn't explain the > missing kernel messages. > > -- > Måns Rullgård > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- With Best Regards, Andy Shevchenko -- To
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > On 12/18/2015 6:33 PM, Måns Rullgård wrote: >> Julian Margetson writes: >> >>> On 12/18/2015 1:18 PM, Måns Rullgård wrote: Julian Margetson writes: > On 12/18/2015 8:49 AM, Måns Rullgård wrote: >> Andy Shevchenko writes: >> > [5.206125] Unable to handle kernel paging request for data at > address 0x > [5.228546] Faulting instruction address: 0xc043a2c8 > [5.248577] Vector: 300 (Data Access) at [eddafae0] > [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204 Well, that's not good. Can you translate that address to a line of code? >>> Besides that, can you enable DYNAMIC_DEBUG in the config and append >>> 'dw_dmac_core.dyndbg dw_dmac.dyndbg' to the kernel cmdline? >> Enabling debug messages in the sata_dwc driver might also be informative. >> > Changed the sata-dwc to a module . > > [ 18.475140] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL > [ 18.535698] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL That's strange. The only way that can happen is if dmaengine_prep_slave_sg() return NULL, and that really shouldn't be happening. Did you turn on debug messages in dw_dma? You can enable some extra debug messages by adding "#define VERBOSE_DEBUG" at the top of drivers/dma/dw/core.c >>> [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >>> dma_dwc_xfer_setup returns NULL >>> [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >>> dma_dwc_xfer_setup returns NULL >>> [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >>> dma_dwc_xfer_setup returns NULL >> Could you post the entire kernel log? There might be important >> information before the errors start. >> > > > =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.18 15:01:48 =~=~=~=~=~=~=~=~=~=~=~= > [0.00] Using Canyonlands machine description > [0.00] Initializing cgroup subsys cpu > [0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) (gcc > version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #8 PREEMPT Fri Dec 18 13:36:34 AST > 2015 > [0.00] Zone ranges: > [0.00] DMA [mem 0x-0x2fff] > [0.00] Normal empty > [0.00] HighMem [mem 0x3000-0x7fff] > [0.00] Movable zone start for each node > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x-0x7fff] > [0.00] Initmem setup node 0 [mem > 0x-0x7fff] > [0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts > [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total > pages: 522752 > [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 > console=tty0 dw_dmac_core.dyndbg dw_dmac.dyndbg [...] > [ 13.643415] systemd[1]: Mounted Configuration File System. > [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL > [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL > [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL This log is weird. The sata_dwc_probe() function prints several things (one using dev_notice()), for instance this: /* Read the ID and Version Registers */ idr = in_le32(&hsdev->sata_dwc_regs->idr); versionr = in_le32(&hsdev->sata_dwc_regs->versionr); dev_notice(&ofdev->dev, "id %d, controller version %c.%c%c\n", idr, ver[0], ver[1], ver[2]); The dw_dma_probe() function also prints a line: dev_info(chip->dev, "DesignWare DMA Controller, %d channels\n", pdata->nr_channels); These messages are nowhere to be seen in your log, nor are numerous others that really must appear before before sata_dwc_qc_prep_by_tag() can be called. I'd like to note that the driver works on my Sigma Designs based system using a different DMA controller, so it's not completely broken. The DMA driver could still be faulty, but that still doesn't explain the missing kernel messages. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > On 12/18/2015 1:18 PM, Måns Rullgård wrote: >> Julian Margetson writes: >> >>> On 12/18/2015 8:49 AM, Måns Rullgård wrote: Andy Shevchenko writes: >>> [5.206125] Unable to handle kernel paging request for data at >>> address 0x >>> [5.228546] Faulting instruction address: 0xc043a2c8 >>> [5.248577] Vector: 300 (Data Access) at [eddafae0] >>> [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204 >> Well, that's not good. Can you translate that address to a line of >> code? > Besides that, can you enable DYNAMIC_DEBUG in the config and append > 'dw_dmac_core.dyndbg dw_dmac.dyndbg' to the kernel cmdline? Enabling debug messages in the sata_dwc driver might also be informative. >>> Changed the sata-dwc to a module . >>> >>> [ 18.475140] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >>> dma_dwc_xfer_setup returns NULL >>> [ 18.535698] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >>> dma_dwc_xfer_setup returns NULL >> That's strange. The only way that can happen is if >> dmaengine_prep_slave_sg() return NULL, and that really shouldn't be >> happening. Did you turn on debug messages in dw_dma? You can enable >> some extra debug messages by adding "#define VERBOSE_DEBUG" at the top >> of drivers/dma/dw/core.c >> > > [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL > [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL > [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL Could you post the entire kernel log? There might be important information before the errors start. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Fri, 2015-12-18 at 17:18 +, Måns Rullgård wrote: > Julian Margetson writes: > > > On 12/18/2015 8:49 AM, Måns Rullgård wrote: > > > Andy Shevchenko writes: > > > > > > > > > [5.206125] Unable to handle kernel paging request for > > > > > > data at > > > > > > address 0x > > > > > > [5.228546] Faulting instruction address: 0xc043a2c8 > > > > > > [5.248577] Vector: 300 (Data Access) at [eddafae0] > > > > > > [5.268658] pc: c043a2c8: > > > > > > sata_dwc_qc_issue+0xb8/0x204 > > > > > Well, that's not good. Can you translate that address to a > > > > > line of > > > > > code? > > > > Besides that, can you enable DYNAMIC_DEBUG in the config and > > > > append > > > > 'dw_dmac_core.dyndbg dw_dmac.dyndbg' to the kernel cmdline? > > > Enabling debug messages in the sata_dwc driver might also be > > > informative. > > > > > Changed the sata-dwc to a module . > > > > [ 18.475140] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > > dma_dwc_xfer_setup returns NULL > > [ 18.535698] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > > dma_dwc_xfer_setup returns NULL > > That's strange. The only way that can happen is if > dmaengine_prep_slave_sg() return NULL, and that really shouldn't be > happening. Did you turn on debug messages in dw_dma? You can enable > some extra debug messages by adding "#define VERBOSE_DEBUG" at the > top > of drivers/dma/dw/core.c There are options also for DMA Engine such as CONFIG_DMADEVICES_DEBUG > -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > On 12/18/2015 8:49 AM, Måns Rullgård wrote: >> Andy Shevchenko writes: >> > [5.206125] Unable to handle kernel paging request for data at > address 0x > [5.228546] Faulting instruction address: 0xc043a2c8 > [5.248577] Vector: 300 (Data Access) at [eddafae0] > [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204 Well, that's not good. Can you translate that address to a line of code? >>> Besides that, can you enable DYNAMIC_DEBUG in the config and append >>> 'dw_dmac_core.dyndbg dw_dmac.dyndbg' to the kernel cmdline? >> Enabling debug messages in the sata_dwc driver might also be informative. >> > Changed the sata-dwc to a module . > > [ 18.475140] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL > [ 18.535698] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL That's strange. The only way that can happen is if dmaengine_prep_slave_sg() return NULL, and that really shouldn't be happening. Did you turn on debug messages in dw_dma? You can enable some extra debug messages by adding "#define VERBOSE_DEBUG" at the top of drivers/dma/dw/core.c -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > On 12/18/2015 8:45 AM, Måns Rullgård wrote: >> Julian Margetson writes: >> > Builds now. Using my own .config. What changed? >>> I may have messed up the patch initially . >> Probably. Let's pretend it never happened. >> > [4.784199] sata-dwc 4bffd1000.sata: id 0, controller version 1.82 > [4.791186] scsi host0: sata-dwc > [4.794830] ata1: SATA max UDMA/133 irq 36 > [4.799463] sata_sil 0001:00:04.0: Applying R_ERR on DMA activate FIS > errata fix > [4.807959] scsi host1: sata_sil > [4.811662] scsi host2: sata_sil > [4.815242] ata2: SATA max UDMA/100 mmio m512@0xd8428 tf > 0xd84280080 irq 21 > [4.822990] ata3: SATA max UDMA/100 mmio m512@0xd8428 tf > 0xd842800c0 irq 21 > > [5.143502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [5.164367] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > [5.185174] ppc-of-ohci 4bffd.usb: irq 32, io mem 0x4bffd > [5.206125] Unable to handle kernel paging request for data at address > 0x > [5.228546] Faulting instruction address: 0xc043a2c8 > [5.248577] Vector: 300 (Data Access) at [eddafae0] > [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204 Well, that's not good. Can you translate that address to a line of code? >>> need some guidance on method . >> Enable CONFIG_DEBUG_INFO, then use this command: >> >> $ addr2line -e vmlinux 0xc043a2c8 >> >> Obviously substitute the actual crashing address if it changes. >> > addr2line -e vmlinux 0xc044b41c > arch/powerpc/lib/copy_32.S:? There's obviously a mismatch somewhere since we know that sata_dwc_qc_issue isn't in copy_32.S. Please post the full crash report you got this address from. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Fri, 2015-12-18 at 09:52 -0400, Julian Margetson wrote:
> On 12/18/2015 8:45 AM, Måns Rullgård wrote:
> > Julian Margetson writes:
> > > > > [4.784199] sata-dwc 4bffd1000.sata: id 0, controller
> > > > > version 1.82
> > > > > [4.791186] scsi host0: sata-dwc
> > > > > [4.794830] ata1: SATA max UDMA/133 irq 36
> > > > > [4.799463] sata_sil 0001:00:04.0: Applying R_ERR on DMA
> > > > > activate FIS errata fix
> > > > > [4.807959] scsi host1: sata_sil
> > > > > [4.811662] scsi host2: sata_sil
> > > > > [4.815242] ata2: SATA max UDMA/100 mmio m512@0xd8428
> > > > > tf 0xd84280080 irq 21
> > > > > [4.822990] ata3: SATA max UDMA/100 mmio m512@0xd8428
> > > > > tf 0xd842800c0 irq 21
> > > > >
> > > > > [5.143502] ata1: SATA link up 3.0 Gbps (SStatus 123
> > > > > SControl 300)
> > > > > [5.164367] ata2: SATA link up 1.5 Gbps (SStatus 113
> > > > > SControl 310)
> > > > > [5.185174] ppc-of-ohci 4bffd.usb: irq 32, io mem
> > > > > 0x4bffd
> > > > > [5.206125] Unable to handle kernel paging request for
> > > > > data at address 0x
> > > > > [5.228546] Faulting instruction address: 0xc043a2c8
> > > > > [5.248577] Vector: 300 (Data Access) at [eddafae0]
> > > > > [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204
> > > > Well, that's not good. Can you translate that address to a
> > > > line of code?
> > > >
> > > need some guidance on method .
> > Enable CONFIG_DEBUG_INFO, then use this command:
> >
> > $ addr2line -e vmlinux 0xc043a2c8
> >
> > Obviously substitute the actual crashing address if it changes.
> >
> addr2line -e vmlinux 0xc044b41c
> arch/powerpc/lib/copy_32.S:?
memcpy I suppose. Might be copy to unmapped memory.
Anyway, can you enable debug options as I suggested including debug for
sata driver ('dw_dmac_core.dyndbg dw_dmac.dyndbg sata_dwc_460ex.dydbg'
to the cmdline and CONFIG_DYNAMIC_DEBUG=y)?
--
Andy Shevchenko
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes: >> > [5.206125] Unable to handle kernel paging request for data at >> > address 0x >> > [5.228546] Faulting instruction address: 0xc043a2c8 >> > [5.248577] Vector: 300 (Data Access) at [eddafae0] >> > [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204 >> >> Well, that's not good. Can you translate that address to a line of >> code? > > Besides that, can you enable DYNAMIC_DEBUG in the config and append > 'dw_dmac_core.dyndbg dw_dmac.dyndbg' to the kernel cmdline? Enabling debug messages in the sata_dwc driver might also be informative. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: >>> Builds now. Using my own .config. >> What changed? > I may have messed up the patch initially . Probably. Let's pretend it never happened. >>> [4.784199] sata-dwc 4bffd1000.sata: id 0, controller version 1.82 >>> [4.791186] scsi host0: sata-dwc >>> [4.794830] ata1: SATA max UDMA/133 irq 36 >>> [4.799463] sata_sil 0001:00:04.0: Applying R_ERR on DMA activate FIS >>> errata fix >>> [4.807959] scsi host1: sata_sil >>> [4.811662] scsi host2: sata_sil >>> [4.815242] ata2: SATA max UDMA/100 mmio m512@0xd8428 tf 0xd84280080 >>> irq 21 >>> [4.822990] ata3: SATA max UDMA/100 mmio m512@0xd8428 tf 0xd842800c0 >>> irq 21 >>> >>> [5.143502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >>> [5.164367] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) >>> [5.185174] ppc-of-ohci 4bffd.usb: irq 32, io mem 0x4bffd >>> [5.206125] Unable to handle kernel paging request for data at address >>> 0x >>> [5.228546] Faulting instruction address: 0xc043a2c8 >>> [5.248577] Vector: 300 (Data Access) at [eddafae0] >>> [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204 >> Well, that's not good. Can you translate that address to a line of code? >> > need some guidance on method . Enable CONFIG_DEBUG_INFO, then use this command: $ addr2line -e vmlinux 0xc043a2c8 Obviously substitute the actual crashing address if it changes. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Fri, 2015-12-18 at 08:33 -0400, Julian Margetson wrote:
> On 12/18/2015 8:04 AM, Måns Rullgård wrote:
> > Julian Margetson writes:
> >
> > > On 12/17/2015 8:06 PM, Måns Rullgård wrote:
> > > > Julian Margetson writes:
> > > >
> > > > > On 12/17/2015 3:53 PM, Måns Rullgård wrote:
> > > > > > Julian Margetson writes:
> > > > > >
> > > > > > > On 12/17/2015 2:51 PM, Måns Rullgård wrote:
> > > > > > > > Julian Margetson writes:
> > > > > > > >
> > > > > > > > > On 12/17/2015 1:59 PM, Måns Rullgård wrote:
> > > > > > > > > > Julian Margetson writes:
> > > > > > > > > >
> > > > > > > > > > > I have been running my machine mostly configured
> > > > > > > > > > > for pciex1 thus with
> > > > > > > > > > > the sata_dwc disabled.
> > > > > > > > > > > The changes to sata_dwc-460ex do cause an oops.
> > > > > > > > > > > I will try to give more detailed info over this
> > > > > > > > > > > weekend .
> > > > > > > > > > The driver as is upstream would do that since it
> > > > > > > > > > unconditionally
> > > > > > > > > > dereferences a null pointer in the probe
> > > > > > > > > > function. My patch fixes that
> > > > > > > > > > as a side-effect.
> > > > > > > > > >
> > > > > > > > > patching file drivers/ata/Kconfig
> > > > > > > > >
> > > > > > > > > Hunk #1 FAILED at 296.
> > > > > > > > [...]
> > > > > > > >
> > > > > > > > > root@julian-VirtualBox:/usr/src/linux-3.18.25#
> > > > > > > > The patch is against 4.4-rc5.
> > > > > > > >
> > > > > > > CC drivers/ata/sata_dwc_460ex.o
> > > > > > >
> > > > > > > drivers/ata/sata_dwc_460ex.c:198:15: error: variable
> > > > > > > ‘sata_dwc_dma_dws’ has initializer but incomplete
> > > > > > > type
> > > > > > >
> > > > > > > static struct dw_dma_slave sata_dwc_dma_dws = {
> > > > > > > ^
> > > > > > It builds, albeit with an unrelated warning, using the
> > > > > > attached config.
> > > > > > Maybe there's a missing config dependency somewhere.
> > > > > >
> > > > > I am attempting to cross compile under Ubuntu 14.04 X86 in
> > > > > Virtualbox
> > > > > with your .config.
> > > > > 4.4.0-rc5 builds ok with no patches applied .
> > > > > Once your patch is applied it fails to build .
> > > > >
> > > > > CC drivers/ata/sata_dwc_460ex.o
> > > > > drivers/ata/sata_dwc_460ex.c:198:15: error: variable
> > > > > ‘sata_dwc_dma_dws’ has initializer but incomplete type
> > > > > static struct dw_dma_slave sata_dwc_dma_dws = {
> > > > > ^
> > > > Bizarre. This is what it looks like here:
> > > >
> > > > mru@unicorn:/tmp/linux-sata$ git status
> > > > On branch sata-dwc
> > > > nothing to commit, working directory clean
> > > > mru@unicorn:/tmp/linux-sata$ git describe
> > > > v4.4-rc5
> > > > mru@unicorn:/tmp/linux-sata$ sha1sum /tmp/0001-ata-
> > > > sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
> > > > e300971aa483390f82de2e9120dc16e460e74feb /tmp/0001-ata-
> > > > sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
> > > > mru@unicorn:/tmp/linux-sata$ git am /tmp/0001-ata-
> > > > sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
> > > > Applying: ata: sata_dwc_460ex: use "dmas" DT property to find
> > > > dma channel
> > > > mru@unicorn:/tmp/linux-sata$ sha1sum .config
> > > > 4e7615b8d2fa9a1c4b4ae9ffc363aefcaf3789ca .config
> > > > mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
> > > > CROSS_COMPILE=powerpc64-none-linux-gnu- oldconfig
> > > > HOSTCC scripts/basic/fixdep
> > > > HOSTCC scripts/kconfig/conf.o
> > > > SHIPPED scripts/kconfig/zconf.tab.c
> > > > SHIPPED scripts/kconfig/zconf.lex.c
> > > > SHIPPED scripts/kconfig/zconf.hash.c
> > > > HOSTCC scripts/kconfig/zconf.tab.o
> > > > HOSTLD scripts/kconfig/conf
> > > > scripts/kconfig/conf --oldconfig Kconfig
> > > > #
> > > > # configuration written to .config
> > > > #
> > > > mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
> > > > CROSS_COMPILE=powerpc64-none-linux-gnu-
> > > > drivers/ata/sata_dwc_460ex.o
> > > > scripts/kconfig/conf --silentoldconfig Kconfig
> > > > CHK include/config/kernel.release
> > > > UPD include/config/kernel.release
> > > > WRAParch/powerpc/include/generated/asm/clkdev.h
> > > > WRAParch/powerpc/include/generated/asm/div64.h
> > > > WRAParch/powerpc/include/generated/asm/irq_regs.h
> > > > WRAParch/powerpc/include/generated/asm/irq_work.h
> > > > WRAParch/powerpc/include/generated/asm/local64.h
> > > > WRAParch/powerpc/include/generated/asm/mcs_spinlock.h
> > > > WRAParch/powerpc/include/generated/asm/preempt.h
> > > > WRAParch/powerpc/include/generated/asm/rwsem.h
> > > > WRAParch/powerpc/include/generated/asm/vtime.h
> > > > CHK include/generated/uapi/linux/version.h
> > > > UPD include/generated/uapi/linux/version.h
> > > > CHK include/generated/utsrelease.h
> > > > UPD include/generated/utsrelease.h
> > > > CC kernel/bounds.s
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/18/2015 8:04 AM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/17/2015 8:06 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/17/2015 3:53 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/17/2015 2:51 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/17/2015 1:59 PM, Måns Rullgård wrote:
Julian Margetson writes:
I have been running my machine mostly configured for pciex1 thus with
the sata_dwc disabled.
The changes to sata_dwc-460ex do cause an oops.
I will try to give more detailed info over this weekend .
The driver as is upstream would do that since it unconditionally
dereferences a null pointer in the probe function. My patch fixes that
as a side-effect.
patching file drivers/ata/Kconfig
Hunk #1 FAILED at 296.
[...]
root@julian-VirtualBox:/usr/src/linux-3.18.25#
The patch is against 4.4-rc5.
CC drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’ has
initializer but incomplete type
static struct dw_dma_slave sata_dwc_dma_dws = {
^
It builds, albeit with an unrelated warning, using the attached config.
Maybe there's a missing config dependency somewhere.
I am attempting to cross compile under Ubuntu 14.04 X86 in Virtualbox
with your .config.
4.4.0-rc5 builds ok with no patches applied .
Once your patch is applied it fails to build .
CC drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’ has
initializer but incomplete type
static struct dw_dma_slave sata_dwc_dma_dws = {
^
Bizarre. This is what it looks like here:
mru@unicorn:/tmp/linux-sata$ git status
On branch sata-dwc
nothing to commit, working directory clean
mru@unicorn:/tmp/linux-sata$ git describe
v4.4-rc5
mru@unicorn:/tmp/linux-sata$ sha1sum
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
e300971aa483390f82de2e9120dc16e460e74feb
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
mru@unicorn:/tmp/linux-sata$ git am
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
Applying: ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
mru@unicorn:/tmp/linux-sata$ sha1sum .config
4e7615b8d2fa9a1c4b4ae9ffc363aefcaf3789ca .config
mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
CROSS_COMPILE=powerpc64-none-linux-gnu- oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
#
# configuration written to .config
#
mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
CROSS_COMPILE=powerpc64-none-linux-gnu- drivers/ata/sata_dwc_460ex.o
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config/kernel.release
UPD include/config/kernel.release
WRAParch/powerpc/include/generated/asm/clkdev.h
WRAParch/powerpc/include/generated/asm/div64.h
WRAParch/powerpc/include/generated/asm/irq_regs.h
WRAParch/powerpc/include/generated/asm/irq_work.h
WRAParch/powerpc/include/generated/asm/local64.h
WRAParch/powerpc/include/generated/asm/mcs_spinlock.h
WRAParch/powerpc/include/generated/asm/preempt.h
WRAParch/powerpc/include/generated/asm/rwsem.h
WRAParch/powerpc/include/generated/asm/vtime.h
CHK include/generated/uapi/linux/version.h
UPD include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
CC kernel/bounds.s
CHK include/generated/bounds.h
UPD include/generated/bounds.h
CHK include/generated/timeconst.h
UPD include/generated/timeconst.h
CC arch/powerpc/kernel/asm-offsets.s
CHK include/generated/asm-offsets.h
UPD include/generated/asm-offsets.h
CALLscripts/checksyscalls.sh
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
SHIPPED scripts/dtc/dtc-lexer.lex.c
SHIPPED scripts/dtc/dtc-parser.tab.h
HOSTCC scripts/dtc/dtc-lexer.lex.o
SHIPPED scripts/dtc/dtc-parser.tab.c
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTLD scripts/dtc/dtc
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/modpost.o
CC scripts/mod/devicetable-offsets.s
GEN scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/kallsyms
CC drivers/ata/sata_dwc_4
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Fri, 2015-12-18 at 12:04 +, Måns Rullgård wrote:
> Julian Margetson writes:
>
> > On 12/17/2015 8:06 PM, Måns Rullgård wrote:
> > > Julian Margetson writes:
> > >
> > > > On 12/17/2015 3:53 PM, Måns Rullgård wrote:
> > > > > Julian Margetson writes:
> > > > >
> > > > > > On 12/17/2015 2:51 PM, Måns Rullgård wrote:
> > > > > > > Julian Margetson writes:
> > > > > > >
> > > > > > > > On 12/17/2015 1:59 PM, Måns Rullgård wrote:
> > > > > > > > > Julian Margetson writes:
> > > > > > > > >
> > > > > > > > > > I have been running my machine mostly configured
> > > > > > > > > > for pciex1 thus with
> > > > > > > > > > the sata_dwc disabled.
> > > > > > > > > > The changes to sata_dwc-460ex do cause an oops.
> > > > > > > > > > I will try to give more detailed info over this
> > > > > > > > > > weekend .
> > > > > > > > > The driver as is upstream would do that since it
> > > > > > > > > unconditionally
> > > > > > > > > dereferences a null pointer in the probe
> > > > > > > > > function. My patch fixes that
> > > > > > > > > as a side-effect.
> > > > > > > > >
> > > > > > > > patching file drivers/ata/Kconfig
> > > > > > > >
> > > > > > > > Hunk #1 FAILED at 296.
> > > > > > > [...]
> > > > > > >
> > > > > > > > root@julian-VirtualBox:/usr/src/linux-3.18.25#
> > > > > > > The patch is against 4.4-rc5.
> > > > > > >
> > > > > > CC drivers/ata/sata_dwc_460ex.o
> > > > > >
> > > > > > drivers/ata/sata_dwc_460ex.c:198:15: error: variable
> > > > > > ‘sata_dwc_dma_dws’ has initializer but incomplete type
> > > > > >
> > > > > > static struct dw_dma_slave sata_dwc_dma_dws = {
> > > > > > ^
> > > > > It builds, albeit with an unrelated warning, using the
> > > > > attached config.
> > > > > Maybe there's a missing config dependency somewhere.
> > > > >
> > > > I am attempting to cross compile under Ubuntu 14.04 X86 in
> > > > Virtualbox
> > > > with your .config.
> > > > 4.4.0-rc5 builds ok with no patches applied .
> > > > Once your patch is applied it fails to build .
> > > >
> > > > CC drivers/ata/sata_dwc_460ex.o
> > > > drivers/ata/sata_dwc_460ex.c:198:15: error: variable
> > > > ‘sata_dwc_dma_dws’ has initializer but incomplete type
> > > > static struct dw_dma_slave sata_dwc_dma_dws = {
> > > > ^
> > > Bizarre. This is what it looks like here:
> > >
> > > mru@unicorn:/tmp/linux-sata$ git status
> > > On branch sata-dwc
> > > nothing to commit, working directory clean
> > > mru@unicorn:/tmp/linux-sata$ git describe
> > > v4.4-rc5
> > > mru@unicorn:/tmp/linux-sata$ sha1sum /tmp/0001-ata-
> > > sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
> > > e300971aa483390f82de2e9120dc16e460e74feb /tmp/0001-ata-
> > > sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
> > > mru@unicorn:/tmp/linux-sata$ git am /tmp/0001-ata-sata_dwc_460ex-
> > > use-dmas-DT-property-to-find-dma-.patch
> > > Applying: ata: sata_dwc_460ex: use "dmas" DT property to find dma
> > > channel
> > > mru@unicorn:/tmp/linux-sata$ sha1sum .config
> > > 4e7615b8d2fa9a1c4b4ae9ffc363aefcaf3789ca .config
> > > mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
> > > CROSS_COMPILE=powerpc64-none-linux-gnu- oldconfig
> > > HOSTCC scripts/basic/fixdep
> > > HOSTCC scripts/kconfig/conf.o
> > > SHIPPED scripts/kconfig/zconf.tab.c
> > > SHIPPED scripts/kconfig/zconf.lex.c
> > > SHIPPED scripts/kconfig/zconf.hash.c
> > > HOSTCC scripts/kconfig/zconf.tab.o
> > > HOSTLD scripts/kconfig/conf
> > > scripts/kconfig/conf --oldconfig Kconfig
> > > #
> > > # configuration written to .config
> > > #
> > > mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
> > > CROSS_COMPILE=powerpc64-none-linux-gnu-
> > > drivers/ata/sata_dwc_460ex.o
> > > scripts/kconfig/conf --silentoldconfig Kconfig
> > > CHK include/config/kernel.release
> > > UPD include/config/kernel.release
> > > WRAParch/powerpc/include/generated/asm/clkdev.h
> > > WRAParch/powerpc/include/generated/asm/div64.h
> > > WRAParch/powerpc/include/generated/asm/irq_regs.h
> > > WRAParch/powerpc/include/generated/asm/irq_work.h
> > > WRAParch/powerpc/include/generated/asm/local64.h
> > > WRAParch/powerpc/include/generated/asm/mcs_spinlock.h
> > > WRAParch/powerpc/include/generated/asm/preempt.h
> > > WRAParch/powerpc/include/generated/asm/rwsem.h
> > > WRAParch/powerpc/include/generated/asm/vtime.h
> > > CHK include/generated/uapi/linux/version.h
> > > UPD include/generated/uapi/linux/version.h
> > > CHK include/generated/utsrelease.h
> > > UPD include/generated/utsrelease.h
> > > CC kernel/bounds.s
> > > CHK include/generated/bounds.h
> > > UPD include/generated/bounds.h
> > > CHK include/generated/timeconst.h
> > > UPD include/generated/timeconst.h
> > > CC arch/powerpc/kernel/asm-offsets.s
> > > CHK include/generated/asm-offsets.h
> > > UPD inc
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/17/2015 8:06 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 3:53 PM, Måns Rullgård wrote:
Julian Margetson writes:
> On 12/17/2015 2:51 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 1:59 PM, Måns Rullgård wrote:
Julian Margetson writes:
> I have been running my machine mostly configured for pciex1 thus with
> the sata_dwc disabled.
> The changes to sata_dwc-460ex do cause an oops.
> I will try to give more detailed info over this weekend .
The driver as is upstream would do that since it unconditionally
dereferences a null pointer in the probe function. My patch fixes that
as a side-effect.
>>> patching file drivers/ata/Kconfig
>>>
>>> Hunk #1 FAILED at 296.
>> [...]
>>
>>> root@julian-VirtualBox:/usr/src/linux-3.18.25#
>> The patch is against 4.4-rc5.
>>
>CC drivers/ata/sata_dwc_460ex.o
>
> drivers/ata/sata_dwc_460ex.c:198:15: error: variable
> ‘sata_dwc_dma_dws’ has initializer but incomplete type
>
>static struct dw_dma_slave sata_dwc_dma_dws = {
> ^
It builds, albeit with an unrelated warning, using the attached config.
Maybe there's a missing config dependency somewhere.
>>> I am attempting to cross compile under Ubuntu 14.04 X86 in Virtualbox
>>> with your .config.
>>> 4.4.0-rc5 builds ok with no patches applied .
>>> Once your patch is applied it fails to build .
>>>
>>> CC drivers/ata/sata_dwc_460ex.o
>>> drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’ has
>>> initializer but incomplete type
>>> static struct dw_dma_slave sata_dwc_dma_dws = {
>>> ^
>> Bizarre. This is what it looks like here:
>>
>> mru@unicorn:/tmp/linux-sata$ git status
>> On branch sata-dwc
>> nothing to commit, working directory clean
>> mru@unicorn:/tmp/linux-sata$ git describe
>> v4.4-rc5
>> mru@unicorn:/tmp/linux-sata$ sha1sum
>> /tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
>> e300971aa483390f82de2e9120dc16e460e74feb
>> /tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
>> mru@unicorn:/tmp/linux-sata$ git am
>> /tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
>> Applying: ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
>> mru@unicorn:/tmp/linux-sata$ sha1sum .config
>> 4e7615b8d2fa9a1c4b4ae9ffc363aefcaf3789ca .config
>> mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
>> CROSS_COMPILE=powerpc64-none-linux-gnu- oldconfig
>>HOSTCC scripts/basic/fixdep
>>HOSTCC scripts/kconfig/conf.o
>>SHIPPED scripts/kconfig/zconf.tab.c
>>SHIPPED scripts/kconfig/zconf.lex.c
>>SHIPPED scripts/kconfig/zconf.hash.c
>>HOSTCC scripts/kconfig/zconf.tab.o
>>HOSTLD scripts/kconfig/conf
>> scripts/kconfig/conf --oldconfig Kconfig
>> #
>> # configuration written to .config
>> #
>> mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
>> CROSS_COMPILE=powerpc64-none-linux-gnu- drivers/ata/sata_dwc_460ex.o
>> scripts/kconfig/conf --silentoldconfig Kconfig
>>CHK include/config/kernel.release
>>UPD include/config/kernel.release
>>WRAParch/powerpc/include/generated/asm/clkdev.h
>>WRAParch/powerpc/include/generated/asm/div64.h
>>WRAParch/powerpc/include/generated/asm/irq_regs.h
>>WRAParch/powerpc/include/generated/asm/irq_work.h
>>WRAParch/powerpc/include/generated/asm/local64.h
>>WRAParch/powerpc/include/generated/asm/mcs_spinlock.h
>>WRAParch/powerpc/include/generated/asm/preempt.h
>>WRAParch/powerpc/include/generated/asm/rwsem.h
>>WRAParch/powerpc/include/generated/asm/vtime.h
>>CHK include/generated/uapi/linux/version.h
>>UPD include/generated/uapi/linux/version.h
>>CHK include/generated/utsrelease.h
>>UPD include/generated/utsrelease.h
>>CC kernel/bounds.s
>>CHK include/generated/bounds.h
>>UPD include/generated/bounds.h
>>CHK include/generated/timeconst.h
>>UPD include/generated/timeconst.h
>>CC arch/powerpc/kernel/asm-offsets.s
>>CHK include/generated/asm-offsets.h
>>UPD include/generated/asm-offsets.h
>>CALLscripts/checksyscalls.sh
>>HOSTCC scripts/dtc/dtc.o
>>HOSTCC scripts/dtc/flattree.o
>>HOSTCC scripts/dtc/fstree.o
>>HOSTCC scripts/dtc/data.o
>>HOSTCC scripts/dtc/livetree.o
>>HOSTCC scripts/dtc/treesource.o
>>HOSTCC scripts/dtc/srcpos.o
>>HOSTCC scripts/dtc/checks.o
>>HOSTCC scripts/dtc/util.o
>>SHIPPED scripts/dtc/dtc-lexer.lex.c
>>SHIPPED scripts/dtc/dtc-parser.tab.h
>>HOSTCC scripts/dtc/dtc-lexer.lex.o
>>SHIPPED scripts/dtc/dtc-parser.tab.c
>>HOSTCC scripts/dtc/dtc-parser.tab.o
>>HOSTLD scripts/dtc/dtc
>>CC
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/17/2015 8:06 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/17/2015 3:53 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/17/2015 2:51 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/17/2015 1:59 PM, Måns Rullgård wrote:
Julian Margetson writes:
I have been running my machine mostly configured for pciex1 thus with
the sata_dwc disabled.
The changes to sata_dwc-460ex do cause an oops.
I will try to give more detailed info over this weekend .
The driver as is upstream would do that since it unconditionally
dereferences a null pointer in the probe function. My patch fixes that
as a side-effect.
patching file drivers/ata/Kconfig
Hunk #1 FAILED at 296.
[...]
root@julian-VirtualBox:/usr/src/linux-3.18.25#
The patch is against 4.4-rc5.
CC drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’ has
initializer but incomplete type
static struct dw_dma_slave sata_dwc_dma_dws = {
^
It builds, albeit with an unrelated warning, using the attached config.
Maybe there's a missing config dependency somewhere.
I am attempting to cross compile under Ubuntu 14.04 X86 in Virtualbox
with your .config.
4.4.0-rc5 builds ok with no patches applied .
Once your patch is applied it fails to build .
CC drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’ has
initializer but incomplete type
static struct dw_dma_slave sata_dwc_dma_dws = {
^
Bizarre. This is what it looks like here:
mru@unicorn:/tmp/linux-sata$ git status
On branch sata-dwc
nothing to commit, working directory clean
mru@unicorn:/tmp/linux-sata$ git describe
v4.4-rc5
mru@unicorn:/tmp/linux-sata$ sha1sum
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
e300971aa483390f82de2e9120dc16e460e74feb
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
mru@unicorn:/tmp/linux-sata$ git am
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
Applying: ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
mru@unicorn:/tmp/linux-sata$ sha1sum .config
4e7615b8d2fa9a1c4b4ae9ffc363aefcaf3789ca .config
mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
CROSS_COMPILE=powerpc64-none-linux-gnu- oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
#
# configuration written to .config
#
mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
CROSS_COMPILE=powerpc64-none-linux-gnu- drivers/ata/sata_dwc_460ex.o
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config/kernel.release
UPD include/config/kernel.release
WRAParch/powerpc/include/generated/asm/clkdev.h
WRAParch/powerpc/include/generated/asm/div64.h
WRAParch/powerpc/include/generated/asm/irq_regs.h
WRAParch/powerpc/include/generated/asm/irq_work.h
WRAParch/powerpc/include/generated/asm/local64.h
WRAParch/powerpc/include/generated/asm/mcs_spinlock.h
WRAParch/powerpc/include/generated/asm/preempt.h
WRAParch/powerpc/include/generated/asm/rwsem.h
WRAParch/powerpc/include/generated/asm/vtime.h
CHK include/generated/uapi/linux/version.h
UPD include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
CC kernel/bounds.s
CHK include/generated/bounds.h
UPD include/generated/bounds.h
CHK include/generated/timeconst.h
UPD include/generated/timeconst.h
CC arch/powerpc/kernel/asm-offsets.s
CHK include/generated/asm-offsets.h
UPD include/generated/asm-offsets.h
CALLscripts/checksyscalls.sh
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
SHIPPED scripts/dtc/dtc-lexer.lex.c
SHIPPED scripts/dtc/dtc-parser.tab.h
HOSTCC scripts/dtc/dtc-lexer.lex.o
SHIPPED scripts/dtc/dtc-parser.tab.c
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTLD scripts/dtc/dtc
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/modpost.o
CC scripts/mod/devicetable-offsets.s
GEN scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/kallsyms
CC drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c: In function 'dma_dwc_xfer_setup':
drivers/ata/sata_dwc_460ex.c:383:20: warning: cast from pointer
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes:
> On Thu, 2015-12-17 at 17:41 -0400, Julian Margetson wrote:
>> On 12/17/2015 3:53 PM, Måns Rullgård wrote:
>> > Julian Margetson writes:
>> >
>> > > On 12/17/2015 2:51 PM, Måns Rullgård wrote:
>> > > > Julian Margetson writes:
>> > > >
>> > > > > On 12/17/2015 1:59 PM, Måns Rullgård wrote:
>> > > > > > Julian Margetson writes:
>> > > > > >
>> > > > > > > I have been running my machine mostly configured for
>> > > > > > > pciex1 thus with
>> > > > > > > the sata_dwc disabled.
>> > > > > > > The changes to sata_dwc-460ex do cause an oops.
>> > > > > > > I will try to give more detailed info over this weekend .
>> > > > > > The driver as is upstream would do that since it
>> > > > > > unconditionally
>> > > > > > dereferences a null pointer in the probe function. My
>> > > > > > patch fixes that
>> > > > > > as a side-effect.
>> > > > > >
>> > > > > patching file drivers/ata/Kconfig
>> > > > >
>> > > > > Hunk #1 FAILED at 296.
>> > > > [...]
>> > > >
>> > > > > root@julian-VirtualBox:/usr/src/linux-3.18.25#
>> > > > The patch is against 4.4-rc5.
>> > > >
>> > > CC drivers/ata/sata_dwc_460ex.o
>> > >
>> > > drivers/ata/sata_dwc_460ex.c:198:15: error: variable
>> > > ‘sata_dwc_dma_dws’ has initializer but incomplete type
>> > >
>> > > static struct dw_dma_slave sata_dwc_dma_dws = {
>> > > ^
>> > It builds, albeit with an unrelated warning, using the attached
>> > config.
>> > Maybe there's a missing config dependency somewhere.
>> >
>> I am attempting to cross compile under Ubuntu 14.04 X86 in Virtualbox
>> with your .config.
>> 4.4.0-rc5 builds ok with no patches applied .
>> Once your patch is applied it fails to build .
>> CC drivers/ata/sata_dwc_460ex.o
>> drivers/ata/sata_dwc_460ex.c:198:15: error: variable
>> ‘sata_dwc_dma_dws’ has initializer but incomplete type
>> static struct dw_dma_slave sata_dwc_dma_dws = {
>> ^
>> drivers/ata/sata_dwc_460ex.c:199:2: error: unknown field ‘src_id’
>> specified in initializer
>> .src_id = 0,
>
> This clearly means that header file that defines the struct
> dw_dma_slave is not included.
And yet two lines above there's this:
#include
This unconditionally defines struct dw_dma_slave.
Moreover, the line number in the error message above does not match any
version of the file with my patches applied. I suspect something went
wrong when Julian patched his tree.
> After the patch it seems you have to explicitly enable DW_DMAC, so,
> either via make nconfig, or by adding
> CONFIG_DW_DMAC=y
The option for enabling the compatibility code selects DW_DMAC. There
is a missing select DMA_ENGINE, but that won't make any difference here,
and my .config has it enabled anyhow.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Thu, 2015-12-17 at 17:41 -0400, Julian Margetson wrote:
> On 12/17/2015 3:53 PM, Måns Rullgård wrote:
> > Julian Margetson writes:
> >
> > > On 12/17/2015 2:51 PM, Måns Rullgård wrote:
> > > > Julian Margetson writes:
> > > >
> > > > > On 12/17/2015 1:59 PM, Måns Rullgård wrote:
> > > > > > Julian Margetson writes:
> > > > > >
> > > > > > > I have been running my machine mostly configured for
> > > > > > > pciex1 thus with
> > > > > > > the sata_dwc disabled.
> > > > > > > The changes to sata_dwc-460ex do cause an oops.
> > > > > > > I will try to give more detailed info over this weekend .
> > > > > > The driver as is upstream would do that since it
> > > > > > unconditionally
> > > > > > dereferences a null pointer in the probe function. My
> > > > > > patch fixes that
> > > > > > as a side-effect.
> > > > > >
> > > > > patching file drivers/ata/Kconfig
> > > > >
> > > > > Hunk #1 FAILED at 296.
> > > > [...]
> > > >
> > > > > root@julian-VirtualBox:/usr/src/linux-3.18.25#
> > > > The patch is against 4.4-rc5.
> > > >
> > > CC drivers/ata/sata_dwc_460ex.o
> > >
> > > drivers/ata/sata_dwc_460ex.c:198:15: error: variable
> > > ‘sata_dwc_dma_dws’ has initializer but incomplete type
> > >
> > > static struct dw_dma_slave sata_dwc_dma_dws = {
> > > ^
> > It builds, albeit with an unrelated warning, using the attached
> > config.
> > Maybe there's a missing config dependency somewhere.
> >
> I am attempting to cross compile under Ubuntu 14.04 X86 in Virtualbox
> with your .config.
> 4.4.0-rc5 builds ok with no patches applied .
> Once your patch is applied it fails to build .
> CC drivers/ata/sata_dwc_460ex.o
> drivers/ata/sata_dwc_460ex.c:198:15: error: variable
> ‘sata_dwc_dma_dws’ has initializer but incomplete type
> static struct dw_dma_slave sata_dwc_dma_dws = {
> ^
> drivers/ata/sata_dwc_460ex.c:199:2: error: unknown field ‘src_id’
> specified in initializer
> .src_id = 0,
This clearly means that header file that defines the struct
dw_dma_slave is not included.
After the patch it seems you have to explicitly enable DW_DMAC, so,
either via make nconfig, or by adding
CONFIG_DW_DMAC=y
> ^
> drivers/ata/sata_dwc_460ex.c:199:2: warning: excess elements in
> struct initializer [enabled by default]
> drivers/ata/sata_dwc_460ex.c:199:2: warning: (near initialization for
> ‘sata_dwc_dma_dws’) [enabled by default]
> drivers/ata/sata_dwc_460ex.c:200:2: error: unknown field ‘dst_id’
> specified in initializer
> .dst_id = 0,
> ^
> drivers/ata/sata_dwc_460ex.c:200:2: warning: excess elements in
> struct initializer [enabled by default]
> drivers/ata/sata_dwc_460ex.c:200:2: warning: (near initialization for
> ‘sata_dwc_dma_dws’) [enabled by default]
> drivers/ata/sata_dwc_460ex.c:201:2: error: unknown field ‘src_master’
> specified in initializer
> .src_master = 0,
> ^
> drivers/ata/sata_dwc_460ex.c:201:2: warning: excess elements in
> struct initializer [enabled by default]
> drivers/ata/sata_dwc_460ex.c:201:2: warning: (near initialization for
> ‘sata_dwc_dma_dws’) [enabled by default]
> drivers/ata/sata_dwc_460ex.c:202:2: error: unknown field ‘dst_master’
> specified in initializer
> .dst_master = 1,
> ^
> drivers/ata/sata_dwc_460ex.c:202:2: warning: excess elements in
> struct initializer [enabled by default]
> drivers/ata/sata_dwc_460ex.c:202:2: warning: (near initialization for
> ‘sata_dwc_dma_dws’) [enabled by default]
> drivers/ata/sata_dwc_460ex.c: In function ‘dma_dwc_xfer_setup’:
> drivers/ata/sata_dwc_460ex.c:389:20: warning: cast from pointer to
> integer of different size [-Wpointer-to-int-cast]
> dma_addr_t addr = (dma_addr_t)&hsdev->sata_dwc_regs->dmadr;
> ^
> drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_dma_filter’:
> drivers/ata/sata_dwc_460ex.c:872:9: error: dereferencing pointer to
> incomplete type
> if (dws->dma_dev != chan->device->dev)
> ^
> drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_port_start’:
> drivers/ata/sata_dwc_460ex.c:958:13: error: dereferencing pointer to
> incomplete type
> hsdevp->dws->dma_dev = hsdev->dev;
> ^
> drivers/ata/sata_dwc_460ex.c: In function ‘sata_dwc_probe’:
> drivers/ata/sata_dwc_460ex.c:1330:12: error: dereferencing pointer to
> incomplete type
> hsdev->dma->irq = irq_of_parse_and_map(np, 1);
> ^
> drivers/ata/sata_dwc_460ex.c:1331:16: error: dereferencing pointer to
> incomplete type
> if (hsdev->dma->irq == NO_IRQ) {
> ^
> drivers/ata/sata_dwc_460ex.c:1338:12: error: dereferencing pointer to
> incomplete type
> hsdev->dma->regs = of_iomap(np, 1);
> ^
> drivers/ata/sata_dwc_460ex.c:1339:17: error: dereferencing pointer to
> incomplete type
> if (!hsdev->dma->regs) {
> ^
> drivers/ata/sata_dwc_460ex.c:1349:12: error: dereferencing pointer to
> incomplete type
> hsdev->dma->dev = &ofdev->dev;
> ^
> drivers/ata/sata_dwc_460ex.c:1352:2: error: i
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/17/2015 8:06 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 3:53 PM, Måns Rullgård wrote:
Julian Margetson writes:
> On 12/17/2015 2:51 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 1:59 PM, Måns Rullgård wrote:
Julian Margetson writes:
> I have been running my machine mostly configured for pciex1 thus with
> the sata_dwc disabled.
> The changes to sata_dwc-460ex do cause an oops.
> I will try to give more detailed info over this weekend .
The driver as is upstream would do that since it unconditionally
dereferences a null pointer in the probe function. My patch fixes that
as a side-effect.
>>> patching file drivers/ata/Kconfig
>>>
>>> Hunk #1 FAILED at 296.
>> [...]
>>
>>> root@julian-VirtualBox:/usr/src/linux-3.18.25#
>> The patch is against 4.4-rc5.
>>
>CC drivers/ata/sata_dwc_460ex.o
>
> drivers/ata/sata_dwc_460ex.c:198:15: error: variable
> ‘sata_dwc_dma_dws’ has initializer but incomplete type
>
>static struct dw_dma_slave sata_dwc_dma_dws = {
> ^
It builds, albeit with an unrelated warning, using the attached config.
Maybe there's a missing config dependency somewhere.
>>> I am attempting to cross compile under Ubuntu 14.04 X86 in Virtualbox
>>> with your .config.
>>> 4.4.0-rc5 builds ok with no patches applied .
>>> Once your patch is applied it fails to build .
>>>
>>> CC drivers/ata/sata_dwc_460ex.o
>>> drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’ has
>>> initializer but incomplete type
>>> static struct dw_dma_slave sata_dwc_dma_dws = {
>>> ^
>> Bizarre. This is what it looks like here:
>>
>> mru@unicorn:/tmp/linux-sata$ git status
>> On branch sata-dwc
>> nothing to commit, working directory clean
>> mru@unicorn:/tmp/linux-sata$ git describe
>> v4.4-rc5
>> mru@unicorn:/tmp/linux-sata$ sha1sum
>> /tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
>> e300971aa483390f82de2e9120dc16e460e74feb
>> /tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
>> mru@unicorn:/tmp/linux-sata$ git am
>> /tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
>> Applying: ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
>> mru@unicorn:/tmp/linux-sata$ sha1sum .config
>> 4e7615b8d2fa9a1c4b4ae9ffc363aefcaf3789ca .config
>> mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
>> CROSS_COMPILE=powerpc64-none-linux-gnu- oldconfig
>>HOSTCC scripts/basic/fixdep
>>HOSTCC scripts/kconfig/conf.o
>>SHIPPED scripts/kconfig/zconf.tab.c
>>SHIPPED scripts/kconfig/zconf.lex.c
>>SHIPPED scripts/kconfig/zconf.hash.c
>>HOSTCC scripts/kconfig/zconf.tab.o
>>HOSTLD scripts/kconfig/conf
>> scripts/kconfig/conf --oldconfig Kconfig
>> #
>> # configuration written to .config
>> #
>> mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
>> CROSS_COMPILE=powerpc64-none-linux-gnu- drivers/ata/sata_dwc_460ex.o
>> scripts/kconfig/conf --silentoldconfig Kconfig
[...]
>>CC drivers/ata/sata_dwc_460ex.o
>> drivers/ata/sata_dwc_460ex.c: In function 'dma_dwc_xfer_setup':
>> drivers/ata/sata_dwc_460ex.c:383:20: warning: cast from pointer to integer
>> of different size [-Wpointer-to-int-cast]
>>dma_addr_t addr = (dma_addr_t)&hsdev->sata_dwc_regs->dmadr;
>> ^
>> mru@unicorn:/tmp/linux-sata$
>>
>> Patch file and .config attached.
>>
>> Looking into that warning, I doubt it works as is, but that's not caused
>> by my patch. I can try to come up with a fix, but again, I can't test it.
>>
> I am using
>
> make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
Shouldn't matter since the compiler flags include -m32, and I only had a
powerpc64 toolchain built. Anyhow, I built a 32-bit toolchain and it
still builds.
Just to make sure you applied the patch correctly:
mru@unicorn:/tmp/linux-sata$ sha1sum drivers/ata/sata_dwc_460ex.c
c8a7927840aade75ac62b04a2c9acc8335a34d6f drivers/ata/sata_dwc_460ex.c
Digging deeper into that warning, it is clearly a bug which has always
been there. The reason it ever worked appears to be that the 460EX has
a dedicated DMA unit hard-wired to the SATA controller ignoring that
address. The situation is similar on my hardware.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/17/2015 8:06 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/17/2015 3:53 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/17/2015 2:51 PM, Måns Rullgård wrote:
Julian Margetson writes:
On 12/17/2015 1:59 PM, Måns Rullgård wrote:
Julian Margetson writes:
I have been running my machine mostly configured for pciex1 thus with
the sata_dwc disabled.
The changes to sata_dwc-460ex do cause an oops.
I will try to give more detailed info over this weekend .
The driver as is upstream would do that since it unconditionally
dereferences a null pointer in the probe function. My patch fixes that
as a side-effect.
patching file drivers/ata/Kconfig
Hunk #1 FAILED at 296.
[...]
root@julian-VirtualBox:/usr/src/linux-3.18.25#
The patch is against 4.4-rc5.
CC drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’ has
initializer but incomplete type
static struct dw_dma_slave sata_dwc_dma_dws = {
^
It builds, albeit with an unrelated warning, using the attached config.
Maybe there's a missing config dependency somewhere.
I am attempting to cross compile under Ubuntu 14.04 X86 in Virtualbox
with your .config.
4.4.0-rc5 builds ok with no patches applied .
Once your patch is applied it fails to build .
CC drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’ has
initializer but incomplete type
static struct dw_dma_slave sata_dwc_dma_dws = {
^
Bizarre. This is what it looks like here:
mru@unicorn:/tmp/linux-sata$ git status
On branch sata-dwc
nothing to commit, working directory clean
mru@unicorn:/tmp/linux-sata$ git describe
v4.4-rc5
mru@unicorn:/tmp/linux-sata$ sha1sum
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
e300971aa483390f82de2e9120dc16e460e74feb
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
mru@unicorn:/tmp/linux-sata$ git am
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
Applying: ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
mru@unicorn:/tmp/linux-sata$ sha1sum .config
4e7615b8d2fa9a1c4b4ae9ffc363aefcaf3789ca .config
mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
CROSS_COMPILE=powerpc64-none-linux-gnu- oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
#
# configuration written to .config
#
mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
CROSS_COMPILE=powerpc64-none-linux-gnu- drivers/ata/sata_dwc_460ex.o
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config/kernel.release
UPD include/config/kernel.release
WRAParch/powerpc/include/generated/asm/clkdev.h
WRAParch/powerpc/include/generated/asm/div64.h
WRAParch/powerpc/include/generated/asm/irq_regs.h
WRAParch/powerpc/include/generated/asm/irq_work.h
WRAParch/powerpc/include/generated/asm/local64.h
WRAParch/powerpc/include/generated/asm/mcs_spinlock.h
WRAParch/powerpc/include/generated/asm/preempt.h
WRAParch/powerpc/include/generated/asm/rwsem.h
WRAParch/powerpc/include/generated/asm/vtime.h
CHK include/generated/uapi/linux/version.h
UPD include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
CC kernel/bounds.s
CHK include/generated/bounds.h
UPD include/generated/bounds.h
CHK include/generated/timeconst.h
UPD include/generated/timeconst.h
CC arch/powerpc/kernel/asm-offsets.s
CHK include/generated/asm-offsets.h
UPD include/generated/asm-offsets.h
CALLscripts/checksyscalls.sh
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
SHIPPED scripts/dtc/dtc-lexer.lex.c
SHIPPED scripts/dtc/dtc-parser.tab.h
HOSTCC scripts/dtc/dtc-lexer.lex.o
SHIPPED scripts/dtc/dtc-parser.tab.c
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTLD scripts/dtc/dtc
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/modpost.o
CC scripts/mod/devicetable-offsets.s
GEN scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/kallsyms
CC drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c: In function 'dma_dwc_xfer_setup':
drivers/ata/sata_dwc_460ex.c:383:20: warning: cast from pointer
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/17/2015 3:53 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 2:51 PM, Måns Rullgård wrote:
Julian Margetson writes:
> On 12/17/2015 1:59 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> I have been running my machine mostly configured for pciex1 thus with
>>> the sata_dwc disabled.
>>> The changes to sata_dwc-460ex do cause an oops.
>>> I will try to give more detailed info over this weekend .
>> The driver as is upstream would do that since it unconditionally
>> dereferences a null pointer in the probe function. My patch fixes that
>> as a side-effect.
>>
> patching file drivers/ata/Kconfig
>
> Hunk #1 FAILED at 296.
[...]
> root@julian-VirtualBox:/usr/src/linux-3.18.25#
The patch is against 4.4-rc5.
>>> CC drivers/ata/sata_dwc_460ex.o
>>>
>>> drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’
>>> has initializer but incomplete type
>>>
>>> static struct dw_dma_slave sata_dwc_dma_dws = {
>>> ^
>> It builds, albeit with an unrelated warning, using the attached config.
>> Maybe there's a missing config dependency somewhere.
>>
> I am attempting to cross compile under Ubuntu 14.04 X86 in Virtualbox
> with your .config.
> 4.4.0-rc5 builds ok with no patches applied .
> Once your patch is applied it fails to build .
>
> CC drivers/ata/sata_dwc_460ex.o
> drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’ has
> initializer but incomplete type
> static struct dw_dma_slave sata_dwc_dma_dws = {
>^
Bizarre. This is what it looks like here:
mru@unicorn:/tmp/linux-sata$ git status
On branch sata-dwc
nothing to commit, working directory clean
mru@unicorn:/tmp/linux-sata$ git describe
v4.4-rc5
mru@unicorn:/tmp/linux-sata$ sha1sum
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
e300971aa483390f82de2e9120dc16e460e74feb
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
mru@unicorn:/tmp/linux-sata$ git am
/tmp/0001-ata-sata_dwc_460ex-use-dmas-DT-property-to-find-dma-.patch
Applying: ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
mru@unicorn:/tmp/linux-sata$ sha1sum .config
4e7615b8d2fa9a1c4b4ae9ffc363aefcaf3789ca .config
mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
CROSS_COMPILE=powerpc64-none-linux-gnu- oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
#
# configuration written to .config
#
mru@unicorn:/tmp/linux-sata$ make ARCH=powerpc
CROSS_COMPILE=powerpc64-none-linux-gnu- drivers/ata/sata_dwc_460ex.o
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config/kernel.release
UPD include/config/kernel.release
WRAParch/powerpc/include/generated/asm/clkdev.h
WRAParch/powerpc/include/generated/asm/div64.h
WRAParch/powerpc/include/generated/asm/irq_regs.h
WRAParch/powerpc/include/generated/asm/irq_work.h
WRAParch/powerpc/include/generated/asm/local64.h
WRAParch/powerpc/include/generated/asm/mcs_spinlock.h
WRAParch/powerpc/include/generated/asm/preempt.h
WRAParch/powerpc/include/generated/asm/rwsem.h
WRAParch/powerpc/include/generated/asm/vtime.h
CHK include/generated/uapi/linux/version.h
UPD include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
CC kernel/bounds.s
CHK include/generated/bounds.h
UPD include/generated/bounds.h
CHK include/generated/timeconst.h
UPD include/generated/timeconst.h
CC arch/powerpc/kernel/asm-offsets.s
CHK include/generated/asm-offsets.h
UPD include/generated/asm-offsets.h
CALLscripts/checksyscalls.sh
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
SHIPPED scripts/dtc/dtc-lexer.lex.c
SHIPPED scripts/dtc/dtc-parser.tab.h
HOSTCC scripts/dtc/dtc-lexer.lex.o
SHIPPED scripts/dtc/dtc-parser.tab.c
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTLD scripts/dtc/dtc
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/modpost.o
CC scripts/mod/devicetable-offsets.s
GEN scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/kallsyms
CC drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c: In function 'dma_dwc_xfer_se
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes:
> On 12/17/2015 2:51 PM, Måns Rullgård wrote:
>> Julian Margetson writes:
>>
>>> On 12/17/2015 1:59 PM, Måns Rullgård wrote:
Julian Margetson writes:
> I have been running my machine mostly configured for pciex1 thus with
> the sata_dwc disabled.
> The changes to sata_dwc-460ex do cause an oops.
> I will try to give more detailed info over this weekend .
The driver as is upstream would do that since it unconditionally
dereferences a null pointer in the probe function. My patch fixes that
as a side-effect.
>>> patching file drivers/ata/Kconfig
>>>
>>> Hunk #1 FAILED at 296.
>> [...]
>>
>>> root@julian-VirtualBox:/usr/src/linux-3.18.25#
>> The patch is against 4.4-rc5.
>>
> CC drivers/ata/sata_dwc_460ex.o
>
> drivers/ata/sata_dwc_460ex.c:198:15: error: variable ‘sata_dwc_dma_dws’
> has initializer but incomplete type
>
> static struct dw_dma_slave sata_dwc_dma_dws = {
>^
It builds, albeit with an unrelated warning, using the attached config.
Maybe there's a missing config dependency somewhere.
--
Måns Rullgård
#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 4.4.0-rc5 Kernel Configuration
#
# CONFIG_PPC64 is not set
#
# Processor support
#
# CONFIG_PPC_BOOK3S_32 is not set
# CONFIG_PPC_85xx is not set
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
CONFIG_44x=y
# CONFIG_E200 is not set
CONFIG_PPC_FPU=y
CONFIG_4xx=y
CONFIG_BOOKE=y
CONFIG_PTE_64BIT=y
CONFIG_PHYS_64BIT=y
CONFIG_PPC_MMU_NOHASH=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_NOT_COHERENT_CACHE=y
# CONFIG_PPC_DOORBELL is not set
CONFIG_VDSO32=y
CONFIG_CPU_BIG_ENDIAN=y
CONFIG_PPC32=y
CONFIG_32BIT=y
CONFIG_WORD_SIZE=32
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_MMU=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
# CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK is not set
CONFIG_NR_IRQS=512
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y
CONFIG_PPC=y
# CONFIG_GENERIC_CSUM is not set
CONFIG_EARLY_PRINTK=y
CONFIG_PANIC_TIMEOUT=180
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_EPAPR_BOOT is not set
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_PPC_DCR_NATIVE=y
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_PPC_DCR=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_PPC_ADV_DEBUG_REGS=y
CONFIG_PPC_ADV_DEBUG_IACS=4
CONFIG_PPC_ADV_DEBUG_DACS=2
CONFIG_PPC_ADV_DEBUG_DVCS=2
CONFIG_PPC_ADV_DEBUG_DAC_RANGE=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_TIME_VSYSCALL_OLD=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > On 12/17/2015 1:59 PM, Måns Rullgård wrote: >> Julian Margetson writes: >> >>> I have been running my machine mostly configured for pciex1 thus with >>> the sata_dwc disabled. >>> The changes to sata_dwc-460ex do cause an oops. >>> I will try to give more detailed info over this weekend . >> The driver as is upstream would do that since it unconditionally >> dereferences a null pointer in the probe function. My patch fixes that >> as a side-effect. >> > > patching file drivers/ata/Kconfig > > Hunk #1 FAILED at 296. [...] > root@julian-VirtualBox:/usr/src/linux-3.18.25# The patch is against 4.4-rc5. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On 12/17/2015 12:53 PM, Andy Shevchenko wrote:
On Thu, 2015-12-17 at 16:04 +, Måns Rullgård wrote:
Andy Shevchenko writes:
On Thu, 2015-12-17 at 15:13 +, Måns Rullgård wrote:
Andy Shevchenko writes:
On Tue, 2015-12-15 at 23:34 +, Måns Rullgård wrote:
Mans Rullgard writes:
Currently this driver only works with a DesignWare DMA
engine
which it registers manually using the second "reg" address
range and interrupt number from the DT node.
This patch makes the driver instead use the "dmas" property
if
present, otherwise optionally falling back on the old way
so
existing device trees can continue to work.
With this change, there is no longer any reason to depend
on
the 460EX machine type so drop that from Kconfig.
Signed-off-by: Mans Rullgard
---
drivers/ata/Kconfig | 10 ++-
drivers/ata/sata_dwc_460ex.c | 192
+++--
--
2 files changed, 131 insertions(+), 71 deletions(-)
The corresponding patch for the canyonlands devicetree looks
something
like this. I don't have any such hardware or even a manual,
so I
don't
know what values to use for the various required DT
properties of
the
DMA controller node, nor can I test it. The SATA driver
works
with a
different DMA controller on a Sigma Designs chip.
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 3dc75de..959f36e 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -190,12 +190,22 @@
/* DMA */ 0x2 &UIC0
0xc
0x4>;
};
+ DMA0: dma@bffd0800 {
+ compatible = "snps,dma-spear1340";
+ reg = <4 0xbffd0800 0x400>;
+ interrupt-parent = <&UIC3>;
+ interrupts = <0x5 0x4>;
+ #dma-cells = <3>;
+ /* required properties here */
You have to move the master assignments and other custom
dw_dmac
properties. Maybe at some point I will fix that in
dw/platform.c.
+ };
The current sata_dwc driver calls dw_dma_probe() with null pdata
which causes the dw_dma driver to auto-detect most
parameters. It
looks like simply omitting those properties here results in the
same
thing, although in this case dw_dma_parse_dt() leaves a
devm-allocated pdata struct adrift. Deferring the allocation of
that
and changing the DT binding doc to make these properties optional
for
auto-detect-capable hardware should just work.
Yeah, I would like to allow autoconfiguration in case of DT as well
and
translate it to use unified device property API.
Something like this:
If it works for you, please, submit as a patch. Thanks.
I can't test it since I have no such hardware.
It's currently broken, last person who seems to have it is
(was?) Julian Margetson [1]
[1] https://patchwork.ozlabs.org/patch/439850/
I have been running my machine mostly configured for pciex1 thus with
the sata_dwc disabled.
The changes to sata_dwc-460ex do cause an oops.
I will try to give more detailed info over this weekend .
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > I have been running my machine mostly configured for pciex1 thus with > the sata_dwc disabled. > The changes to sata_dwc-460ex do cause an oops. > I will try to give more detailed info over this weekend . The driver as is upstream would do that since it unconditionally dereferences a null pointer in the probe function. My patch fixes that as a side-effect. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Thu, 2015-12-17 at 16:04 +, Måns Rullgård wrote:
> Andy Shevchenko writes:
>
> > On Thu, 2015-12-17 at 15:13 +, Måns Rullgård wrote:
> > > Andy Shevchenko writes:
> > >
> > > > On Tue, 2015-12-15 at 23:34 +, Måns Rullgård wrote:
> > > > > Mans Rullgard writes:
> > > > >
> > > > > > Currently this driver only works with a DesignWare DMA
> > > > > > engine
> > > > > > which it registers manually using the second "reg" address
> > > > > > range and interrupt number from the DT node.
> > > > > >
> > > > > > This patch makes the driver instead use the "dmas" property
> > > > > > if
> > > > > > present, otherwise optionally falling back on the old way
> > > > > > so
> > > > > > existing device trees can continue to work.
> > > > > >
> > > > > > With this change, there is no longer any reason to depend
> > > > > > on
> > > > > > the 460EX machine type so drop that from Kconfig.
> > > > > >
> > > > > > Signed-off-by: Mans Rullgard
> > > > > > ---
> > > > > > drivers/ata/Kconfig | 10 ++-
> > > > > > drivers/ata/sata_dwc_460ex.c | 192
> > > > > > +++--
> > > > > > --
> > > > > > 2 files changed, 131 insertions(+), 71 deletions(-)
> > > > >
> > > > > The corresponding patch for the canyonlands devicetree looks
> > > > > something
> > > > > like this. I don't have any such hardware or even a manual,
> > > > > so I
> > > > > don't
> > > > > know what values to use for the various required DT
> > > > > properties of
> > > > > the
> > > > > DMA controller node, nor can I test it. The SATA driver
> > > > > works
> > > > > with a
> > > > > different DMA controller on a Sigma Designs chip.
> > > > >
> > > > > diff --git a/arch/powerpc/boot/dts/canyonlands.dts
> > > > > b/arch/powerpc/boot/dts/canyonlands.dts
> > > > > index 3dc75de..959f36e 100644
> > > > > --- a/arch/powerpc/boot/dts/canyonlands.dts
> > > > > +++ b/arch/powerpc/boot/dts/canyonlands.dts
> > > > > @@ -190,12 +190,22 @@
> > > > > /* DMA */ 0x2 &UIC0
> > > > > 0xc
> > > > > 0x4>;
> > > > > };
> > > > >
> > > > > + DMA0: dma@bffd0800 {
> > > > > + compatible = "snps,dma-spear1340";
> > > > > + reg = <4 0xbffd0800 0x400>;
> > > > > + interrupt-parent = <&UIC3>;
> > > > > + interrupts = <0x5 0x4>;
> > > > > + #dma-cells = <3>;
> > > > > + /* required properties here */
> > > >
> > > > You have to move the master assignments and other custom
> > > > dw_dmac
> > > > properties. Maybe at some point I will fix that in
> > > > dw/platform.c.
> > > >
> > > > > + };
> > >
> > > The current sata_dwc driver calls dw_dma_probe() with null pdata
> > > which causes the dw_dma driver to auto-detect most
> > > parameters. It
> > > looks like simply omitting those properties here results in the
> > > same
> > > thing, although in this case dw_dma_parse_dt() leaves a
> > > devm-allocated pdata struct adrift. Deferring the allocation of
> > > that
> > > and changing the DT binding doc to make these properties optional
> > > for
> > > auto-detect-capable hardware should just work.
> >
> > Yeah, I would like to allow autoconfiguration in case of DT as well
> > and
> > translate it to use unified device property API.
> >
> > > Something like this:
> >
> > If it works for you, please, submit as a patch. Thanks.
>
> I can't test it since I have no such hardware.
It's currently broken, last person who seems to have it is
(was?) Julian Margetson [1]
[1] https://patchwork.ozlabs.org/patch/439850/
--
Andy Shevchenko
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes:
> On Thu, 2015-12-17 at 15:13 +, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > On Tue, 2015-12-15 at 23:34 +, Måns Rullgård wrote:
>> > > Mans Rullgard writes:
>> > >
>> > > > Currently this driver only works with a DesignWare DMA engine
>> > > > which it registers manually using the second "reg" address
>> > > > range and interrupt number from the DT node.
>> > > >
>> > > > This patch makes the driver instead use the "dmas" property if
>> > > > present, otherwise optionally falling back on the old way so
>> > > > existing device trees can continue to work.
>> > > >
>> > > > With this change, there is no longer any reason to depend on
>> > > > the 460EX machine type so drop that from Kconfig.
>> > > >
>> > > > Signed-off-by: Mans Rullgard
>> > > > ---
>> > > > drivers/ata/Kconfig | 10 ++-
>> > > > drivers/ata/sata_dwc_460ex.c | 192
>> > > > +++--
>> > > > --
>> > > > 2 files changed, 131 insertions(+), 71 deletions(-)
>> > >
>> > > The corresponding patch for the canyonlands devicetree looks
>> > > something
>> > > like this. I don't have any such hardware or even a manual, so I
>> > > don't
>> > > know what values to use for the various required DT properties of
>> > > the
>> > > DMA controller node, nor can I test it. The SATA driver works
>> > > with a
>> > > different DMA controller on a Sigma Designs chip.
>> > >
>> > > diff --git a/arch/powerpc/boot/dts/canyonlands.dts
>> > > b/arch/powerpc/boot/dts/canyonlands.dts
>> > > index 3dc75de..959f36e 100644
>> > > --- a/arch/powerpc/boot/dts/canyonlands.dts
>> > > +++ b/arch/powerpc/boot/dts/canyonlands.dts
>> > > @@ -190,12 +190,22 @@
>> > > /* DMA */ 0x2 &UIC0 0xc
>> > > 0x4>;
>> > > };
>> > >
>> > > +DMA0: dma@bffd0800 {
>> > > +compatible = "snps,dma-spear1340";
>> > > +reg = <4 0xbffd0800 0x400>;
>> > > +interrupt-parent = <&UIC3>;
>> > > +interrupts = <0x5 0x4>;
>> > > +#dma-cells = <3>;
>> > > +/* required properties here */
>> >
>> > You have to move the master assignments and other custom dw_dmac
>> > properties. Maybe at some point I will fix that in dw/platform.c.
>> >
>> > > +};
>>
>> The current sata_dwc driver calls dw_dma_probe() with null pdata
>> which causes the dw_dma driver to auto-detect most parameters. It
>> looks like simply omitting those properties here results in the same
>> thing, although in this case dw_dma_parse_dt() leaves a
>> devm-allocated pdata struct adrift. Deferring the allocation of that
>> and changing the DT binding doc to make these properties optional for
>> auto-detect-capable hardware should just work.
>
> Yeah, I would like to allow autoconfiguration in case of DT as well and
> translate it to use unified device property API.
>
>> Something like this:
>
> If it works for you, please, submit as a patch. Thanks.
I can't test it since I have no such hardware.
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Thu, 2015-12-17 at 15:13 +, Måns Rullgård wrote:
> Andy Shevchenko writes:
>
> > On Tue, 2015-12-15 at 23:34 +, Måns Rullgård wrote:
> > > Mans Rullgard writes:
> > >
> > > > Currently this driver only works with a DesignWare DMA engine
> > > > which
> > > > it
> > > > registers manually using the second "reg" address range and
> > > > interrupt
> > > > number from the DT node.
> > > >
> > > > This patch makes the driver instead use the "dmas" property if
> > > > present,
> > > > otherwise optionally falling back on the old way so existing
> > > > device
> > > > trees can continue to work.
> > > >
> > > > With this change, there is no longer any reason to depend on
> > > > the
> > > > 460EX
> > > > machine type so drop that from Kconfig.
> > > >
> > > > Signed-off-by: Mans Rullgard
> > > > ---
> > > > drivers/ata/Kconfig | 10 ++-
> > > > drivers/ata/sata_dwc_460ex.c | 192
> > > > +++--
> > > > --
> > > > 2 files changed, 131 insertions(+), 71 deletions(-)
> > >
> > > The corresponding patch for the canyonlands devicetree looks
> > > something
> > > like this. I don't have any such hardware or even a manual, so I
> > > don't
> > > know what values to use for the various required DT properties of
> > > the
> > > DMA controller node, nor can I test it. The SATA driver works
> > > with a
> > > different DMA controller on a Sigma Designs chip.
> > >
> > > diff --git a/arch/powerpc/boot/dts/canyonlands.dts
> > > b/arch/powerpc/boot/dts/canyonlands.dts
> > > index 3dc75de..959f36e 100644
> > > --- a/arch/powerpc/boot/dts/canyonlands.dts
> > > +++ b/arch/powerpc/boot/dts/canyonlands.dts
> > > @@ -190,12 +190,22 @@
> > > /* DMA */ 0x2 &UIC0 0xc
> > > 0x4>;
> > > };
> > >
> > > + DMA0: dma@bffd0800 {
> > > + compatible = "snps,dma-spear1340";
> > > + reg = <4 0xbffd0800 0x400>;
> > > + interrupt-parent = <&UIC3>;
> > > + interrupts = <0x5 0x4>;
> > > + #dma-cells = <3>;
> > > + /* required properties here */
> >
> > You have to move the master assignments and other custom dw_dmac
> > properties. Maybe at some point I will fix that in dw/platform.c.
> >
> > > + };
>
> The current sata_dwc driver calls dw_dma_probe() with null pdata
> which
> causes the dw_dma driver to auto-detect most parameters. It looks
> like
> simply omitting those properties here results in the same thing,
> although in this case dw_dma_parse_dt() leaves a devm-allocated pdata
> struct adrift. Deferring the allocation of that and changing the DT
> binding doc to make these properties optional for auto-detect-capable
> hardware should just work.
Yeah, I would like to allow autoconfiguration in case of DT as well and
translate it to use unified device property API.
> Something like this:
If it works for you, please, submit as a patch. Thanks.
>
> diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
> index 68a4815..f90c465 100644
> --- a/drivers/dma/dw/platform.c
> +++ b/drivers/dma/dw/platform.c
> @@ -103,18 +103,21 @@ dw_dma_parse_dt(struct platform_device *pdev)
> struct device_node *np = pdev->dev.of_node;
> struct dw_dma_platform_data *pdata;
> u32 tmp, arr[DW_DMA_MAX_NR_MASTERS];
> + u32 nr_channels;
>
> if (!np) {
> dev_err(&pdev->dev, "Missing DT data\n");
> return NULL;
> }
>
> + if (of_property_read_u32(np, "dma-channels", nr_channels))
> + return NULL;
> +
> pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata),
> GFP_KERNEL);
> if (!pdata)
> return NULL;
>
> - if (of_property_read_u32(np, "dma-channels", &pdata-
> >nr_channels))
> - return NULL;
> + pdata->nr_channels = nr_channels;
>
> if (of_property_read_bool(np, "is_private"))
> pdata->is_private = true;
>
>
--
Andy Shevchenko
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Andy Shevchenko writes:
> On Tue, 2015-12-15 at 23:34 +, Måns Rullgård wrote:
>> Mans Rullgard writes:
>>
>> > Currently this driver only works with a DesignWare DMA engine which
>> > it
>> > registers manually using the second "reg" address range and
>> > interrupt
>> > number from the DT node.
>> >
>> > This patch makes the driver instead use the "dmas" property if
>> > present,
>> > otherwise optionally falling back on the old way so existing device
>> > trees can continue to work.
>> >
>> > With this change, there is no longer any reason to depend on the
>> > 460EX
>> > machine type so drop that from Kconfig.
>> >
>> > Signed-off-by: Mans Rullgard
>> > ---
>> > drivers/ata/Kconfig | 10 ++-
>> > drivers/ata/sata_dwc_460ex.c | 192 +++--
>> > --
>> > 2 files changed, 131 insertions(+), 71 deletions(-)
>>
>> The corresponding patch for the canyonlands devicetree looks
>> something
>> like this. I don't have any such hardware or even a manual, so I
>> don't
>> know what values to use for the various required DT properties of the
>> DMA controller node, nor can I test it. The SATA driver works with a
>> different DMA controller on a Sigma Designs chip.
>>
>> diff --git a/arch/powerpc/boot/dts/canyonlands.dts
>> b/arch/powerpc/boot/dts/canyonlands.dts
>> index 3dc75de..959f36e 100644
>> --- a/arch/powerpc/boot/dts/canyonlands.dts
>> +++ b/arch/powerpc/boot/dts/canyonlands.dts
>> @@ -190,12 +190,22 @@
>> /* DMA */ 0x2 &UIC0 0xc
>> 0x4>;
>> };
>>
>> +DMA0: dma@bffd0800 {
>> +compatible = "snps,dma-spear1340";
>> +reg = <4 0xbffd0800 0x400>;
>> +interrupt-parent = <&UIC3>;
>> +interrupts = <0x5 0x4>;
>> +#dma-cells = <3>;
>> +/* required properties here */
>
> You have to move the master assignments and other custom dw_dmac
> properties. Maybe at some point I will fix that in dw/platform.c.
>
>> +};
The current sata_dwc driver calls dw_dma_probe() with null pdata which
causes the dw_dma driver to auto-detect most parameters. It looks like
simply omitting those properties here results in the same thing,
although in this case dw_dma_parse_dt() leaves a devm-allocated pdata
struct adrift. Deferring the allocation of that and changing the DT
binding doc to make these properties optional for auto-detect-capable
hardware should just work. Something like this:
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 68a4815..f90c465 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -103,18 +103,21 @@ dw_dma_parse_dt(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct dw_dma_platform_data *pdata;
u32 tmp, arr[DW_DMA_MAX_NR_MASTERS];
+ u32 nr_channels;
if (!np) {
dev_err(&pdev->dev, "Missing DT data\n");
return NULL;
}
+ if (of_property_read_u32(np, "dma-channels", nr_channels))
+ return NULL;
+
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return NULL;
- if (of_property_read_u32(np, "dma-channels", &pdata->nr_channels))
- return NULL;
+ pdata->nr_channels = nr_channels;
if (of_property_read_bool(np, "is_private"))
pdata->is_private = true;
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Tue, 2015-12-15 at 23:34 +, Måns Rullgård wrote:
> Mans Rullgard writes:
>
> > Currently this driver only works with a DesignWare DMA engine which
> > it
> > registers manually using the second "reg" address range and
> > interrupt
> > number from the DT node.
> >
> > This patch makes the driver instead use the "dmas" property if
> > present,
> > otherwise optionally falling back on the old way so existing device
> > trees can continue to work.
> >
> > With this change, there is no longer any reason to depend on the
> > 460EX
> > machine type so drop that from Kconfig.
> >
> > Signed-off-by: Mans Rullgard
> > ---
> > drivers/ata/Kconfig | 10 ++-
> > drivers/ata/sata_dwc_460ex.c | 192 +++--
> > --
> > 2 files changed, 131 insertions(+), 71 deletions(-)
>
> The corresponding patch for the canyonlands devicetree looks
> something
> like this. I don't have any such hardware or even a manual, so I
> don't
> know what values to use for the various required DT properties of the
> DMA controller node, nor can I test it. The SATA driver works with a
> different DMA controller on a Sigma Designs chip.
>
> diff --git a/arch/powerpc/boot/dts/canyonlands.dts
> b/arch/powerpc/boot/dts/canyonlands.dts
> index 3dc75de..959f36e 100644
> --- a/arch/powerpc/boot/dts/canyonlands.dts
> +++ b/arch/powerpc/boot/dts/canyonlands.dts
> @@ -190,12 +190,22 @@
> /* DMA */ 0x2 &UIC0 0xc
> 0x4>;
> };
>
> + DMA0: dma@bffd0800 {
> + compatible = "snps,dma-spear1340";
> + reg = <4 0xbffd0800 0x400>;
> + interrupt-parent = <&UIC3>;
> + interrupts = <0x5 0x4>;
> + #dma-cells = <3>;
> + /* required properties here */
You have to move the master assignments and other custom dw_dmac
properties. Maybe at some point I will fix that in dw/platform.c.
> + };
> +
> SATA0: sata@bffd1000 {
> compatible = "amcc,sata-460ex";
> - reg = <4 0xbffd1000 0x800 4 0xbffd0800
> 0x400>;
> + reg = <4 0xbffd1000 0x800>;
> interrupt-parent = <&UIC3>;
> - interrupts = <0x0 0x4 /* SATA */
> - 0x5 0x4>; /* AHBDMA */
> + interrupts = <0x0 0x4>;
> + dmas = <&DMA0 0 0 1>;
> + dma-names = "sata-dma";
> };
>
> POB0: opb {
>
>
--
Andy Shevchenko
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Tue, 2015-12-15 at 23:25 +, Mans Rullgard wrote:
> Currently this driver only works with a DesignWare DMA engine which
> it
> registers manually using the second "reg" address range and interrupt
> number from the DT node.
>
> This patch makes the driver instead use the "dmas" property if
> present,
> otherwise optionally falling back on the old way so existing device
> trees can continue to work.
>
> With this change, there is no longer any reason to depend on the
> 460EX
> machine type so drop that from Kconfig.
Looks good for me (from dw_dmac usage prospective).
>
> Signed-off-by: Mans Rullgard
> ---
> drivers/ata/Kconfig | 10 ++-
> drivers/ata/sata_dwc_460ex.c | 192 +++
>
> 2 files changed, 131 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index 3fc2a56..193c673 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -296,14 +296,20 @@ config ATA_PIIX
>
> config SATA_DWC
> tristate "DesignWare Cores SATA support"
> - depends on 460EX
> - select DW_DMAC
> help
> This option enables support for the on-chip SATA
> controller of the
> AppliedMicro processor 460EX.
>
> If unsure, say N.
>
> +config SATA_DWC_OLD_DMA
> + bool "Support old device trees"
> + depends on SATA_DWC && 460EX
> + select DW_DMAC
> + help
> + This option enables support for old device trees without
> the
> + "dmas" property.
> +
> config SATA_DWC_DEBUG
> bool "Debugging driver version"
> depends on SATA_DWC
> diff --git a/drivers/ata/sata_dwc_460ex.c
> b/drivers/ata/sata_dwc_460ex.c
> index 9020349..9985749 100644
> --- a/drivers/ata/sata_dwc_460ex.c
> +++ b/drivers/ata/sata_dwc_460ex.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -42,10 +43,6 @@
> #include
> #include
>
> -/* Supported DMA engine drivers */
> -#include
> -#include
> -
> /* These two are defined in "libata.h" */
> #undef DRV_NAME
> #undef DRV_VERSION
> @@ -148,7 +145,9 @@ struct sata_dwc_device {
> struct ata_host *host;
> u8 __iomem *reg_base;
> struct sata_dwc_regs*sata_dwc_regs; /* DW
> Synopsys SATA specific */
> +#ifdef CONFIG_SATA_DWC_OLD_DMA
> struct dw_dma_chip *dma;
> +#endif
> };
>
> #define SATA_DWC_QCMD_MAX32
> @@ -159,7 +158,6 @@ struct sata_dwc_device_port {
> int dma_pending[SATA_DWC_QCMD_MAX];
>
> /* DMA info */
> - struct dw_dma_slave *dws;
> struct dma_chan *chan;
> struct dma_async_tx_descriptor *desc[SATA_DWC_QCMD_MA
> X];
> u32 dma_interrupt_count;
> @@ -198,13 +196,6 @@ struct sata_dwc_host_priv {
>
> static struct sata_dwc_host_priv host_pvt;
>
> -static struct dw_dma_slave sata_dwc_dma_dws = {
> - .src_id = 0,
> - .dst_id = 0,
> - .src_master = 0,
> - .dst_master = 1,
> -};
> -
> /*
> * Prototypes
> */
> @@ -215,6 +206,90 @@ static void sata_dwc_dma_xfer_complete(struct
> ata_port *ap, u32 check_status);
> static void sata_dwc_port_stop(struct ata_port *ap);
> static void sata_dwc_clear_dmacr(struct sata_dwc_device_port
> *hsdevp, u8 tag);
>
> +#ifdef CONFIG_SATA_DWC_OLD_DMA
> +
> +#include
> +#include
> +
> +static struct dw_dma_slave sata_dwc_dma_dws = {
> + .src_id = 0,
> + .dst_id = 0,
> + .src_master = 0,
> + .dst_master = 1,
> +};
> +
> +static bool sata_dwc_dma_filter(struct dma_chan *chan, void *param)
> +{
> + struct dw_dma_slave *dws = &sata_dwc_dma_dws;
> +
> + if (dws->dma_dev != chan->device->dev)
> + return false;
> +
> + chan->private = dws;
> + return true;
> +}
> +
> +static int sata_dwc_dma_get_channel_old(struct sata_dwc_device_port
> *hsdevp)
> +{
> + struct sata_dwc_device *hsdev = hsdevp->hsdev;
> + struct dw_dma_slave *dws = &sata_dwc_dma_dws;
> + dma_cap_mask_t mask;
> +
> + dws->dma_dev = hsdev->dev;
> +
> + dma_cap_zero(mask);
> + dma_cap_set(DMA_SLAVE, mask);
> +
> + /* Acquire DMA channel */
> + hsdevp->chan = dma_request_channel(mask,
> sata_dwc_dma_filter, hsdevp);
> + if (!hsdevp->chan) {
> + dev_err(hsdev->dev, "%s: dma channel unavailable\n",
> + __func__);
> + return -EAGAIN;
> + }
> +
> + return 0;
> +}
> +
> +static int sata_dwc_dma_init_old(struct platform_device *pdev,
> + struct sata_dwc_device *hsdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + int err;
> +
> + hsdev->dma = devm_kzalloc(&pdev->dev, sizeof(*hsdev->dma),
> GFP_KERNEL);
> + if (!hsdev->dma)
> + return -ENOMEM;
> +
> + hsdev->dma->dev = &pdev->dev;
> +
> + /* Get SATA DMA interrupt number */
> + hsdev->dma->irq = irq_of_pars
Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Mans Rullgard writes:
> Currently this driver only works with a DesignWare DMA engine which it
> registers manually using the second "reg" address range and interrupt
> number from the DT node.
>
> This patch makes the driver instead use the "dmas" property if present,
> otherwise optionally falling back on the old way so existing device
> trees can continue to work.
>
> With this change, there is no longer any reason to depend on the 460EX
> machine type so drop that from Kconfig.
>
> Signed-off-by: Mans Rullgard
> ---
> drivers/ata/Kconfig | 10 ++-
> drivers/ata/sata_dwc_460ex.c | 192
> +++
> 2 files changed, 131 insertions(+), 71 deletions(-)
The corresponding patch for the canyonlands devicetree looks something
like this. I don't have any such hardware or even a manual, so I don't
know what values to use for the various required DT properties of the
DMA controller node, nor can I test it. The SATA driver works with a
different DMA controller on a Sigma Designs chip.
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 3dc75de..959f36e 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -190,12 +190,22 @@
/* DMA */ 0x2 &UIC0 0xc 0x4>;
};
+ DMA0: dma@bffd0800 {
+ compatible = "snps,dma-spear1340";
+ reg = <4 0xbffd0800 0x400>;
+ interrupt-parent = <&UIC3>;
+ interrupts = <0x5 0x4>;
+ #dma-cells = <3>;
+ /* required properties here */
+ };
+
SATA0: sata@bffd1000 {
compatible = "amcc,sata-460ex";
- reg = <4 0xbffd1000 0x800 4 0xbffd0800 0x400>;
+ reg = <4 0xbffd1000 0x800>;
interrupt-parent = <&UIC3>;
- interrupts = <0x0 0x4 /* SATA */
- 0x5 0x4>; /* AHBDMA */
+ interrupts = <0x0 0x4>;
+ dmas = <&DMA0 0 0 1>;
+ dma-names = "sata-dma";
};
POB0: opb {
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
