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.
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.
signature.asc
Description: Digital signature
