Hi!
There's a number of down-counting clocksources using various methods to
convert to an up-counting value - sometimes -readl(), sometimes
cs-mask - readl() and sometimes ~readl().
Then there's those which are either 16-bit or 32-bit, and some of those
16-bit implementations must use
2011/4/1 Arnd Bergmann a...@arndb.de:
On Friday 01 April 2011, Ingo Molnar wrote:
IMO the right answer is what Linus and Thomas outlined:
1) provide a small number of clean examples and clean abstractions
2) to not pull new crap from that point on
3) do this gradually but
On 4/6/2011 3:52 AM, Linus Walleij wrote:
2011/4/5 Santosh Shilimkarsantosh.shilim...@ti.com:
The only issue I see is the clock-events implemented using
local timers capabilities in low power modes. The local timers
won't be able wakeup CPU from DORMANT or OFF state and hence
you will need an
On 4/6/2011 3:46 AM, Linus Walleij wrote:
2011/4/5 Santosh Shilimkarsantosh.shilim...@ti.com:
[Me]
(And third it will also eventually need to hook into the timer-based
delay framework that I think Nokia is working on to be really
useful, else all delays become unpredictable.)
Do you mean
On Wed, Apr 6, 2011 at 2:11 PM, Barry Song 21cn...@gmail.com wrote:
2011/4/1 Arnd Bergmann a...@arndb.de:
On Friday 01 April 2011, Ingo Molnar wrote:
IMO the right answer is what Linus and Thomas outlined:
1) provide a small number of clean examples and clean abstractions
2) to not
On Wed, 2011-04-06 at 00:19 +0100, Linus Walleij wrote:
2011/4/1 Linus Torvalds torva...@linux-foundation.org:
If you have discoverable hardware, use it.
But by discoverable hardware I mean something like PCI config
cycles. IOW, real hardware features.
The ARM AMBA architecture
On Wednesday 06 April 2011, Catalin Marinas wrote:
On Wed, 2011-04-06 at 00:19 +0100, Linus Walleij wrote:
2011/4/1 Linus Torvalds torva...@linux-foundation.org:
Basically it requires you to get the physical address and size of
each peripheral, then at offset -0x10 from the end address
On 4/5/2011 1:38 AM, Linus Walleij wrote:
2011/4/4 Marc Zyngiermarc.zyng...@arm.com:
On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote:
If ARM are going to architect a set of timers into the hardware, let's
make sure that all such hardware has them so we can dig ourselves out
On Mon, 2011-04-04 at 22:08 +0200, Linus Walleij wrote:
2011/4/4 Marc Zyngier marc.zyng...@arm.com:
On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote:
If ARM are going to architect a set of timers into the hardware, let's
make sure that all such hardware has them so we can
On Tue, Apr 05, 2011 at 12:10:24PM +0530, Santosh Shilimkar wrote:
The only issue I see is the clock-events implemented using
local timers capabilities in low power modes. The local timers
won't be able wakeup CPU from DORMANT or OFF state and hence
you will need an additional wakeup capable
On Tue, 2011-04-05 at 08:45 +0100, Russell King - ARM Linux wrote:
On Tue, Apr 05, 2011 at 12:10:24PM +0530, Santosh Shilimkar wrote:
The only issue I see is the clock-events implemented using
local timers capabilities in low power modes. The local timers
won't be able wakeup CPU from
2011/4/5 Santosh Shilimkar santosh.shilim...@ti.com:
[Me]
(And third it will also eventually need to hook into the timer-based
delay framework that I think Nokia is working on to be really
useful, else all delays become unpredictable.)
Do you mean udelay()/mdelay() here ?
Yes. Stephen Boyd
2011/4/5 Santosh Shilimkar santosh.shilim...@ti.com:
The only issue I see is the clock-events implemented using
local timers capabilities in low power modes. The local timers
won't be able wakeup CPU from DORMANT or OFF state and hence
you will need an additional wakeup capable clock-event
2011/4/1 Linus Torvalds torva...@linux-foundation.org:
If you have discoverable hardware, use it.
But by discoverable hardware I mean something like PCI config
cycles. IOW, real hardware features.
The ARM AMBA architecture actually has such a thing, or a
little of it, found in
Le 01/04/2011 17:30, Detlef Vollmann :
On 04/01/11 16:59, Arnd Bergmann wrote:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all of
which
are ARMv7 based.
Define interesting.
The
On Mon, 2011-04-04 at 01:59 +0100, Arnd Bergmann wrote:
On Sunday 03 April 2011, Russell King - ARM Linux wrote:
Then there's those which change the cs-read function pointer at runtime,
...
and those which share that pointer with their sched_clock() implementation.
Abstracting
On Mon, Apr 04, 2011 at 12:03:42PM +0100, Catalin Marinas wrote:
On Mon, 2011-04-04 at 01:59 +0100, Arnd Bergmann wrote:
On Sunday 03 April 2011, Russell King - ARM Linux wrote:
Then there's those which change the cs-read function pointer at runtime,
...
and those which share that
On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote:
On Mon, Apr 04, 2011 at 12:03:42PM +0100, Catalin Marinas wrote:
On Mon, 2011-04-04 at 01:59 +0100, Arnd Bergmann wrote:
On Sunday 03 April 2011, Russell King - ARM Linux wrote:
Then there's those which change the cs-read
On Mon, Apr 04, 2011 at 02:24:17PM +0100, Marc Zyngier wrote:
On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote:
Whether its worth it or not is questionable - the above is more lines
of code than many of the existing implementations, and we're not going
to shrink the
On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote:
On Mon, Apr 04, 2011 at 02:24:17PM +0100, Marc Zyngier wrote:
On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote:
Whether its worth it or not is questionable - the above is more lines
of code than many of
2011/4/4 Marc Zyngier marc.zyng...@arm.com:
On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote:
If ARM are going to architect a set of timers into the hardware, let's
make sure that all such hardware has them so we can dig ourselves out
of this crappy mess that we find
On Saturday 02 April 2011, Nicolas Pitre wrote:
On Sat, 2 Apr 2011, Arnd Bergmann wrote:
On Friday 01 April 2011 21:54:47 Nicolas Pitre wrote:
I however don't think it is practical to go off in a separate
mach-nocrap space and do things in parallel. Taking OMAP as an example,
there
On Fri, 2011-04-01 at 16:28 +0200, Detlef Vollmann wrote:
* No board files
Where do you put code that needs to run very early (e.g. pinging the
watchdog)?
Even on powerpc I keep board files :-)
The main thing is:
- The generic - board linkage must not be hard (ie, no
platform_restart,
On Monday 04 April 2011, Benjamin Herrenschmidt wrote:
On Fri, 2011-04-01 at 16:28 +0200, Detlef Vollmann wrote:
* No board files
Where do you put code that needs to run very early (e.g. pinging the
watchdog)?
Even on powerpc I keep board files :-)
The main thing is:
- The
On Sunday 03 April 2011, Russell King - ARM Linux wrote:
On Sun, Apr 03, 2011 at 05:26:37PM +0200, Arnd Bergmann wrote:
There are a few other examples that were done in a similar way:
* The drivers/ide code still serves a few hardware platforms that
never had anyone write a new libata
On Mon, 4 Apr 2011, Benjamin Herrenschmidt wrote:
On Fri, 2011-04-01 at 16:28 +0200, Detlef Vollmann wrote:
* No board files
Where do you put code that needs to run very early (e.g. pinging the
watchdog)?
Even on powerpc I keep board files :-)
The main thing is:
- The generic
On 17:30 Fri 01 Apr , Detlef Vollmann wrote:
On 04/01/11 16:59, Arnd Bergmann wrote:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all of which
are ARMv7 based.
Define
On Thu, 2011-03-31 at 17:23 +0200, Arnd Bergmann wrote:
* The DSS display drivers introduce new infrastructure include new bus
types that have the complexity to make them completely generic, but
in practice can only work on OMAP, and are clearly not written with
cross-vendor
* David Brown dav...@codeaurora.org wrote:
When we push back, there is a good chance they just won't bother, not because
they don't want to do it, but because it doesn't fit a schedule, and there is
already something else for them to work on.
So what's the right answer here. [...]
IMO
On Friday 01 April 2011, Tomi Valkeinen wrote:
On Thu, 2011-03-31 at 17:23 +0200, Arnd Bergmann wrote:
* The DSS display drivers introduce new infrastructure include new bus
types that have the complexity to make them completely generic, but
in practice can only work on OMAP, and are
On Thursday 31 March 2011, Kevin Hilman wrote:
Arnd Bergmann a...@arndb.de writes:
But that's the point. The incentive is there for managing the infrastructure
within the SoC, but not across SoCs.
OK, but the rest of my thread went on to describe how at least a few ARM
SoC maintainers
On Thursday 31 March 2011, Thomas Gleixner wrote:
On Thu, 31 Mar 2011, Arnd Bergmann wrote:
Right, but the problem starts in way simpler areas like irq chips and
gpio stuff, where lots of the IP cores are similar and trivial enough
to be shared across many SoC families.
Yes, I'm sure that
(dropping people from cc, as this is getting quite DSS spesific)
On Fri, 2011-04-01 at 13:22 +0200, Arnd Bergmann wrote:
On Friday 01 April 2011, Tomi Valkeinen wrote:
On Thu, 2011-03-31 at 17:23 +0200, Arnd Bergmann wrote:
* The DSS display drivers introduce new infrastructure include
On Friday 01 April 2011, Tomi Valkeinen wrote:
Thanks for pointing me to the MCDE stuff. I doesn't seem to be merged,
though. I need to contact them and see if they're still interested in
working on the common interface.
I pushed back quite hard on some of the aspects there, which probably
On Fri, 2011-04-01 at 14:07 +0200, Arnd Bergmann wrote:
On Friday 01 April 2011, Tomi Valkeinen wrote:
Thanks for pointing me to the MCDE stuff. I doesn't seem to be merged,
though. I need to contact them and see if they're still interested in
working on the common interface.
I pushed
On Friday 01 April 2011, Ingo Molnar wrote:
IMO the right answer is what Linus and Thomas outlined:
1) provide a small number of clean examples and clean abstractions
2) to not pull new crap from that point on
3) do this gradually but consistently
I.e. make all your requirements
On Wednesday 30 March 2011, Russell King - ARM Linux wrote:
On Wed, Mar 30, 2011 at 07:06:41PM +0200, Arnd Bergmann 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
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all of which
are ARMv7 based.
Define interesting.
The ones that are causing the churn that we're talking about.
Platforms that have been
Hi Arnd,
On Fri, 2011-04-01 at 14:54 +0100, Arnd Bergmann wrote:
I would actually suggest a different much more radical start: Fork the way
that platforms are managed today, and start an alternative way of setting
up boards and devices together with the proven ARM core kernel infrastructure,
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 16:59, Arnd Bergmann wrote:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all of which
are ARMv7 based.
Define
On Friday 01 April 2011, Will Deacon wrote:
1. The core arch code is not a problem (Russell does a great job here)
2. The platform specific code contains a lot of crap that doesn't belong
there
(not enough reviewers to push back on crap)
3. The amount of crap in platform specfic
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 Fri, Apr 01, 2011 at 05:50:17PM +0200, Arnd Bergmann wrote:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 16:59, Arnd Bergmann wrote:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a
On Fri, 1 Apr 2011, Arnd Bergmann wrote:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 16:59, Arnd Bergmann wrote:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all
On Fri, 1 Apr 2011, Arnd Bergmann wrote:
On Friday 01 April 2011, Will Deacon wrote:
1. The core arch code is not a problem (Russell does a great job here)
2. The platform specific code contains a lot of crap that doesn't belong
there
(not enough reviewers to push back on crap)
Hello,
On Fri, Apr 01, 2011 at 03:54:47PM -0400, Nicolas Pitre wrote:
It would be more useful and scalable to simply sit down, look at the
current mess, and identify common patterns that can be easily factored
out into some shared library code, and all that would be left in the
board or
Arnd Bergmann a...@arndb.de writes:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all of which
are ARMv7 based.
Define interesting.
The ones that are causing the churn that we're
On Friday 01 April 2011 23:10:04 Kevin Hilman wrote:
Arnd Bergmann a...@arndb.de writes:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all of
which
are ARMv7 based.
On Friday, 1 April 2011, Arnd Bergmann a...@arndb.de wrote:
On Friday 01 April 2011 23:10:04 Kevin Hilman wrote:
Arnd Bergmann a...@arndb.de writes:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful
On Friday 01 April 2011 21:54:47 Nicolas Pitre wrote:
On Fri, 1 Apr 2011, Arnd Bergmann wrote:
I thought new ones were generally Cortex-M3 based. Either way, even
if there are exceptions, focusing on ARMv7 at first should give
a good representation of the new development.
The actual
On Sat, 2 Apr 2011, Arnd Bergmann wrote:
On Friday 01 April 2011 21:54:47 Nicolas Pitre wrote:
I however don't think it is practical to go off in a separate
mach-nocrap space and do things in parallel. Taking OMAP as an example,
there is already way too big of an infrastructure in place
On Fri, Apr 01, 2011 at 03:54:47PM -0400, Nicolas Pitre wrote:
1) GPIO drivers
As Linus observed, in the majority of the cases GPIOs are accessed
through simple memory-mapped registers. Some have absolute state
registers, the others have separate clear/set registers. Suffice to
On Fri, Apr 01, 2011 at 05:55:57PM +0200, Arnd Bergmann wrote:
On Friday 01 April 2011, Will Deacon wrote:
I don't understand how you can handle `early quirks' without board
files. Does this follow on from Linus' suggestion about moving code out
of the kernel and into the bootloader?
On Fri, Apr 01, 2011 at 04:19:31PM -0400, Nicolas Pitre wrote:
In a perfect world the bootloader would be bug free and always up to
date with the best DT data. In practice I'm very skeptical this will
always be the case and painless. At least the above makes it very
simple to have a
On Wed, Mar 30, 2011 at 8:24 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
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,
On Wed, Mar 30 2011, Linus Torvalds wrote:
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
On Wed, 30 Mar 2011, da...@lang.hm wrote:
On Wed, 30 Mar 2011, Nicolas Pitre wrote:
As long as SOC vendors keep producing wildly different architectures
besides the core CPU we'll have this problem. Denying the reality won't
make that problem go away either. And device tree won't stop
On Thu, 31 Mar 2011, Geert Uytterhoeven wrote:
On Thu, Mar 31, 2011 at 01:31, Nicolas Pitre n...@fluxnic.net wrote:
On ARM there is simply not such thing as a single machine design to
clone, and a closed source test bench to design for.
There are other architectures that didn't start from
* Nicolas Pitre n...@fluxnic.net wrote:
On Wed, 30 Mar 2011, da...@lang.hm wrote:
back in the early days of the PCs, different systems from different vendors
had different bus types, peripherals at different addresses, etc. that
didn't
make all of those vendors systems different
On Wed, Mar 30, 2011 at 10:05:41PM -0700, da...@lang.hm wrote:
with ARM you do have a couple different architectures (arm5 vs arm7 for
example), but what you are hearing people say is that
arm7+IPblock1+IPblock2
arm7+IPblock1+IPblock3
arm7+IPblock2+IPblock3
are not three different
On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote:
Having strong, effective platform abstractions inside the kernel really helps
even if the hardware space itself is inevitably fragmented: both powerpc and
x86 has shown that. Until you realize and appreciate that you really have not
Absolutely. On Intel, it is (still) Windows the reference. If Windows
doesn't boot on your motherboard you have a problem. So motherboard
vendors won't make crazy incompatible things. They are constrained to
OLPC, Moorestown ?
fix their hardware because they just cannot alter Windows
B1;2401;0cOn Thu, 31 Mar 2011, Nicolas Pitre wrote:
On Wed, 30 Mar 2011, Linus Torvalds wrote:
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
* Russell King - ARM Linux li...@arm.linux.org.uk wrote:
On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote:
Having strong, effective platform abstractions inside the kernel really
helps
even if the hardware space itself is inevitably fragmented: both powerpc
and
x86 has
Hi,
On Thu, Mar 31, 2011 at 09:09:54AM +0100, Russell King - ARM Linux wrote:
what's more, you seem to be saying that
arm7+IPblock1
and
arm7+IPblock1
are different architectures if the wiring between the arm core and
IPblock1 are different (they are different 'boards' or
On Thu, Mar 31, 2011 at 10:54:40AM +0100, Alan Cox wrote:
If I boot it on a current PC I'm booting on a multiprocessor system with
different timers, totally different IRQ controllers, different keyboard
controllers (USB), PCI Express, an IOMMU, NCQ SATA, ACPI, graphics
running in shared host
On Wed, 2011-03-30 at 23:10 +0200, Thomas Gleixner wrote:
The only problem is to find a person, who is willing to do that, has
enough experience, broad shoulders and a strong accepted voice. Not to
talk about finding someone who is willing to pay a large enough
compensation for pain and
Hi,
On Wed, Mar 30, 2011 at 08:24:30PM -0700, Linus Torvalds wrote:
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.
Most likely those
On 11:50 Thu 31 Mar , Russell King - ARM Linux wrote:
On Thu, Mar 31, 2011 at 10:54:40AM +0100, Alan Cox wrote:
If I boot it on a current PC I'm booting on a multiprocessor system with
different timers, totally different IRQ controllers, different keyboard
controllers (USB), PCI
On Thu, 2011-03-31 at 11:50 +0100, Russell King - ARM Linux wrote:
Given this thread, I've lost the motivation to continue with it because
it's just going to cause more 'pointless churn' and end up annoying
Linus even more.
I don't think the criticism was directed at the core ARM code that you
On Thu, Mar 31, 2011 at 01:38:21PM +0100, Catalin Marinas wrote:
On Thu, 2011-03-31 at 11:50 +0100, Russell King - ARM Linux wrote:
Given this thread, I've lost the motivation to continue with it because
it's just going to cause more 'pointless churn' and end up annoying
Linus even more.
On Thu, Mar 31, 2011 at 12:41:52PM +0200, Ingo Molnar wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk wrote:
On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote:
Having strong, effective platform abstractions inside the kernel really
helps
even if the hardware space
On Wed, 30 Mar 2011, Linus Torvalds wrote:
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
On Thursday 31 March 2011, Artem Bityutskiy wrote:
On Wed, 2011-03-30 at 23:10 +0200, Thomas Gleixner wrote:
The only problem is to find a person, who is willing to do that, has
enough experience, broad shoulders and a strong accepted voice. Not to
talk about finding someone who is willing
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote:
And I'm not going to be merging anything into my tree for the time being.
I know there's no way for me to continue without being moaned at by someone.
So I'm just going to take the easy option at the moment and do precisely
nothing in terms
Thomas Gleixner t...@linutronix.de writes:
But the current SoC maintainer model does not work either. The SoC
maintainers care about their sandbox and have exactly zero incentive
to look at the overall picture, e.g reuse of code for the same IP
blocks, better abstraction mechanisms etc.
Russell:
On Thu, Mar 31, 2011 at 8:01 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
And since Linus' whinge about ARM defconfigs, I really *hate* merging
anything with *any* defconfig changes in - as a result, I don't
particularly want to deal with ARM defconfig changes anymore.
On Thu, 31 Mar 2011, Kevin Hilman wrote:
Thomas Gleixner t...@linutronix.de writes:
But the current SoC maintainer model does not work either. The SoC
maintainers care about their sandbox and have exactly zero incentive
to look at the overall picture, e.g reuse of code for the same IP
On Thu, Mar 31, 2011 at 05:01:40PM +0200, Thomas Gleixner wrote:
On Thu, 31 Mar 2011, Kevin Hilman wrote:
Thomas Gleixner t...@linutronix.de writes:
But the current SoC maintainer model does not work either. The SoC
maintainers care about their sandbox and have exactly zero incentive
On Thursday 31 March 2011, Kevin Hilman wrote:
Some SoCs families (like OMAP) have huge amount of diversity even within
the SoC family, so better abstractions and generic infrastrucure
improvements are an obvious win, even staying within the SoC.
But that's the point. The incentive is there
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote:
On Thu, Mar 31, 2011 at 05:01:40PM +0200, Thomas Gleixner wrote:
On Thu, 31 Mar 2011, Kevin Hilman wrote:
Thomas Gleixner t...@linutronix.de writes:
Yes, ARM SoC maintainers have to make up some ground. But compare this
to just a
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote:
On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote:
Having strong, effective platform abstractions inside the kernel really helps
even if the hardware space itself is inevitably fragmented: both powerpc and
x86 has shown that. Until
On Thu, Mar 31, 2011 at 09:03:28AM -0700, da...@lang.hm wrote:
In this case I owe you and Nicolas an apology.
Thanks.
it's not the total amount of code, and it's not even the total amount of
change to the code that's the issue.
I think you're not entirely correct - have a look at Linus'
On Thu, 31 Mar 2011, Arnd Bergmann wrote:
On Thursday 31 March 2011, Kevin Hilman wrote:
Some SoCs families (like OMAP) have huge amount of diversity even within
the SoC family, so better abstractions and generic infrastrucure
improvements are an obvious win, even staying within the SoC.
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, 31 Mar 2011, Russell King - ARM Linux wrote:
On Thu, Mar 31, 2011 at 10:54:40AM +0100, Alan Cox wrote:
If I boot it on a current PC I'm booting on a multiprocessor system with
different timers, totally different IRQ controllers, different keyboard
controllers (USB), PCI Express, an
On Thu, 31 Mar 2011, da...@lang.hm wrote:
I think that part of the issue is that when Linus points out a problem, the
response isn't we agree and are working on it, here's what we are doing,
instead it seems to be mostly there is no problem, this is just because there
is so much variation in
Op 31 mrt 2011, om 19:22 heeft da...@lang.hm het volgende geschreven:
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote:
On Thu, Mar 31, 2011 at 10:54:40AM +0100, Alan Cox wrote:
If I boot it on a current PC I'm booting on a multiprocessor system with
different timers, totally different
Hello,
Am 31.03.2011 10:09, schrieb Russell King - ARM Linux:
We also need the various SoC designers and ARM architecture people to
realise that what the hardware situation is rediculous; I have commented
about this lack of standardisation to ARM in past years. ARM have had
a standard set of
And since Linus' whinge about ARM defconfigs, I really *hate* merging
anything with *any* defconfig changes in - as a result, I don't
particularly want to deal with ARM defconfig changes anymore.
I thought we solved this with the introduction of make savedefconfig
that created much much
On Thu, Mar 31, 2011 at 08:12:54PM +0200, Sam Ravnborg wrote:
And since Linus' whinge about ARM defconfigs, I really *hate* merging
anything with *any* defconfig changes in - as a result, I don't
particularly want to deal with ARM defconfig changes anymore.
I thought we solved this with
On Thu, 31 Mar 2011, Thomas Gleixner wrote:
Start off with such a trivial, but immense effective cleanup and see
what it helps to share code even accross SoC vendors. They all glue
together random IP blocks from the market and there are not soo many
sources which are relevant. This makes
On Thu, 31 Mar 2011 19:17:51 +0100
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
On Thu, Mar 31, 2011 at 08:12:54PM +0200, Sam Ravnborg wrote:
And since Linus' whinge about ARM defconfigs, I really *hate* merging
anything with *any* defconfig changes in - as a result, I don't
On Thu, 31 Mar 2011, Nicolas Pitre wrote:
On Thu, 31 Mar 2011, da...@lang.hm wrote:
I think that part of the issue is that when Linus points out a problem, the
response isn't we agree and are working on it, here's what we are doing,
instead it seems to be mostly there is no problem, this
On Thu, 31 Mar 2011, Nicolas Pitre wrote:
On Thu, 31 Mar 2011, Thomas Gleixner wrote:
Start off with such a trivial, but immense effective cleanup and see
what it helps to share code even accross SoC vendors. They all glue
together random IP blocks from the market and there are not soo
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, 31 Mar 2011, Linus Torvalds wrote:
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.
I do that, Russell does that, Catalin does that, Tony
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
Arnd Bergmann a...@arndb.de writes:
On Thursday 31 March 2011, Kevin Hilman wrote:
Some SoCs families (like OMAP) have huge amount of diversity even within
the SoC family, so better abstractions and generic infrastrucure
improvements are an obvious win, even staying within the SoC.
But
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
1 - 100 of 150 matches
Mail list logo
