PL330: Add PL330 DMA controller driver
in [Kernel]
|
Prev: mm/vmalloc: Export purge_vmap_area_lazy()
Next: perf/scripts: tuple was set from long in both branches in python_process_event()
From: jassi brar on 25 Mar 2010 20:00 On Fri, Mar 26, 2010 at 8:12 AM, Dan Williams <dan.j.williams(a)intel.com> wrote: > On Thu, Mar 25, 2010 at 3:27 PM, jassi brar <jassisinghbrar(a)gmail.com> wrote: >> On Fri, Mar 26, 2010 at 12:13 AM, Dan Williams <dan.j.williams(a)intel.com> wrote: >>> It sounds like you just need to add an extension for the arch specific dma >>> api. >> I actually plan more than that. >> Apart from inefficient design, JoonYoung's driver has made some fatal >> assumptions >> about PL330, which will result in DMA aborts if used with SoCs that implement >> configuration of PL330 that is very different from Samsung SoCs' >> Of course, I address all such issues that I can think of, in my implementation. > > Ok, I'll rely on acked-by's from the interested parties once your > driver is out as I do not have a vested interest in this hardware, > just the dmaengine framework issues. Fair enough. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kyungmin Park on 25 Mar 2010 20:40 On Fri, Mar 26, 2010 at 8:59 AM, jassi brar <jassisinghbrar(a)gmail.com> wrote: > On Fri, Mar 26, 2010 at 8:12 AM, Dan Williams <dan.j.williams(a)intel.com> wrote: >> On Thu, Mar 25, 2010 at 3:27 PM, jassi brar <jassisinghbrar(a)gmail.com> wrote: >>> On Fri, Mar 26, 2010 at 12:13 AM, Dan Williams <dan.j.williams(a)intel.com> wrote: >>>> It sounds like you just need to add an extension for the arch specific dma >>>> api. >>> I actually plan more than that. >>> Apart from inefficient design, JoonYoung's driver has made some fatal >>> assumptions >>> about PL330, which will result in DMA aborts if used with SoCs that implement >>> configuration of PL330 that is very different from Samsung SoCs' Exactly what? We are already tested it our board and play the music well. What's condition DMA aborts are happen? >>> Of course, I address all such issues that I can think of, in my implementation. >> >> Ok, I'll rely on acked-by's from the interested parties once your >> driver is out as I do not have a vested interest in this hardware, >> just the dmaengine framework issues. > Fair enough. Thank you. As your previous mail, we can wait until this weekend. but If you don't post the your codes until this weekend. We assume that your works are not yet done so merge this patch first and then fix it if your words(DMA aborts issue) are right. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: jassi brar on 25 Mar 2010 20:50 On Fri, Mar 26, 2010 at 9:29 AM, Kyungmin Park <kyungmin.park(a)samsung.com> wrote: > On Fri, Mar 26, 2010 at 8:59 AM, jassi brar <jassisinghbrar(a)gmail.com> wrote: >> On Fri, Mar 26, 2010 at 8:12 AM, Dan Williams <dan.j.williams(a)intel.com> wrote: >>> On Thu, Mar 25, 2010 at 3:27 PM, jassi brar <jassisinghbrar(a)gmail.com> wrote: >>>> On Fri, Mar 26, 2010 at 12:13 AM, Dan Williams <dan.j.williams(a)intel.com> wrote: >>>>> It sounds like you just need to add an extension for the arch specific dma >>>>> api. >>>> I actually plan more than that. >>>> Apart from inefficient design, JoonYoung's driver has made some fatal >>>> assumptions >>>> about PL330, which will result in DMA aborts if used with SoCs that implement >>>> configuration of PL330 that is very different from Samsung SoCs' > Exactly what? We are already tested it our board and play the music well. > What's condition DMA aborts are happen? I didn't want to get into gory details, but it seems I need to explain ..... Please see my quick review to the original patch in this thread. We take the discussion there. >>>> Of course, I address all such issues that I can think of, in my implementation. >>> >>> Ok, I'll rely on acked-by's from the interested parties once your >>> driver is out as I do not have a vested interest in this hardware, >>> just the dmaengine framework issues. >> Fair enough. Thank you. > > As your previous mail, we can wait until this weekend. but If you > don't post the your codes until this weekend. > We assume that your works are not yet done so merge this patch first > and then fix it if your words(DMA aborts issue) are right. It's not upto you to give me any deadline. Not the "Until this weekend" one !!! I think only the word of the maintainers count. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joonyoung Shim on 25 Mar 2010 21:00 On 3/26/2010 7:27 AM, jassi brar wrote: > On Fri, Mar 26, 2010 at 12:13 AM, Dan Williams <dan.j.williams(a)intel.com> wrote: >> jassi brar wrote: >>>> Perhaps Joonyoung can simply port over the stuff >>>> you need to this driver if you show your code. >>> Having worked on Samsung SoCs(with PL330 DMAC) based products, I would be >>> _very_ surprised if any user found this implementation useful. >>> Let alone testing, this implementation can't even explain usability >>> for fast peripherals >>> with shallow FIFOs. I didn't give feedback for this patch because I am >>> not sure if this >>> is the right way to go at all. >> This is the wrong attitude. 혻If it were not for a simple oversight >> Joonyoung's driver would already be upstream for the past two kernel >> releases. 혻So you need to work together to improve that driver to >> incorporate what you need. > Nothing wrong in attitude here. > Giving feedback on the code only comes after one is convinced with the > overall approach taken. The last time I raised the PL330 driver issue, > most people were not enthusiastic with this drivers/dma/ approach. > I wasn't active mainline discussions when the driver was originally > submitted a few months ago. > And now my replies are not very 'polite' because theres a lot going on > in the background that people in public threads don't know about. > > >> It sounds like you just need to add an extension for the arch specific dma >> api. > I actually plan more than that. > Apart from inefficient design, JoonYoung's driver has made some fatal > assumptions > about PL330, which will result in DMA aborts if used with SoCs that implement > configuration of PL330 that is very different from Samsung SoCs' > Of course, I address all such issues that I can think of, in my implementation. > I can wait your implementation and wonder what is the issue also. I welcome you try other design and want better driver is committed at mainline kernel too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: jassi brar on 25 Mar 2010 21:10
On Fri, Mar 26, 2010 at 9:54 AM, Joonyoung Shim <jy0922.shim(a)samsung.com> wrote: > On 3/26/2010 7:27 AM, jassi brar wrote: >> On Fri, Mar 26, 2010 at 12:13 AM, Dan Williams <dan.j.williams(a)intel.com> wrote: >>> jassi brar wrote: >>>>> Perhaps Joonyoung can simply port over the stuff >>>>> you need to this driver if you show your code. >>>> Having worked on Samsung SoCs(with PL330 DMAC) based products, I would be >>>> _very_ surprised if any user found this implementation useful. >>>> Let alone testing, this implementation can't even explain usability >>>> for fast peripherals >>>> with shallow FIFOs. I didn't give feedback for this patch because I am >>>> not sure if this >>>> is the right way to go at all. >>> This is the wrong attitude. 혻If it were not for a simple oversight >>> Joonyoung's driver would already be upstream for the past two kernel >>> releases. 혻So you need to work together to improve that driver to >>> incorporate what you need. >> Nothing wrong in attitude here. >> Giving feedback on the code only comes after one is convinced with the >> overall approach taken. The last time I raised the PL330 driver issue, >> most people were not enthusiastic with this drivers/dma/ approach. >> I wasn't active mainline discussions when the driver was originally >> submitted a few months ago. >> And now my replies are not very 'polite' because theres a lot going on >> in the background that people in public threads don't know about. >> >> >>> It sounds like you just need to add an extension for the arch specific dma >>> api. >> I actually plan more than that. >> Apart from inefficient design, JoonYoung's driver has made some fatal >> assumptions >> about PL330, which will result in DMA aborts if used with SoCs that implement >> configuration of PL330 that is very different from Samsung SoCs' >> Of course, I address all such issues that I can think of, in my implementation. >> > > I can wait your implementation and wonder what is the issue also. > > I welcome you try other design and want better driver is committed at > mainline kernel too. Good to have you at last reply to my posts -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |