On Thu, Jan 29, 2015 at 3:45 PM, Maxime Ripard <[email protected]> wrote: > On Thu, Jan 29, 2015 at 09:37:25AM -0500, Stefan Monnier wrote: >> >> > You may also need some DMA changes. I've got a patch for this but have >> >> > never tested it. >> >> I really would like to keep using my little server for another 5 years >> >> or more, and I don't see that happening if it doesn't get merged >> >> into mainline. >> > You absolutely need DMA for a server? Really? >> >> Home jukebox server, yes: the audio out is rather handy when playing >> music ;-) > > Buying a USB DAC is also an option for now then. > >> >> IIUC the main first step is to fix the DMA code so as to allow >> >> concurrent DMA. Where in the code is this limitation to "only one >> >> DMA at a time"? >> > It's not really a limitation of the number of clients, but the number >> > of concurrent transfers, and it actually works like that in hardware, >> > it's just re-emulated in software too. >> >> I thought that the hardware did support multiple (8?) concurrent >> transfers (and that the code does not make use of it because of >> a misunderstanding of the docs). > > IIRC, the hardware a 8 channels, and follows a round-robin between the > 8. So you can program 8 in parallel, but only one will be actually > transfering at the same time.
Allwinner corrected the translation error on this. All DMA on any common CPU only does one transfer at a time -- there's only one bus. This hardware does a bus memory burst (8 or 16 bytes) and then round robins to the next ready DMA. All common DMA hardware works like that. What Sugar said what that this is standard DMA hardware with no special sauce. It is the normal burst round-robin DMA found on all ARM CPUs. This single transfer thing was a translation error in the documentation. > > And what Emilio did was always use a single channel (still IIRC), > effectively implementing some kind of scheduler in software. > >> In any case, if someone could help me get started on fixing this >> would be very welcome. I'm not a kernel hacker, but I'm willing to >> try and learn. > > I'd start looking what the issue_pending function does. It's the > function that's supposed to push the transfer descriptor to the > hardware. > >> >> PS: Looking at recent coding activity, it seems there's more interest in >> >> adding basic support for new SoCs than for improving support for "old" >> >> ones. So we end up with basic support for lots of devices but good >> >> support for none :-( >> > These days, we're three of us doing some work, including fixing >> > existing bugs, maintaining the code, etc. >> >> I'm sorry I sounded like the usual whiner. I really do appreciate all >> the work people put into this (especially since the 3.4 kernel was >> unstable on my machine, whereas the mainline is pretty solid) and I'm >> well aware of the usual lack of manpower. >> >> > That, and I'm not sure that focusing on a five years old SoCs while >> > ignoring any new SoC is the right policy. linux-sunxi did that with >> > the A31, look at where it is now. >> >> I don't know for sure what is the right policy either, of course. >> But I don't find it obvious that, given the lack of resources, trying to >> expand the breadth of support rather than the depth of support is >> necessarily a good idea either, if the result is "more boards that can >> barely boot". > > I wouldn't describe it as barely boot. > > But there's also two things to consider: > - People with A31/A23/A80 have no other alternative than the > Allwinner kernel. Do we really want to leave these users out in > the cold? I don't. > - Adding a new SoC support is pretty cheap > >> Maybe the best policy should aim at bringing more people on board. > > If you have a good strategy for that, I'm all ears. > > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl [email protected] -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
