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
