Am 29.01.2015, 21:45 Uhr, schrieb Maxime Ripard
<[email protected]>:
>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
>
Although it looks like Allwinner Co. is focusing entirely on software
for
chips newer than the A20, there are a lot of boards using this chip
because
of the attractive price. And that low price imho is only possible
because
Allwinner Co. does not really support the software which might easily
rise
cost to become too high.
Their strategy looks like: Make the HW design, deliver a (single) kernel
that can be used for Linux and Android, include that in the reference
design
and let the buyers of the chips do all the (expensive) rest. That
strategy
seems to work because the market for manufacturers for phones and
tablets is
so extremely fast that they too only deliver one software without
upgrades.
Now for the A20: Sinovoip manufactures several boards including the
original
BananaPi, Olimex and others are in the same boat. So I think it would be
worth the effort to improve the kernel for that chip.
It has interesting specs for a lot of applications including small home
servers and is one of the few chips offering SATA and GHZ Ethernet at
that
low price.
The latest sunxi kernels perfectly work for Ethernet and SATA (Thanks to
everybody who made this happen!!). I do not know enough about the
delicate
details of Linux kernels, but would be prepared to contribute by what
ever
needs testing on that platform.
