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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
37 matches
Mail list logo
