On Sat, Jan 31, 2015 at 09:49:36AM +0100, Irgendeiner wrote: > 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.
A good first step would be to test whatever boards you have on a regular basis (with the current -rc, and ideally linux-next), and making sure that everything still works as it used to. And if not, report it. This would be very valuable, and doesn't really require any kernel knowledge beside compiling a kernel on your own. > My personal goal is to have a sunxi kernel with Debian Jessie, which > lets me bring up an additional point: > > In some may be not too distant future, the newest sunxi kernel will no > longer be compatible with Jessie. What are your opinions and plans to make > it possible to use new kernels with then 'old' Jessie? I'm not aware of that issue. Would you care to expand a bit? 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
