Re: [PATCH] ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854
On Sun, Oct 19, 2014 at 11:51 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Does that work for things like allnoconfig and randconfig? I guess people /could/ seed those appropriately, but that seems to be something that Olof wants to avoid doing. You can force particular config options for those, using something like export KCONFIG_ALLCONFIG=custom.config and filling the custom config file with the required config setting. So the downside is that you do need to have this custom support to seed particular things, but yes, it's doable, and it only requires a one-time setup with an environment variable, so it doesn't need changes to the actual testing infrastructure. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fbdev changes for 3.8
On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Linus, Florian, the fbdev maintainer, has been very busy lately, so I offered to send the pull request for fbdev for this merge window. Pulled. However, with this I get the Kconfig question OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW) which doesn't make a whole lot of sense on x86-64, unless there's something about OMAP2 that I don't know. So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at least ARM. Because showing it to anybody else seems insane. Same goes for FB_OMAP2 for that matter. I realize that it's likely nice to get compile testing for this on x86-64 too, but if that's the intent, we need to think about it some more. I don't think it's good to ask actual normal users questions like this just for compile coverage. Hmm? Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tty: omap-serial: fix boot hang by converting to use a threaded IRQ handler (was Re: [PATCH] irq: always set IRQF_ONESHOT if no primary handler is specified)
On Tue, Aug 23, 2011 at 1:57 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Mon, 22 Aug 2011 23:10:21 -0600 (MDT)
Paul Walmsley p...@pwsan.com wrote:
Convert the omap-serial hardirq handler to a threaded IRQ handler. Without
this patch, OMAP boards which use the on-board OMAP UARTs and the
omap-serial driver will not boot to userspace after commit
f3637a5f2e2eb391ff5757bc83fb5de8f9726464 (irq: Always set IRQF_ONESHOT if
no primary handler is specified). Enabling CONFIG_DEBUG_SHIRQ reveals
'IRQ handler type mismatch' errors:
There are multiple other drivers reporting all these problems - the
faulty irq change should be reverted at this point not the drivers
fiddled with.
Agreed. It's too late to try to fix random drivers.
The real issue seems to be that clue:
Enabling CONFIG_DEBUG_SHIRQ reveals 'IRQ handler type mismatch' errors
iow, we have a shared irq, and forcing the IRQF_ONESHOT bit is
resulting in those shared interrupts now having different values of
IRQF_ONESHOT, so this test triggers:
/*
* Can't share interrupts unless both agree to and are
* the same type (level, edge, polarity). So both flag
* fields must have IRQF_SHARED set and the bits which
* set the trigger type must match. Also all must
* agree on ONESHOT.
*/
if (!((old-flags new-flags) IRQF_SHARED) ||
((old-flags ^ new-flags) IRQF_TRIGGER_MASK) ||
((old-flags ^ new-flags) IRQF_ONESHOT)) {
old_name = old-name;
goto mismatch;
}
and the irq isn't installed at all (setup_irq returns with EBUSY).
So the commit that caused this problem was simply bogus. The commit log says
Since it is required for those users and
there is no difference for others it makes sense to add this flag
unconditionally.
but the there is no difference for others seems to be total crap,
exactly because it results in this IRQF mismatch.
So I think that commit should just be reverted. Thomas?
Linus
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, Apr 1, 2011 at 8:55 AM, Arnd Bergmann a...@arndb.de wrote:
Well, except that because of point 7, device trees are still inferior to
having correct and complete information in hardware.
Oh, absolutely.
If you have discoverable hardware, use it.
But by discoverable hardware I mean something like PCI config
cycles. IOW, real hardware features. Not some code like
if (board_signature_is(xyz)) {
...
that just maps some _other_ hardware knowledge (reading a SoC ID or
something) into an unrelated thing (I know this SoC has these bits of
hardware).
So devicetree should never override actual hardware tells me it
exists here. But you might well have a mapping from SoC ID's to a
compiled-in devicetree thing (this is largely what POWER does, iirc).
Linus
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 9:45 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: I think you're not entirely correct - have a look at Linus' message where there's a comparison of the size of arch/arm with other architectures, and you'll find that it is partly about size of source code. It definitely is partly about code size, although I tend to use it as an easy illustration of the issues rather than anything deeper than that. The code size is a symptom of the problem. The deeper problem is the crazy arm hardware infrastructure. We can't do much about that, but it does mean that I _do_ think we need to take approaches that aren't necessary when that deeper problem doesn't exist. For example, I don't think it's problematic that we have various drivers that do their own gpio thing. Why? Because those things are generally part of a bigger chip/driver that is discoverable, and they don't tend to proliferate in various crazy random amounts - nor do they tend to impact anything else. Nor does it look like that is going to explode in the future any more than any normal driver work is exploding. Or look at the irq controllers we have on most other architectures. x86 has several of them too, and it's annoying. But it's several, not hundreds, and again, it's not exploding or looking like it will be a major pain to support. I doubt Thomas enjoyed having to work with the legacy controllers, but I also doubt he had huge problems on the x86 side. What does that mean? _I_ think it means that ARM platform managers need to worry about things that other platform managers don't necessarily need to worry about as much. Things that works for others will _not_ work for ARM, because the platforms don't have the same kind of sticking power. Other architectures just don't have the same kinds of issues, so they don't need to worry about them. An right now just from the kinds of pulls I do, I see all these ARM platform maintainers doing their own thing, and adding new platforms all the time (with a _very_ occasional removal of some old platform support just because it was a prototype that never went anywhere at all). What I'm _not_ seeing is a lot of cross-platform maintenance or sense of people trying to reign things in and look for solutions to the proliferation of random stupid and mindless platform code. Even _within_ platforms, I see conflicts like the crazy clock files - and between platforms I don't see any conflicts for the simple reason that people are just duplicating crap and adding more and more of these mindless things. A new platform? Let's just create a new directory, fill it with all the same template crud, and then tweak the code to match. It's simple, but it's not maintainable. So it's not the size PER SE. But the size is a damn easy first-order we have a problem sign. ARM is clearly an important architecture, but that doesn't excuse the crazy bloating. x86 had this too - the whole mindless duplication of x86-64. It got merged. It required cleanups, it required effort, it required time. And it required some abstractions. x86 never had much of a _platform_ duplication, and the different platforms that did exist were so clearly secondary that they never rated any first-class code: they always knew that they were a second-class citizen and had to work within the framework of trying to hook into the main PC platform code. Power did a lot of platform unification, despite having much less of a problem than ARM to begin with. The less of a problem made it easier to do, but also less critical. And I don't think it's realistic to convert all ARM platforms in one go, and nobody should even plan anything like that. But I _do_ think that some of the major platforms (like omap) should seriously just say we can't continue doing this, and look at converting at least everything they do to something like devicetree (NOT some omap-specific infrastructure!) rather than lots of explicit code. Done right, that hopefully then shows other platforms how to do the same, and get the ball rolling. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 10:56 AM, Nicolas Pitre n...@fluxnic.net wrote: So... Is there missed opportunity for better code reuse here? Most probably. Is all that code the result of misabstracted and duplicated code? Certainly not. Let's just presume that half of that code is genuine crap and the other half is simply the result of new hardware for which there is no existing model to fit it in. Even then, do we have 5 times the reviewer bandwidth to properly review all that code compared to X86? Absolutely not, not even close. That's an odd assumption. And it's followed by a total red herring that doesn't even make any sense. And then your conclusion seems to be that ARM could never have the same quality anyway, because of the whole lack of review issue is fundamental. And from there you seem to go on to think that there are no major problems, and things are good enough! If prominent people looking at this from the side line continue bashing at those who are both feet in the mud trying to contain the flood rather than actually helping then nothing will change. The reason nothing seems to be changing is that you don't seem to think it's even WORTH fixing. I really don't understand your arguments. They seem to boil down to the same thing that always happens in the embedded world, and why most of the hardware and software is crap: people don't think further than their own small project. It's why embedded OS's have always been crap, and it's why Linux is becomign so important to ARM - exactly because the embedded world (both software and hardware) always just look at their own issue, and say hey, this is working for me right now, so I won't bother to try to solve the bigger issues, because it's not worth my time. To hammer that in: ... And the fact is that _users_ of the ARM kernel are not complaining. Things are far from being perfect, but so far things have been good enough for the majority of the people involved, and improvements are constantly being worked on with the men power available. You really don't seem to care about how Thomas was complaining about the whole maintenance issue. As he was trying to clean up irq handling, the pure flow of more crap just made it hard to ever catch up. THAT is the kind of maintenance problem where I go This is a big problem. But for some individual board user or the code-monkey who creates yet another board description, this isn't a problem. Because he's looking at a single kernel and a single board at a time, and seldom cares about anything else. But guess what? That really _is_ a problem. And it's likely to be a bigger problem in the future. Look at how we're actually starting to see vendors who are making ARM into more of a real platform, rather than a succession of one-off embedded boards, and think about what that actually will entail. I'm talking about things like ASUS getting their feet wet making netbooks with ARM. Things like that have been promised for the last several years now, and so far it's been a total failure. And it's going to CONTINUE to be a failure, unless the ARM platform mess can be sorted out. Why? Think of the Ubuntu's etc of the world. If you can't make half-way generic install images, you can't have a reasonably generic distribution. And if you don't have that, then what happens to your developer situation? Most sane people won't touch it with a ten-foot pole, because the bother is simply not worth their time. So the current embedded mindset of hey, it's working for all these individual people is just broken. It's broken for multiple reasons. It's broken because it makes it much harder to do top-level maintenance (but the low-level guys don't care), and it's broken because it results in insane fragmentation where it basically is never an option to support anything but one - or a couple - particular device. The ARM -core- situation is simple, and those high-level people can (and do) say that they'll just support ARM7 and screw all the other cores. But the platform problem is real. And it does need some solution, because continuing to just do the same thing really does mean that some new things simply cannot be done. And the fact that it's been good enough in the past when every single board was always just a one-off and had nothing to do with other boards does _not_ mean that it's going to continue to be good enough. So the _good_ news is that all the high-end ARM's are largely consolidating anyway, and when we're talking Cortex-A9 class hardware, there generally aren't millions of SoC's. And I'm hoping the hardware people are actually aware of this (presumably because their customers are starting to push back against pointless hw churn too) and clearly some manufacturers are trying to -create- platforms like OMAP that try to have lots of shared characteristics (and then screw up a lot of the details, but whatever). But I still do think that on the software side, people need to stop doing the whole
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 12:25 PM, Nicolas Pitre n...@fluxnic.net wrote: So we need help! If core kernel people could get off their X86 stool and get down in the ARM mud to help sort out this mess that would be really nice (thanks tglx). Until then all that the few of us can do is to contain the flood and hope for the best, and so far things being as they are have still worked surprisingly well in practice for users. If compensation is a concern then I think Linaro might be able to arrange something. The thing is, maintainers don't scale. The only way to get quality code is to try to improve the quality from the leaf nodes, because otherwise you'll always end up playing catch-up. You'll get new bad code faster than you can clean it up. I've told people this before, and I'll tell it again: when I flame submaintainers, they should try to push the pain down. I'm not really asking those submaintainers to clean up all the stuff they are getting: I'm basically asking people to say no, or at least push back a lot, and argue with the people who send you code. Tell them what you don't like about the code, and tell them that you can't take it any more. And we can't count on vendor people doing this work. They are all busy porting the kernel to their next SOC version so they can win the next big Android hardware design, and doing so with our kernel quality standards is already quite a struggle for them. This really isn't the argument. The argument should be that if they want their code up-stream, they need to do a good job. If they don't, why should you take it at all? What is going on at the moment is some effort to introduce DT support to ARM. The core support is there, but that is useless until platform code is moved to it, and corresponding work is put into bootloaders, etc. That is progressing... slowly. How about not moving platform code TO it, but at least saying that you won't accept new platform code that doesn't use it? When somebody sends you a new platform, just say no if it's another copy-paste job or another add yet another #ifdef or conditional to a messy driver. But we also need some slack wrt number of lines changed. An increased consolidation effort will create more churn not less, at least for a while. The OMAP clock merge conflict was the result of some cleanup which will make further consolidation easier. Umm. The whole number of lines of code thing has become a total red herring. THAT IS NOT WHY I STARTED TO COMPLAIN! The reason I point out the number of lines of code is because it's one of the more obvious _symptoms_ of the problem. But trust me, if you start doing a better job at platform code, I won't be complaining when I get lots of deleted code, or when I start getting devicetree descriptions instead of new drivers. So number of lines of code and massive churn is a problem, but look at how I'm not complaining about the drivers/ subdirectory, which is still the bulk of all lines in the kernel by far. I may complain about particular subsystems in drivers (gpu..) for other reasons, but it's not lines of code per se. In the case of ARM, the reason I point out the size of the arch/arm is because it's illustrative of just how _different_ ARM is from the other architectures. And those differences are pretty much all about the board/platform issues. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31, 2011 at 1:05 PM, Linus Torvalds torva...@linux-foundation.org wrote: Umm. The whole number of lines of code thing has become a total red herring. THAT IS NOT WHY I STARTED TO COMPLAIN! The reason I point out the number of lines of code is because it's one of the more obvious _symptoms_ of the problem. But trust me, if you start doing a better job at platform code, I won't be complaining when I get lots of deleted code, or when I start getting devicetree descriptions instead of new drivers. So if you don't like lines of code, how about just number of files touched. This is Thomas this merge window. Remember: he's traditionally doing timers and interrupts and stuff. Do: git log --author=tglx v2.6.38.. --oneline --numstat | cut -f3- | grep -v ' ' | cut -d/ -f1-2 | sort | uniq -c | sort -n | tail and see another example of arm standing out (ok, so kernel/irq also stands out in this case, but you'd kind of _expect_ that, when the whole series is about irq controllers, wouldn't you?) And no, mips doesn't look so hot either. Anyway, the point is, there are many ways to show the whole arm is a maintenance problem issue. Don't get too hung up about number of lines changed. It's just the simplest kind of thing where the tools give answers very quickly without the above kinds of games. Btw, the reason why the subject line on this rant is what it is, is that during this merge window, arm was also one of the more annoying to merge. And NO, that does NOT mean that I want you guys to merge things behind my back just to hide the problem. I'm just saying that it's another facet of this whole issue. Not that I can't do merges, but that ARM simply ends up having these issues that others don't. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, Mar 30, 2011 at 10:06 AM, Arnd Bergmann a...@arndb.de wrote: I'm still new to the ARM world, but I think one real problem is the way that all platforms have their own trees with a very flat hierarchy -- a lot of people directly ask Linus to pull their trees, and the main way to sort out conflicts is linux-next. The number of platforms in the ARM arch is still increasing, so I assume that this only gets worse. As far as I'm concerned, the biggest issuee is that some of the ARM crap is just CRAP. It's idiotic tables that get updated by multiple people, and in totally nonsensical ways. When I see conflicts in those damn clock-data files, I just go mental. Those files are an abomination. Why the hell is the clock-data for fifty (number taken out of my ass) different clocking rules in one array? And why do we have eight different files of that kind of crap for omap2? THAT is an example of something that is totally and utterly screwed up. Those kinds of random board-level detail files abound in the ARM tree. They should either be in a per-board file, or (much better) the ARM people should have standardized this ten f*cking years ago, and put it in a bootloader or something that just initializes the crap so that the kernel doesn't have to have random tables like that at all. ARM right now i a nightmare, and most of it is because ARM hardware manufacturers are morons. But the way the ARM tree is then laid out has made that even more painful, and the decision to put all the crazy board details in the kernel tables instead of trying to have a per-board boot loader that fills in the details is just crazy. Look at the dirstat for arch/ in just the current merge window (cut-off at 5% just to not get too much): [torvalds@i5 linux]$ git diff -C --dirstat=5 --cumulative v2.6.38.. arch 14.0% arch/arm/mach-omap2/ 5.8% arch/arm/plat-mxc/include/mach/ 6.3% arch/arm/plat-mxc/ 57.1% arch/arm/ 5.4% arch/m68k/ 9.6% arch/unicore32/ 6.9% arch/x86/ 100.0% arch/ almost *SIXTY* percent of all arch updates were to ARM code. And that's despite the fact that one of those architectures (unicore32) is a totally new architecture, and despite m68k having gone through a first-level unification of nommu and mmu code! And was this just a fluke? No. Doing the same for 2.3.37..38 gives 58.3% for arch/arm (and in that release we had a blackfin unification effort, otherwise arm would have been an even bigger percentage). That's ridiculous. It's entirely due to the whole f*cked-up arm ecosystem. Something needs to be done. A small part is to make sure the source code is more hierarchical, so that we don't have those crazy shared data-files that are ugly as hell and get conflicts because different boards all think they need to care. But the larger problem is that somebody really REALLY needs to think about how to get those crazy board details out of the kernel entirely. Having per-board drivers for real hardware is sane - having to have per-board detail files for clock chips is just crazy. Split off that thing a Linux ARM second-stage bootloader project that has the per-board tables or something. Don't pollute the main kernel with crazy details like this. Because as far as I can tell, most of that board support really is about crazy details that the kernel shouldn't even care about. Come up with a table that describes them, have one common parsing routine, and push the table into a bootloader. And get rid of having to add a board file for every crazy random piece of hardware that nobody really cares about. Or something. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre n...@fluxnic.net wrote: If in your mind competitors == morons then you might be right. There's a difference between competition and do things differently just to be difficult. Trying to rely on bootloaders doing things right is like saying that x86 should always rely on the BIOS doing things right. No. Not at all. The problem with firmware/BIOS is that it's set in stone and closed-source. I'm suggesting splitting out the crazy part into a separate project that does this. Open-source. Like a mini-kernel. Because the thing is, the main kernel doesn't care, and _shouldn't_ care. Those board files are just noise. The long-term situation should be that you should be able to have ONE binary kernel just work. That's where we are on x86. Really. Without that kind of long-term view, where do you think ARM is going to be in five years? almost *SIXTY* percent of all arch updates were to ARM code. Absolutely not! You have 14% going to OMAP code which happens to be under arch/arm/ but there is nothing ARM specific in there. If OMAP was using a PPC or a MIPS core then you'd have the same result except under arch/powerpc or arch/mips. There is very little in terms of ARM specific peculiarities under arch/arm/mach-omap2/ in fact. But that's my point - the problem is all the crazy board crap. I've never claimed that this is about the ARM cpu (which has it's own issues, but that's a separate rant entirely). It's about the broken infrastructure. Now, some of it is quite understandable - ie real drivers for real hardware. But a _lot_ of it seems to be just descriptor tables, and I'm getting the very strong feeling that ARM people aren't even _trying_ to make it sane, and trying to standardize things, or trying to aim for the whole notion of one kernel image, with much more hw description done elsewhere. Sure, you'll fundamentally always need several images (due to the afore-mentioned crazy CPU architecture flaws - arm6 vs arm7 vs armxyz), but I'm looking at the future, and arch/arm will get _totally_ unmaintainable unless you guys have a plan for getting out of the crazy hole you are in now. arch/arm is already about 3x the size of arch/x86. And it's pretty much all the crazy infrastructure afaik. timer chips, irq chips, gpio differences - crap like that. And the fact that you don't even seem to UNDERSTAND the problem, and think that it's ok, and that continued future explosion of this is all fine makes me even more nervous. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, Mar 30, 2011 at 2:44 PM, Tony Lindgren t...@atomide.com wrote: That's ridiculous. It's entirely due to the whole f*cked-up arm ecosystem. Yeh there's no BIOS and there are no scannable busses.. Which leads to huge amount of data patches that show up in the diffstat. Yes. And due to all the traditional embedded models, there's no historical platform model at all, unlike pretty much all other architectures. Sure, other architectures often have more than a single platform, but there's usually at least a couple of standard ways of doing things, and defined interfaces to figure out at least most of the big issues. The embedded world has always been painfully different, and arm is just the most successful entry (by far) in that world. So as a result, it's not just no scannable busses, it's pretty much _everything_ that you can't take for granted. The clock chip details and crazy irq controllers are a symptom. Now, I'm not a huge fan of ACPI and always point out how firmware people inevitably get something wrong, but the _real_ reason I think ACPI was such a broken idea is that it was basically used as an excuse to break the PC platform notion - the fundamental problem with ACPI was that it was a way to avoid making platform decisions, and let all the hw crazies make bad decisions and then fix them up in ACPI. So I always felt that Intel should just have documented the hardware standard instead, and pushed that as the platform (which, in all honesty, Intel has done for a lot of very successful things - PCI, AHCI, USB etc etc are all examples of Intel creating those kinds of hardware platform standards). ACPI allowed (and still allows) Sony and others to make crazy ad-hoc decisions about some random motherboard device, and just encouranges _bad_ hardware without enumeration or good high-level rules. But for ARM, I suspect even ACPI would actually be an improvement. Because on ARM, the crazy non-platform hw people already happened, and took over the insane asylum. So having a complicated description language with an interpreter wouldn't be worse than what we already do there. I'm only half kidding. I wouldn't wish for ACPI even on ARM. But.. Anyways, let's plan on kicking out per-SoC and per-board data from the kernel and get it from the bootloader via device tree in the long run. Most of the data is already separate from the code, so it should not be that hard to do, just takes some time. This is basically my hope for the future. I just think that ARM people should be very very aggressive about it, because the longer it isn't done, the more crud there will be to convert. I bet it will be painful to do. But it will be even more painful to _not_ do it, and then five years from now realize that it should have been done ten years ago. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, Mar 30, 2011 at 5:15 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: In this merge window, I deleted at least 6000 lines from arch/arm, and by quoting diffstat percentages, you're using that against the ARM community. Why did I bother (that's not a question). Umm. The actual stats are still: 1349 files changed, 62230 insertions(+), 33993 deletions(-) which is sad. And the end result speaks for itself: this is lines per architecture: ... 124022 total arch/sh 124418 total arch/sparc 181997 total arch/m68k 246717 total arch/mips 254785 total arch/x86 370912 total arch/powerpc 732732 total arch/arm notice how ARM ends up being in a class of its own. This is a PROBLEM. And ARM fanbois can say oh, but arm is special all they want, but they need to realize that the lack of common platform for ARM is a real major issue. It's not a feature, and I'm sorry, but anybody who calls x86 peanuts is a moron and should be ashamed of himself. Instead of trying to feel superior, those people should feel like pariah. The fact that x86 has a platform, and people have cared about compatibility, and actually gets things to work with less code is a good thing. I know ARM people who think that x86 is an ugly architecture. But the fact is, of all the architectures out there, ARM right now is the ugliest BY FAR. Exactly because of people who don't seem to understand that this kind of crap is a problem. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, Mar 30, 2011 at 6:15 PM, Bill Gatliff b...@billgatliff.com wrote: I'm not sure this metric is completely fair to ARM. If you want to level the field, I think you have to divide each result by the number of SoC's But that's the problem with ARM. Hardware companies that do one-off stuff, with no sense of compatibility. And calling it an opportunity is just stupid. There's nothing good about causing extra work just because ARM hasn't had the sense to standardize on one (or a couple) of interrupt controllers etc. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, Mar 30, 2011 at 6:44 PM, Bill Gatliff b...@billgatliff.com wrote: In the meantime, we have to live with the chips that exist and the ones coming down the pipe. Until ARM and all their licensees start consulting us on such matters, we'll just have to find a way to deal with what we're given after the fact. Yes. But: (a) we don't have to be stupid and think it's a good design and an opportunity like you do. and (b) the kernel source code doesn't have to be the mess of code that it is. Those things should be abstracted out somehow (and yes, devicetree is hopefully one way) I really don't understand why you seem to be arguing against trying to fix a real problem, and why you also seem to be arguing that the messy ARM situation is somehow good. I find your attitude about the lack of platform being good be to incomprehensibly stupid. There is absolutely _no_ advantage to anybody from the crazy arm fragmentation. I know, I know, a lot of companies make money supporting the whole crazy mess. I guess that can make people confused and think that being messy is good, and could be seen as an advantage. But most embedded companies seem to have realized that they should move up the stack, rather than worry about some crazy GPIO or stupid driver details. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, Mar 30, 2011 at 7:20 PM, Bill Gatliff b...@billgatliff.com wrote: If it isn't opportunity, then you must be arguing that we shouldn't add any new ARM SoC support to the kernel. Is that what you are saying? What I'm saying is that we should not be adding ANY MINDLESS BOARD DRIVERS for ARM. Because they don't work. Most of them are totally unmaintainable CRAP in the long run. They are extra code that actually have negative worth. It shouldn't be in the kernel at all. So let's take a really simple example of this kind of crap. Do this: git ls-files arch/arm/ | grep gpio and cry. That's 145 files in the arm directory that are some kind of crazy gpio support. Now, we have gpio drivers in other parts of the kernel too, but ARM is at the point where it's just crazy. And most GPIO drivers I've ever seen are actually basically turn this bit on or off in this register to turn it into an Input or Output along with read/write this other bit to actually see/set the value. Repeat that for 'nr' bits, where 'nr' is just some small value, usually in single digits. Now, not all of them are that, by all means, and the details are often slightly different. Sometimes the read register is the same as the write register, sometimes it isn't. Sometimes you have a clear register and a set register instead of a register you write the value to. And I haven't checked what those 145 files do, but I bet a _lot_ of them could be described by having a single generic gpio driver, and then just using devicetree to give that common driver a few values to describe where the IO ports are, which bits they are, and which type of gpio it is. And then when you have another ARM SoC, instead of writing yet another mindless board driver for the gpio's on it, just add the nr entries for the GPIO's to the device tree. NOT A SINGLE LINE OF CODE. Yes, yes, there are always exceptions. Many GPIO's are actually behind some i2c bus or something. Others can do pulsing or are just generally more complex than an array of single bits. So I'm sure we couldn't replace all those 145 gpio files under arch/arm with a single driver and some devicetree entries, but maybe half of them match the simple pattern. I bet the SoC case it's more than half, it would be silly to do i2c on an SoC. But I dunno. I really didn't look. PowerPC does exactly the above, btw. So I'm not just talking about some magical theoretical thing. I seriously think every ARM person who has ever written any of those gpio files should look at powerpc. Now, I suspect that most powerpc SoC's tend to share more IP blocks than the crazy ARM situation, but even so, please just check it out. Check out the device tree files (*.dts) and do that same git ls-files arch/arm/ | grep gpio except do it on powerpc. See the difference? The powerpc people even wrote documentation about the thing, which is just above and beyond reasonable. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 17, 2011 at 11:30 AM, Tony Lindgren t...@atomide.com wrote: Please pull omap changes for this merge window from: Gaah. Guys, this whole ARM thing is a f*cking pain in the ass. You need to stop stepping on each others toes. There is no way that your changes to those crazy clock-data files should constantly result in those annoying conflicts, just because different people in different ARM trees do some masturbatory renaming of some random device. Seriously. That usb_musb_init() thing in arch/arm/mach-omap2/usb-musb.c also seems to be totally insane. I wonder what kind of insanity I'm missing just because I don't happen to see the merge conflicts, just because people were lucky enough to happen to not touch the same file within a few lines. Somebody needs to get a grip in the ARM community. I do want to do these merges, just to see how screwed up things are, but guys, this is just ridiculous. The pure amount of crazy churn is annoying in itself, but when I then get these independent pull requests from four different people, and they touch the same files, that indicates that something is wrong. And stop the crazy renaming already! Just leave it off. Don't rename boards and drivers just because, at least not when there clearly are clashes. There's no point. I'm not even talking about the file renames (which happened and can also make it fun to try to resolve the conflicts when somebody else then makes _other_ changes), but about the stupid change human-readable names in board files just to annoy whoever needs to merge the crap. Somebody in the ARM community really needs to step up and tell people to stop dicking around. (I'm replying to the omap pull request, because that's the one I did last, but I don't know who to blame. I don't care. It really doesn't matter. I realize thar ARM vendors do crazy shit and haven't figured out this whole platform thing yet, but you guys need to push back on the people sending you crap). Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 17, 2011 at 11:30 AM, Tony Lindgren t...@atomide.com wrote: Please pull omap changes for this merge window from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus Btw, that generic hardware spinlock thing needs to be hidden from sane people and architectures that don't need it. Make platforms that need it select it or something. It looks like nobody but an OMAP4 could _possibly_ ever want to answer 'y' to that question, SO DON'T ASK IT! Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/4] perf: clean-up of power events API
On Sat, Oct 9, 2010 at 1:14 AM, Pierre Tardy tar...@gmail.com wrote: On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar mi...@elte.hu wrote: The thing is, Arjan is 100% right that a library for this is not a 'solution', it's an unnecessary complication. Yes. sounds like overengineering. I also want to remind people that backwards compatibility should always absolutely be the #1 priority. Using libraries to hide differences is a totally moronic thing to do, because if you can do a compatibility library with good interfaces, then damn it, the kernel interface should already _be_ that good interface. And no, even if you interact purely with open source programs, the backwards compatibility requirement doesn't go away. It's a damn pain in the ass to have to recompile, and it means that you have a much harder time mixing and matching, and just updating the kernel on top of a standard distribution. So changing kernel interfaces that get exported to user space is always a disaster. Anybody who _designs_ for that kind of disaster shouldn't be participating in kernel development, because they've shown themselves to be unable to understand the pain and suffering. Yes, we do it. Sometimes we change interfaces because not changing them is too damn painful. But it should absolutely not be the design model. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/4] perf: clean-up of power events API
On Sat, Oct 9, 2010 at 2:15 PM, Steven Rostedt rost...@goodmis.org wrote: The difference here compared to all other user interfaces, is that this interface has the sole purpose of showing what is happening inside the kernel. Bogus and dishonest argument. Listen to yourself, and read this thread again. The thread was about doing some kind of open-source library to allow non-open-source access to these events, and keeping backwards compatibility in user space. In fact, that is what you yourself said. So you claimed it could be backwards-compatible. If that's the case, then there is no excuse for not being so in the kernel. You can't have it both ways. Stop the f*cking waffling. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote: But do you believe that input should be the primary residence for the devices when they are only _sometimes_ used as input devices? Or it would make sense to employ a converter from XXX to input (either purely in-kernel or userspace over uinput)? Umm... You've brought that up before as an objection, but what _is_ that other model that you would convert from? IOW what *is* that XXX that you talk about? So I think accelerometers etc should be seen as input devices for the simple reason that (a) They really *are* input devices in all the most common cases. If you have a phone with an accelerometer, it really is used as an input device quite like a joystick. The fact that there are specialized and rare cases where people may have some fancier accelerometer that isn't necessarily seen that way, and where it is used for some fancy scientific experiment or whatever doesn't change this in *any* way. The common case that almost everybody cares about - and that is getting more common - is the simple and obvious input case. How is a Wii accelerometer in any way different from a joystick? How is a phone accelerometer any different from one? The answer is clear: they aren't different! So it makes 100% sense to expose them under the same subsystem. (b) You cannot even name your XXX thing. It clearly makes sense (at least within Tue context of a driver for some embedded phone chip) to see it as an input device. And nothing else comes to mind. You'd have to expose it as some random character device and then everybody would just have to make it emulate an input device in user space anyway. What's the point of that? None. That's what the point is. So I really don't understand why you're fighting the input device angle. It makes sense as an input device. It does NOT make sense as anything else. Really - what else could a phone accelerometer (or GPS device, for that matter) really be? It very much is about user input - even if it isn't a keyboard. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote: That is why I started taking accelerometers in. But I am concerned that taking accelerometers (which indeed are most often input devices) will lead people to try and use the same for temperature, ALS and other sensors that are more often used in industrial process controls. You're just being silly. Nobody writes a driver for a temperature sensor or ambient light sensor. They write a driver for a specific *chip* that is used in cellphones etc, and that happens to have an ambient light and temperature sensor on it. And in that context, it really does make sense to see it as an input driver. And the fact that there are industrial uses for ALS sensors that aren't necessarily at all interested on the input layer should not matter at all. So don't bring up ALS isn't always input because within the context of a driver for some highly integrated cellphone model, it really IS input, and there is no ambiguity at all. So your sometimes it is, and sometimes it isn't argument is bogus. The ambiguity simply doesn't exist when seen in context. (or GPS device, for that matter) really be? But why GPS should be input device? It has nothing to do with user input. What? OF COURSE it is an input driver. It's the user moving the device around. It's EXACTLY the same thing as an accelerometer in that respect. Sure, it's a bit less precise and measures movement wrt some external frame, but technically they are almost exactly the same. If you se doing a navigation app, the accelerometer, the compass and the GPS are all equally (but differently) important. Again - it's not a user touching buttons. But it IS a user moving around. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
2010/7/12 Uwe Kleine-König u.kleine-koe...@pengutronix.de: As you havn't replied up to now I wonder if that just means that you still plan to remove all defconfig files or if you are just busy doing other things. The reason I haven't replied is that (a) I don't think this really solves the issue, in that the resulting files still aren't human-readable, and as such I suspect it doesn't solve the problem in the long run: people will continue to just run make config and then copy the resulting .config file as a defconfig file. and (b) even if ARM were to go this way, and run the scripts to minimize the defconfig files, that's not something _I_ would do. If I get tired of seeing the insane pull requests where 90% of the crap is just defconfig noise, then _my_ solution will be to remove the crap because I simply am never going to be the person who maintains those defconfig files. See? Especially the (b) part is relevant - I am simply not going to be the person who tries to clean up after other people sh*tting all over their trees with defconfig files. If I do something, it will be total surgery, ie keep your damn broken defconfig files somewhere else than in my tree - I'm tired of your stupidities. It will not be I'll be your mother and clean up your room every day after you made a mess. So if the ARM people decide that your script is a good way to clean up the mess, I might be happy with that. But that would require that they NEVER EVER try to push me a update that contains an un-cleaned-up defconfig file. If they do, and the defconfig files end up showing up big in git history, then the approach has failed. See? The reason I'm not replying to your approach is that it's simply not for me to do so (and no, I don't think it's maintainable, but I haven't tried it, so..) Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: When you brought up the problem you seemed absolutely convinced that nothing except your solution was going to be acceptable. That's not true. What's true is that you didn't seem to _understand_ my solution, so I tried to push the understanding of it. There are always other solutions. I seriously doubt that Uwe's is a maintainable one. That said, even a one-time reduce the size of that stinking pile of sh*t is probably better than nothing. I hope you at least do agree that the current situation is a steaming pile of sh*t. And yes, I _will_ remove the crap, both from POWER and ARM, unless I see some serious tries at fixing it. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
2010/7/12 Uwe Kleine-König u.kleine-koe...@pengutronix.de: I'm willing to try my solution, some others on the linux-arm-kernel lists considered it worth trying, too. Feel free to pull my tree[1]. Russell refused to take defconfig changes for a while now, so I don't expect merge problems if you do. Well, I can hardly refuse a pull that removes almost 200k lines. So I'd happily pull it. Just this single line in your email is a very very powerful thing: 177 files changed, 652 insertions(+), 194157 deletions(-) However, before I would pull, I'd definitely like to make sure we at least have some way forward too, and clarify some issues. So I have a couple of questions: - is this guaranteed to be a no-op as things stand now, and what are the secondary effects of it? Put another way: I realize that fairly late in the -rc series is actually a really good time to do this, rather than during the merge window itself when things are in flux. However, while it would be a good time to pull this for that reason, it's also a _horrible_ time to pull if it then regresses the defconfig uses, or if it causes horrible problems for linux-next merging etc. - what happens when somebody wants to update the defconfig files? This is a question that involves a number of people, because over the last half year, we've had lots of people changing them. git shortlog -ns on that ARM config directory gives 39 people in the last half year, with the top looking roughly like 26 Ben Dooks 10 Tony Lindgren 4 Haojian Zhuang 4 Kukjin Kim 3 Santosh Shilimkar 3 Sriram 2 Janusz Krzysztofik and how are these people going to do their updates going forward without re-introducing the noise? IOW, I'd _love_ to get rid of almost 200k lines of noise and your approach would seem to have the advantage that it's invisible to users. But I would want to get some kind of assurance that it's practical to do so. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote: Put another way: I realize that fairly late in the -rc series is actually a really good time to do this, rather than during the merge window itself when things are in flux. However, while it would be a good time to pull this for that reason, it's also a _horrible_ time to pull if it then regresses the defconfig uses, or if it causes horrible problems for linux-next merging etc. This cannot be any worse than wholesale removal of those files as you were contemplating at some point. Furthermore, on ARM we have someone providing automatic rebuild of all defconfigs already, so any serious issue should be noticed right away. You aren't really answering the question. The thing is, the wholesale removal wouldn't happen during the late -rc anyway, and it wouldn't cause any merge issues (merge conflicts where the file is just to be removed are trivial to take care of). So I'm really asking about the issue of how does this work during the late -rc phase. Where the _timing_ is the important thing. Because I could as easily pull after 2.6.35 is out. That has it's own downsides (with all the merging going on), but at the same time, it's clearly the right time for a large change. So when I ask about timing and how does this work in late -rc, it's really about how safe it is to do now. Because if it isn't very obviously safe, I can't pull it. One part of the obviously safe thing is verification for each defconfig file that the end result is identical with the reduced version. Uwe implied that it was, and that was clearly the intention, but was there some explicit verification that yes, the before-and-after configurations are 100% the same? Also, I assume that while it's _mostly_ a transparent change to users, it does require that people do make oldconfig with the reduced defconfig file first, in order to avoid having to answer with the defaults. No? And the reduced defconfig files obviously do depend on the default in the Kconfig files themselves, so it does have that kind of fairly subtle semantic change that may not be entirely obvious or easy to notice. So from a timing standpoint, I just want to be convinced that late -rc really is the right thing. I'm not entirely sure it is, even though I do see advantages. I think Uwe could provide his script and add it to the kernel tree. Then all architectures could benefit from it. Having the defconfig files contain only those options which are different from the defaults is certainly more readable, even on x86. Quite possible. But maintainers would need to be on the lookout of people actually using the script, and refusing to apply patches that re-introduce the whole big thing. I also haven't actually seen the script - I don't think Uwe ever posted it - so maybe it's some very fragile thing. Hard to judge on no real information ;^p Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Mon, Jul 12, 2010 at 1:29 PM, Nicolas Pitre n...@fluxnic.net wrote: For the record, I do support Uwe's work too. I do wish it could go in now so that from that point going forward we could only focus on improving the thing instead of having to care about implications during the merge window. Ok, I merged it. I do love the diffstat. And while it may not be optimal or a final solution, nobody seems to hate it either. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
2010/7/12 David Brown dav...@codeaurora.org: Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Uwe posted it earlier in this thread as an attachement, and I put the python script into the merge commit message too. And we should probably put it somewhere in scripts too, and/or make a 'make' target to create the small config files. I pushed it all out, and tagged it as -rc5. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suspend blockers Android integration
On Fri, 4 Jun 2010, Ingo Molnar wrote: This allows a task to 'exclude' other tasks that dont have low-latency requirements. Crappy apps would have a large latency value, so they'd be idled out when a privileged task sets the exclusion level low enough. Quite frankly, this sounds fundamentally broken. Think deadlock. The high-latency task got a lock, and now you're excluding it because it scheduled away. So from my perspective, putting that kind of logic deep in the system sounds like the _last_ thing we want to do. I think it's much saner to have a very targeted suspend blocker that only blocks the opportunistic suspends and has _zero_ interaction with the rest of the system (certainly none at all with core code like the scheduler). And if somebody then suspends the traditional way (by an actual suspend event, not that opportunistic thing), then the suspend blocker does nothing at all - because it simply doesn't even _exist_ at that level. It's only about the opportunistic suspends. (I'd further suggest that disk wait and running in kernel mode disable any opportunistic suspend anyway - but that's not about suspend blockers as much as it is about just the opportunistic suspend itself). Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suspend blockers Android integration
On Fri, 4 Jun 2010, Ingo Molnar wrote: What you say is absolutely true, hence this would be driven via sched_tick() + TIF notifiers - i.e. only ever treat user-mode tasks as 'idle-able'. This can be done with no overhead to the regular fastpaths. The TIF notifier would be the one scheduling to idle - and would thus do it only to user-mode tasks. The thing is, unless there is some _really_ deep other reason to do something like this, I still think it's total overdesign to push any knowledge/choices like this into the scheduler. I'd rather keep things way more independent, less tied to each other and to deep kernel subsystems. IOW, my personal opinion is that somethng like a suspend (blocker or not) decision simply shouldn't be important enough to be tied into the scheduler. Especially not if it could just be its own layer. That said, as far as I know, the Android people have mostly been looking at the suspend angle from a single-core standpoint. And I'm not at all convinced that they should hijack the existing /sys/power/state thing which is what I think they do now. And those two things go together. The /sys/power/state thing is a global suspend - which I don't think is appropriate for a opportunistic thing in the first place, especially for multi-core. A well-designed opportunistic suspend should be a two-phase thing: an opportunistc CPU hotunplug (shutting down cores one by one as the system is idle), and not a global event in the first place. And only when you've reached single-core state should you then say do I suspend the system too. So I've tried to look a bit at the patches, and my admittedly rough comments so far is - I really do prefer the off to the side approach that the current google opportunistic suspend patches have. As mentioned, I don't think this should be deep in the scheduler. Not at all. - I do think there are possibly races and CPU idle issues there, but I think they are mainly for the multi-core thing. And I think that's a totally separate issue. Or it _should_ be. - once you're single-core (whether because you never had more cores to begin with, or because the opportunistic CPU offlining has taken down the other cores), I think the suspend-blocker is fine as a concept, and certainly shouldn't need any deep scheduler hooks. so I'd like to see the opportunistc suspend thing think about CPU offlining, and I'd like to see it disconnect from the existing /sys/power/state. And I'd really not like to involved deep internal kernel hooks into it. But I'll also admit that maybe I'm not seeing some problems. I've frankly tried to avoid the whole discussion until Andrew pulled me in yesterday. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suspend blockers Android integration
On Thu, 3 Jun 2010, Linus Torvalds wrote: so I'd like to see the opportunistc suspend thing think about CPU offlining Side note: one reason for me being somewhat interested in the CPU offlining is that I think the Android kind of opportunistic suspend is _not_ likely something I'd like to see on a desktop. But an the opportunistic CPU offliner? That might _well_ be useful even outside of any other suspend activity. If the system is idle (or almost idle) for long times, I would heartily recommend actively shutting down unused cores. Some CPU's are hopefully smart enough to not even need that kind of software management, but I suspect even the really smart ones might be able to take advantage of the kernel saying: I'm shutting you down, you don't have to worry about latency AT ALL, because I'm keeping another CPU active to do any real work. I'd also be interested to see if it could even improve single-thread performance if we end up doing the whole SMP-UP lock prefix rewriting when the system is idle enough that we'd be better off running just a single core. I dunno - just throwing that out there. Anyway, the only reason I think this is related is literally because I think that if we know there is only a single CPU active, I think the actual real opportunistic suspend is easier. Suddenly you don't have to worry about what happens on other run-queues etc, and whether another CPU is just about to create a suspend block etc. So I think they tie together, although it's mostly tangential. And as mentioned, I think a opportunistic CPU suspend part is more relevant outside of Android, and thus perhaps more widely interesting. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suspend blockers Android integration
On Thu, 3 Jun 2010, Arjan van de Ven wrote: And because there's then no power saving (but a performance cost), it's actually a negative for battery life/total energy. Including the UP optimizations we do (ie lock prefix removal)? It's possible that I'm just biased by benchmarks, and it's true that Intel has been getting lots better, but the locking costs are very noticeable performance-wise on some benchmarks. And several CPU's have been held back from going into deepest sleep states by stupid firmware and/or platform bugs. But hey, if it's not going to help, and people have tried it, I guess I'll have to believe it. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v2.6.34-rc5
On Mon, 26 Apr 2010, Tony Lindgren wrote: Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus I pulled it this time, but I'm starting to get really irritated with you. These look like real fixes, but quite frankly, by -rc5, that IS NOT ENOUGH. They need to be _regressions_, not just cleanups and fixes for things that have never worked. And this is starting to be a pattern with the omap tree: you're not honoring the merge window properly. Just it's a bug-fix or it's deleting unused code is not enough. The point of the late -rc series is to fix problems from the merge window, not add new changes. I realize that you think that all the new changes are obviously good, but the fact is, bugs happen even in obvious bug-fixes. And that's why we have the rule about late-rc pulls being about _regressions_ and/or major oopses/security issues. Not just random development that are meant to improve things. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v2.6.34-rc5
On Tue, 27 Apr 2010, Tony Lindgren wrote: OK point taken. I should have dealt with this earlier. Will only queue regressions after -rc3 or so. Note that the only regressions is certainly not a hard rule. Anything that would be valid for -stable is obviously always valid: security issues, major oopses etc etc. But the only regressions should kind of be the guiding line, and the others are more like this is so serious that it should go in regardless of anything else. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for 2.6.33-rc3
On Fri, 8 Jan 2010, Tony Lindgren wrote: Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus No. I don't know what the *** people have been doing in that tree, but it looks like the _same_ branch was merged twice after rebasing: Merge branch 'for_2_6_33_rc_a' of git://git.pwsan.com/linux-2.6 into omap-fixes-2.6.33-rc3 Merge branch 'for_2.6.33rc_b' of git://git.pwsan.com/linux-2.6 into omap-fixes-for-linus This is why we don't rebase public trees, and I refuse to pull crap like that. You need to teach the people you work with to not rebase, and the only way I can say stop is by simply not pulling the crap. There are other problems with that branch too - the committer information is pure sh*t. It says paul p...@twilight.(none), so quite frankly, somebody hasn't even read the very first chapter of just about every single git documentation that is out there. And now that I noticed, I see that the crap-for-brains committer info has been going on for a long time, and I just hadn't looked closely enough before. I didn't look closely enough to see if the rebase problem had also happened before. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for 2.6.33-rc3
On Fri, 8 Jan 2010, Tony Lindgren wrote: $ git log --pretty=oneline --author=.(none) --committer=.(none) v2.6.33-rc1.. Well, that will catch one particular common case of it, but.. Should we have some check like this in place for all pulls? .. it would probably make more sense to warn about it earlier in the chain, so that people with bad configurations can fix them. By the time somebody pulls, it's pretty late in the game. Sadly, git doesn't do any real sanity checking, and now it's pretty much too late. It takes about a year or two for new git versions to percolate out, with things like Debian-stable etc, so making git warn about suspicious-looking names is not necessarily going to help (and with scripting and importing from other SCM's, it may be wrong to warn in general). It's _fairly_ easy to set up a hook at commit-time to check for random thigns, but obviously if the problem is that people haven't configured their git setup, then add a hook is not going to work. In that sense, pull-time may be better, as a way to see it automatically after-the-fact. Doing a post-merge hook would catch it, and could be used to warn about the fact that you merged something odd. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: origin tree build failure
On Wed, 16 Dec 2009, Stephen Rothwell wrote: Hi Tony, On Tue, 15 Dec 2009 09:27:17 -0800 Tony Lindgren t...@atomide.com wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [091215 06:52]: On Tue, Dec 15, 2009 at 04:41:08PM +1100, Stephen Rothwell wrote: I have applied this patch for today (please check): Looks good to me too, fwiw: Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Good thing we have for-next to catch things like this. Except if the renaming patch had gone through linux-next (even for one day) we would have found the problem *before* it was in Linus' tree ... I think maybe Tony was being ironic, exactly because of this. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
