Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-05-26 Thread Pavel Machek
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 readw() to avoid bus faults.
> 
> Combining all those together you end up with something pretty disgusting,
> and an initialization function taking 7 arguments (iomem pointer, name,
> rating, tick rate, size, up/down counter, clocksource flags).

Having structure with 7 fields describing the clock source  seems
completely sane...
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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

2011-04-06 Thread Arnd Bergmann
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 :
> > Basically it requires you to get the physical address and size of
> > each peripheral, then at offset -0x10 from the end address (usually
> > at even 4K pages), if you find the magic number 0xB105F00D
> > (ARM has a sense of humour, obviously) you can find something
> > alike the PCI IDs at offset -0x20, manufacturer ID, version number
> > and revision of the hardware.
> 
> I don't think this was ever part of the AMBA specification. It was just
> some convention used within ARM for the PrimeCell peripherals. Other
> AMBA licensees did something else so it's not a reliable mechanism (I
> think ARM gave up on this as well in recent peripherals).

Do you think there is a way to get ARM ltd to make a better effort
at this with a future specification? I suppose it would be extremely
helpful if there was a way to specify more of the required information,
and to require everybody to fill in correct data, in the same way that
architecture compliance gets enforced on the CPU core.

Arnd
--
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

2011-04-06 Thread Catalin Marinas
On Wed, 2011-04-06 at 00:19 +0100, Linus Walleij wrote:
> 2011/4/1 Linus Torvalds :
> 
> > 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 drivers/amba/bus.c.
> 
> Basically it requires you to get the physical address and size of
> each peripheral, then at offset -0x10 from the end address (usually
> at even 4K pages), if you find the magic number 0xB105F00D
> (ARM has a sense of humour, obviously) you can find something
> alike the PCI IDs at offset -0x20, manufacturer ID, version number
> and revision of the hardware.

I don't think this was ever part of the AMBA specification. It was just
some convention used within ARM for the PrimeCell peripherals. Other
AMBA licensees did something else so it's not a reliable mechanism (I
think ARM gave up on this as well in recent peripherals).

> IMO the world would have been much better off if
> ARM mandated that all vendors *must* use this scheme
> for their hardware blocks if they are to license the AMBA
> bus incarnations, but they don't.

As you said, it had limitations like not providing IRQ or DMA
information, so not entirely useful.

FDT may have its problems but so far is a more generic approach for
specifying such information.

-- 
Catalin


--
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

2011-04-06 Thread Bryan Wu
On Wed, Apr 6, 2011 at 2:11 PM, Barry Song <21cn...@gmail.com> wrote:
> 2011/4/1 Arnd Bergmann :
>> 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 technical and actionable - avoid sweeping,
>>> impossible to meet requirements. Do not require people to clean up all of 
>>> the
>>> existing mess straight away (they cannot realistically do it), do not 
>>> summarily
>>> block the flow of patches, but be firm about drawing a line in the sand and 
>>> be
>>> firm about not introducing new mess in a gradually growing list of 
>>> well-chosen
>>> areas of focus.
>>>
>>> Rinse, repeat.
>>
>> I believe getting to point 1 is the hard part here. There are a lot of things
>> that are wrong with the mach-* (and also plat-*) implementations, and I don't
>> think we have one today that can really serve as an example. Most decisions
>> made in there made a lot of sense when they were introduced, and declaring
>> code that was perfectly acceptable yesterday to be unacceptable crap today
>> is not going to be met with much understanding by the someone who just
>> wants to add support for one more board to 100 already existing ones in the
>> same SoC family.
>>
>> 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,
>> based on these observations (please correct me if some of them they don't 
>> make
>> sense):
>>
>> 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 files is growing exponentially,
>>   despite the best efforts of a handful of people to clean it up.
>> 4. Having one source file per board does not scale any more.
>> 5. Discoverable hardware would solve this, but is not going to happen
>>   in practice.
>> 6. Board firmware would not solve this and is usually not present.
>> 7. Boot loaders can not be trusted to pass valid information
>> 8. Device tree blobs can solve a lot of the problems, and nobody has
>>   come up with a better solution.
>
> ARM BSP is still blasting! we are planning to merge our new ARM
> cortex-a9 SoC into kernel.

As far as I know, Barry is working on a new SoC family based on
Cortex-A9. He asked me/Eric personally before about this issue, it is
quite confused for new comers. On one hand, they wanna follow the
mainline style to join our upstream family, on the other hand if they
duplicate some crap from other SoC families, they will bring us
trouble or more crap.

> So I am just wondering whether traditional
> ARM BSP way can still be accepted, or we must move to use device tree?
> but i have't seen any arm device tree codes enter mainline yet. but we
> can get those patches from linaro 2.6.38. So what's the plan for
> merging arm device tree?
>

I suggest you need a dedicated guy who will work on DT supporting for
your SoC. As I can tell from this thread, DT will be heavily supported
by other SoC soon.

> What i have seen is that the BSP architecture of different ARM SoC
> companies is even different.
>
> samsung has three levels:
> plat-samsung
>            plat-s3c24xx
>                     mach-s3c2410
>                     mach-s3c2440
>            plat-s5p
>                     mach-s5pv210
>                     mach-s5pv310
>
> TI has two levels:
> plat-omap
>            mach-omap1
>            mach-omap2
>
> Nvidia has one level:
> mach-tegra
>
> I didn't find any rule about what codes should be placed in what
> directories. Different companies have different ways. It looks like
> the only agreement is board files are in mach-xxx. Any suggestions for
> that?
>

That's totally frustrated for a new comer, I think. It's that possible
we do more unification firstly and then allow new comers to follow,
like:
plat-common (or just named 'plat')- common plat-common framework for
all ARM based SoC, which might contains IRQ framework, GPIO, Timer,
Clock, PWM or other common things
SoC players just need add one file to enable the platform common
things on their SoC such as plat-omap.c, plat-imx.c, plat-samsung.c
and etc.

mach-'soc' - for machine or board related code, such as mach-omap,
mach-imx .., or maybe we can also introduce mach-common to share other
machine or board layer common code. I guess it will be some machine
related API common functions.

It's just a simple idea, we still need lots of work to make that happen.

Thanks,
-Bryan

> BTW, we don't want to "dick around", which Linus has been very angry.
> we want to fix more issues this 

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-04-05 Thread Santosh Shilimkar

On 4/6/2011 3:46 AM, Linus Walleij wrote:

2011/4/5 Santosh Shilimkar:

[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 from Qualcomm has floated patches to fix it for the
ARM architecture, I just pushed him again. We use it in our
ST-Ericsson products.


I remember the post.


Ideally you'd want that to go along with the A15 timer stuff so that this
monotonic high-precision timer is also used for udelay()/mdelay().


The A15 counter which is always available and running can be used
to emulate this.

Regards
Santosh
--
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

2011-04-05 Thread Santosh Shilimkar

On 4/6/2011 3:52 AM, Linus Walleij wrote:

2011/4/5 Santosh Shilimkar:


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
working together with the local timers using clock-notifiers.


And this is because the IRQs it emits are local and thus cannot wake
the system? This sounds way backwards... A simple naïve solution
would have been to just route out an external IRQ line back from a
selected timer and into the GIC so it will be able to wake up the
system, right?


Even the GIC would be dead is certain low power modes. It's need
GIC extension to route these signals and seems that it's bit
tricky hardware implementation since the timer logic
needs to be moved to ALWAYS ON power domain.

Regards
Santosh
--
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

2011-04-05 Thread Barry Song
2011/4/1 Arnd Bergmann :
> 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 technical and actionable - avoid sweeping,
>> impossible to meet requirements. Do not require people to clean up all of the
>> existing mess straight away (they cannot realistically do it), do not 
>> summarily
>> block the flow of patches, but be firm about drawing a line in the sand and 
>> be
>> firm about not introducing new mess in a gradually growing list of 
>> well-chosen
>> areas of focus.
>>
>> Rinse, repeat.
>
> I believe getting to point 1 is the hard part here. There are a lot of things
> that are wrong with the mach-* (and also plat-*) implementations, and I don't
> think we have one today that can really serve as an example. Most decisions
> made in there made a lot of sense when they were introduced, and declaring
> code that was perfectly acceptable yesterday to be unacceptable crap today
> is not going to be met with much understanding by the someone who just
> wants to add support for one more board to 100 already existing ones in the
> same SoC family.
>
> 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,
> based on these observations (please correct me if some of them they don't make
> sense):
>
> 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 files is growing exponentially,
>   despite the best efforts of a handful of people to clean it up.
> 4. Having one source file per board does not scale any more.
> 5. Discoverable hardware would solve this, but is not going to happen
>   in practice.
> 6. Board firmware would not solve this and is usually not present.
> 7. Boot loaders can not be trusted to pass valid information
> 8. Device tree blobs can solve a lot of the problems, and nobody has
>   come up with a better solution.

ARM BSP is still blasting! we are planning to merge our new ARM
cortex-a9 SoC into kernel. So I am just wondering whether traditional
ARM BSP way can still be accepted, or we must move to use device tree?
but i have't seen any arm device tree codes enter mainline yet. but we
can get those patches from linaro 2.6.38. So what's the plan for
merging arm device tree?

What i have seen is that the BSP architecture of different ARM SoC
companies is even different.

samsung has three levels:
plat-samsung
plat-s3c24xx
 mach-s3c2410
 mach-s3c2440
plat-s5p
 mach-s5pv210
 mach-s5pv310

TI has two levels:
plat-omap
mach-omap1
mach-omap2

Nvidia has one level:
mach-tegra

I didn't find any rule about what codes should be placed in what
directories. Different companies have different ways. It looks like
the only agreement is board files are in mach-xxx. Any suggestions for
that?

BTW, we don't want to "dick around", which Linus has been very angry.
we want to fix more issues this email pointed out before we send
patches.

> 9. All interesting work is going into a handful of platforms, all of which
>   are ARMv7 based.
> 10. We do not want to discontinue support for old boards that work fine.
> 11. Massive changes to existing platforms would cause massive breakage.
> 12. Supporting many different boards with a single kernel binary is a
>    useful goal.
> 13. Infrastructure code should be cross-platform, not duplicated across
>    platforms.
> 14. 32 bit ARM is hitting the wall in the next years (Cortex-A15 is
>    actually adding PAE support, which has failed to solve this on
>    other architectures).
> 15. We need to solve the platform problem before 64 bit support comes
>    and adds another dimension to the complexity.
>
> Based on these assumptions, my preferred strategy would be to a new
> mach-nocrap directory with a documented set of rules (to be adapted when
> necessary):
>
> * Strictly no crap
>  * No board files
>  * No hardcoded memory maps
>  * No lists of interrupts and GPIOs
> * All infrastructure added must be portable to all ARMv7 based SoCs.
>  (ARMv6 can be added later)
> * 64 bit safe code only.
> * SMP safe code only.
> * All board specific information must come from a device tree and
>  be run-time detected.
> * Must use the same device drivers as existing platforms
> * Should share platform drivers (interrupt controller, gpio, timer, ...)
>  with existing platforms where appropriate.
> * Code quality takes priority over stabili

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-04-05 Thread Linus Walleij
2011/4/1 Linus Torvalds :

> 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 drivers/amba/bus.c.

Basically it requires you to get the physical address and size of
each peripheral, then at offset -0x10 from the end address (usually
at even 4K pages), if you find the magic number 0xB105F00D
(ARM has a sense of humour, obviously) you can find something
alike the PCI IDs at offset -0x20, manufacturer ID, version number
and revision of the hardware.

It isn't very hard to imagine that mechanism providing IRQ
numbers or DMA channel allocation and other such data
so it becomes more plug'n'play-ish. If the hardware had a
list of device physical whereabouts in a specific location too,
the system would be quite self-describing.

Not as sexy as the separate PCI configuration space
though, it's just hardcoded in along with the device I/O pages.

Apparently ARM pushed this in their few initial cells
and manufacturers are free to reuse this system for their
silicon. ST Microelectronics for example actually use it to
a larger extent. But since it was not mandatory and there
was no clear way on how to register magic numbers with
this system (like the PCI-SIG), it simply failed. Silicon
foundries didn't care or even know about it, neglecting to put
this 0xB105F00D in place.

IMO the world would have been much better off if
ARM mandated that all vendors *must* use this scheme
for their hardware blocks if they are to license the AMBA
bus incarnations, but they don't.

Maybe the ARM guys on the list has some background on
this?

Yours,
Linus Walleij
--
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

2011-04-05 Thread Linus Walleij
2011/4/5 Santosh Shilimkar :

> 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
> working together with the local timers using clock-notifiers.

And this is because the IRQs it emits are local and thus cannot wake
the system? This sounds way backwards... A simple naïve solution
would have been to just route out an external IRQ line back from a
selected timer and into the GIC so it will be able to wake up the
system, right?

Yours,
Linus Walleij
--
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

2011-04-05 Thread Linus Walleij
2011/4/5 Santosh Shilimkar :
> [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 from Qualcomm has floated patches to fix it for the
ARM architecture, I just pushed him again. We use it in our
ST-Ericsson products.

Ideally you'd want that to go along with the A15 timer stuff so that this
monotonic high-precision timer is also used for udelay()/mdelay().

Yours,
Linus Walleij
--
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

2011-04-05 Thread Catalin Marinas
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 DORMANT or OFF state and hence
> > you will need an additional wakeup capable clock-event
> > working together with the local timers using clock-notifiers.
> 
> So yet again, we have something that almost works but doesn't, and
> we're going to have to have board-specific hacks to work around this.
> 
> This makes the architected timers totally *pointless*.

The point of architected timers is that you now get fast access to a
stable clock source with a fixed frequency that doesn't change with
cpufreq. You can also configure the clock source to be accessible from
user space (via another kuser helper) so that you have a fast
gettimeofday implementation (useful in the graphics world). Virtual
counters are another advantage.

The architecture doesn't say much about the power domains, so
implementations are allowed to vary here. Of course it would have been
better if it did but this doesn't make the architected timers totally
pointless (compare them with the A9 timers).

-- 
Catalin


--
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

2011-04-05 Thread Russell King - ARM Linux
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 clock-event
> working together with the local timers using clock-notifiers.

So yet again, we have something that almost works but doesn't, and
we're going to have to have board-specific hacks to work around this.

This makes the architected timers totally *pointless*.
--
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

2011-04-05 Thread Marc Zyngier
On Mon, 2011-04-04 at 22:08 +0200, Linus Walleij wrote:
> 2011/4/4 Marc Zyngier :
> > 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 ourselves in today.
> >
> > As far as I know, A15 always has a set of generic timers.
> >
> > It may be that they are not available (frequency not programmed into the
> > CNTFREQ register), or that someone decided to use a better alternative
> > (for some particular interpretation of "better").
> 
> I guess this thing is inside that A15 core?
> 
> First, what happens the day any vendors start making SoCs on this is
> they turn the A15 core off whenever it is not used, loosing all state
> including this timer, I believe.

The main counter is located in an ALWAYS_ON power domain, and should
keep going whatever happens in the system.

[...]

> Second, have you taken into account the effect of changing the
> frequency of the A15 core, which is something every vendor also
> does, as you know Colin Cross already has a patch pending
> for that on the TWD localtimer which has not yet reached
> the kernel. (Or is A15 fixed frequency? Forgive my ignorance...)

Fixed frequency, with a minimal roll-over time of 40 years.

M.
-- 
Reality is an implementation detail.


--
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

2011-04-04 Thread Santosh Shilimkar

On 4/5/2011 1:38 AM, Linus Walleij wrote:

2011/4/4 Marc Zyngier:

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 ourselves in today.


As far as I know, A15 always has a set of generic timers.

It may be that they are not available (frequency not programmed into the
CNTFREQ register), or that someone decided to use a better alternative
(for some particular interpretation of "better").


I guess this thing is inside that A15 core?


Yes but the power domain partitioning can be used.


First, what happens the day any vendors start making SoCs on this is
they turn the A15 core off whenever it is not used, loosing all state
including this timer, I believe.

This forces them all to add some totally different clocksource, event and
wakeup in some always-on voltage domain and rate that higher than
the A15 timer(s). They will then implement sched_clock() and
clocksource on that instead and only use A15 for localtimers.

(Leading to the proliferation of board/SoC timer hacks discussed
so much recently...)

The only way to reuse that poor thing in practice is if you engineer
a separate power domain with stuff that is supposed to be always-on
in the A15 macro (including these timers) so vendors must implement
this so as not to loose its state. Is this the case?


Yes. From what I understood from A15 timer architeture so far is,
A15 counter is suppose to be kept in ALWAYS ON domain by Soc vendors.
That's the requirement.


Else, in effect it will only be used as clocksource and sched_clock()
with these Versatile boards where the power is always on anyway.

Second, have you taken into account the effect of changing the
frequency of the A15 core, which is something every vendor also
does, as you know Colin Cross already has a patch pending
for that on the TWD localtimer which has not yet reached
the kernel. (Or is A15 fixed frequency? Forgive my ignorance...)


This one is also addressed. The counter will run on fixed
frequency and even if the clock input has changed, the
counting will be as if the clock source is constant.
e.g
- @6 MHz, counter will increment count by 1 for every ~166 nS
- @32 KHz, counter will increment count by ~183 times for
  every ~30 ms

So overall clock-source should work in all scenario's including low
power scenario'.

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
working together with the local timers using clock-notifiers.


(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 ?

Regards
Santosh
--
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

2011-04-04 Thread Linus Walleij
2011/4/4 Marc Zyngier :
> 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 ourselves in today.
>
> As far as I know, A15 always has a set of generic timers.
>
> It may be that they are not available (frequency not programmed into the
> CNTFREQ register), or that someone decided to use a better alternative
> (for some particular interpretation of "better").

I guess this thing is inside that A15 core?

First, what happens the day any vendors start making SoCs on this is
they turn the A15 core off whenever it is not used, loosing all state
including this timer, I believe.

This forces them all to add some totally different clocksource, event and
wakeup in some always-on voltage domain and rate that higher than
the A15 timer(s). They will then implement sched_clock() and
clocksource on that instead and only use A15 for localtimers.

(Leading to the proliferation of board/SoC timer hacks discussed
so much recently...)

The only way to reuse that poor thing in practice is if you engineer
a separate power domain with stuff that is supposed to be always-on
in the A15 macro (including these timers) so vendors must implement
this so as not to loose its state. Is this the case?

Else, in effect it will only be used as clocksource and sched_clock()
with these Versatile boards where the power is always on anyway.

Second, have you taken into account the effect of changing the
frequency of the A15 core, which is something every vendor also
does, as you know Colin Cross already has a patch pending
for that on the TWD localtimer which has not yet reached
the kernel. (Or is A15 fixed frequency? Forgive my ignorance...)

(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.)

Yours,
Linus Walleij
--
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

2011-04-04 Thread Marc Zyngier
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 the existing implementations, and we're not going
> > > to shrink the existing implementations by much (maybe one to three
> > > lines.)  The only thing we gain is the ability to select an implementation
> > > at runtime.
> > 
> > I believe this last point to be rather important if we plan to have this
> > mythical single kernel covering several architectures. It's also nice
> > for the A15 to be able to use some default sched_clock() implementation
> > as a fallback if the generic timers are not available for some reason.
> 
> 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 ourselves in today.

As far as I know, A15 always has a set of generic timers.

It may be that they are not available (frequency not programmed into the
CNTFREQ register), or that someone decided to use a better alternative
(for some particular interpretation of "better").

Overall, it seems like we need some degree of flexibility to have
several sched_clock() implementations within a single image, whether it
is to support multiple platforms, or to allow a single architecture to
pick the best alternative given a set of initial conditions.

M.
-- 
Reality is an implementation detail.


--
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

2011-04-04 Thread Russell King - ARM Linux
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 existing implementations by much (maybe one to three
> > lines.)  The only thing we gain is the ability to select an implementation
> > at runtime.
> 
> I believe this last point to be rather important if we plan to have this
> mythical single kernel covering several architectures. It's also nice
> for the A15 to be able to use some default sched_clock() implementation
> as a fallback if the generic timers are not available for some reason.

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 ourselves in today.

I do hope they're not missing functionality like the GIC is - otherwise
they're just going to make the situation worse than it already is.
--
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

2011-04-04 Thread Marc Zyngier
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 function pointer at 
> > > > runtime,
> > ...
> > > > and those which share that pointer with their sched_clock() 
> > > > implementation.
> > > 
> > > Abstracting sched_clock() to be run-time selected is something that
> > > needs to be taken care of. Maybe we could have a generic sched_clock
> > > implementation that is written on top of clocksource instead of jiffies,
> > > and always select that on architectures that have a decent clocksource.
> > 
> > On Cortex-A15 with the virtualisation extensions and architected timers
> > the clocksource is implemented using a physical counter (as we want
> > wall-clock timing). But for sched_clock() we may want to use a virtual
> > counter (which is basically an offset from the physical one, set by the
> > hypervisor during guest OS switching). Marc already posted some patches
> > for this.
> 
> I had a quick look at the two patches, but I was far from impressed
> due to the apparant complexity I saw.
>
> There's no point in trying to consolidate stuff if it results in a net
> increase in the amount of code to be maintained as that just increases
> the burden, churn and maintainence headache.
> 
> Is there an easier way to consolidate it across all platforms?  I think
> so:
> 
> static DEFINE_CLOCK_DATA(cd);
> static u32 sched_clock_mask;
> static u32 (*read_sched_clock)(void);
> 
> unsigned long long notrace sched_clock(void)
> {
>   if (read_sched_clock) {
>   u32 cyc = read_sched_clock();
>   return cyc_to_sched_clock(&cd, cyc, sched_clock_mask);
>   } else {
>   /* jiffies based code */
>   }
> }
> 
> static void notrace update_sched_clock(void)
> {
>   u32 cyc = read_sched_clock();
>   update_sched_clock(&cd, cyc, sched_clock_mask);
> }
> 
> void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
> {
>   BUG_ON(bits > 32);
>   read_sched_clock = read;
>   sched_clock_mask = (1 << bits) - 1;
>   init_sched_clock(&cd, update_sched_clock, bits, rate);
> }
> 
> and then get rid of the per-platform implementations entirely - all
> that platforms then have to provide is a read function and a call to
> setup_sched_clock().

The complexity mostly comes the fact that I tried to avoid having more
runtime complexity on platforms that didn't need to select their
sched_clock() implementation at runtime (no indirection while calling
sched_clock()).

If this can be relaxed, then your implementation is definitely better.

> 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 existing implementations by much (maybe one to three
> lines.)  The only thing we gain is the ability to select an implementation
> at runtime.

I believe this last point to be rather important if we plan to have this
mythical single kernel covering several architectures. It's also nice
for the A15 to be able to use some default sched_clock() implementation
as a fallback if the generic timers are not available for some reason.

M.
-- 
Reality is an implementation detail.


--
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

2011-04-04 Thread Russell King - ARM Linux
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 pointer with their sched_clock() 
> > > implementation.
> > 
> > Abstracting sched_clock() to be run-time selected is something that
> > needs to be taken care of. Maybe we could have a generic sched_clock
> > implementation that is written on top of clocksource instead of jiffies,
> > and always select that on architectures that have a decent clocksource.
> 
> On Cortex-A15 with the virtualisation extensions and architected timers
> the clocksource is implemented using a physical counter (as we want
> wall-clock timing). But for sched_clock() we may want to use a virtual
> counter (which is basically an offset from the physical one, set by the
> hypervisor during guest OS switching). Marc already posted some patches
> for this.

I had a quick look at the two patches, but I was far from impressed
due to the apparant complexity I saw.

There's no point in trying to consolidate stuff if it results in a net
increase in the amount of code to be maintained as that just increases
the burden, churn and maintainence headache.

Is there an easier way to consolidate it across all platforms?  I think
so:

static DEFINE_CLOCK_DATA(cd);
static u32 sched_clock_mask;
static u32 (*read_sched_clock)(void);

unsigned long long notrace sched_clock(void)
{
if (read_sched_clock) {
u32 cyc = read_sched_clock();
return cyc_to_sched_clock(&cd, cyc, sched_clock_mask);
} else {
/* jiffies based code */
}
}

static void notrace update_sched_clock(void)
{
u32 cyc = read_sched_clock();
update_sched_clock(&cd, cyc, sched_clock_mask);
}

void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
{
BUG_ON(bits > 32);
read_sched_clock = read;
sched_clock_mask = (1 << bits) - 1;
init_sched_clock(&cd, update_sched_clock, bits, rate);
}

and then get rid of the per-platform implementations entirely - all
that platforms then have to provide is a read function and a call to
setup_sched_clock().

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 existing implementations by much (maybe one to three
lines.)  The only thing we gain is the ability to select an implementation
at runtime.
--
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

2011-04-04 Thread Catalin Marinas
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 sched_clock() to be run-time selected is something that
> needs to be taken care of. Maybe we could have a generic sched_clock
> implementation that is written on top of clocksource instead of jiffies,
> and always select that on architectures that have a decent clocksource.

On Cortex-A15 with the virtualisation extensions and architected timers
the clocksource is implemented using a physical counter (as we want
wall-clock timing). But for sched_clock() we may want to use a virtual
counter (which is basically an offset from the physical one, set by the
hypervisor during guest OS switching). Marc already posted some patches
for this.

-- 
Catalin


--
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

2011-04-04 Thread Nicolas Ferre
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 ones that are causing the churn that we're talking about.
>> Platforms that have been working forever and only need to get
>> the occasional bug fix are boring, i.e. not the problem.
> In the ARM tree I only know mach-at91.
> Atmel still introduces new SOCs based on ARM926EJ-S, and that makes
> perfect sense for lots of applications.
> And if they add support for a new SOC, they just copy an existing one,
> change some GPIOs, and submit it as new files (sorry, I'm over-
> simplifying here).
> And if you happen to wire your board a bit differently than they do,
> you have to patch theur generic file (in addidtion to add your own
> board file).
> And though I only know the mach-at91 closely, I'm pretty sure quite
> a number of other mach-* are not better.
> So this is actually why the ARM tree has such a bad reputation:
> lot's of code repetition, and still more of that.

Yes, certainly time has come for a change.

Note however that AT91 community is making great effort to:
- publish and maintain every single chip/board support since more than 5
years (and far before for first venerable at91rm9200) : if you recall
well, it was before most of code that appeared in arch/arm/mach-*
directories ;-)
- integrate ideas and patches from contributors for simplifying and
reducing board duplication
- try to conform to new infrastructures that are appearing on ARM Linux
for better convergence of code: gpiolib, leds, buttons, clocks (work in
progress)...

We know that work has to be done and we will for sure follow this effort
of consolidation. And remember: contributions welcomed ;-).

Best regards,
-- 
Nicolas Ferre

--
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

2011-04-04 Thread Marc Zyngier
On Mon, 2011-04-04 at 02:59 +0200, Arnd Bergmann wrote:

> Abstracting sched_clock() to be run-time selected is something that
> needs to be taken care of. Maybe we could have a generic sched_clock
> implementation that is written on top of clocksource instead of jiffies,
> and always select that on architectures that have a decent clocksource.
> Are there any platforms on ARM where that would be a bad idea? I believe
> the main reaons why they are separate is that on x86 you can use the TSC
> for sched_clock in many cases where you cannot use it for clocksource.

I've proposed a mechanism for a run-time selectable sched_clock()
implementation as part of my A15 timer patch set:
http://www.spinics.net/lists/arm-kernel/msg116891.html
and more specifically patches #10 and #11.

I'm not completely pleased with it (the fact that it embeds a copy of
the generic sched_clock() to be used as a default is properly ugly), but
maybe this could be used as a base for further discussion.

Cheers,

M.
-- 
Reality is an implementation detail.


--
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

2011-04-03 Thread Jean-Christophe PLAGNIOL-VILLARD
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 interesting.
> >
> >The ones that are causing the churn that we're talking about.
> >Platforms that have been working forever and only need to get
> >the occasional bug fix are boring, i.e. not the problem.
> In the ARM tree I only know mach-at91.
> Atmel still introduces new SOCs based on ARM926EJ-S, and that makes
> perfect sense for lots of applications.
> And if they add support for a new SOC, they just copy an existing one,
> change some GPIOs, and submit it as new files (sorry, I'm over-
> simplifying here).
at SoC level quite a lot as we do the necessarly to factorise as much as we
can you can take a look when we add the g20, g10 of g45, etc...
> And if you happen to wire your board a bit differently than they do,
> you have to patch theur generic file (in addidtion to add your own
> board file).
> And though I only know the mach-at91 closely, I'm pretty sure quite
> a number of other mach-* are not better.
> So this is actually why the ARM tree has such a bad reputation:
> lot's of code repetition, and still more of that.
On AT91 it's not anymore the case now we do start reduce the number of machine
and we not allow this anymore
> 
> >>>12. Supporting many different boards with a single kernel binary is a
> >>>  useful goal.
> >>Generally not for embedded systems (for me, a mobile PDA/phone is just a
> >>small computer with a crappy keyboard, but not an embedded system).
> >
> >True. For embedded, this would not be an important thing to do, but
> >also not hurt.
> It costs you flash space.
I disagree have a single kernel with mutliple board is very usefull as it can
allow you to have one firmware for multiple version of product. It will really
simplify the maintanance

And it's also allow to simplify kernel maintanance
> 
> >>>* Strictly no crap
> >>>   * No board files
> >>Where do you put code that needs to run very early (e.g. pinging the
> >>watchdog)?
> >
> >Don't know. I'd hope we can get fast enough to the phase where device
> >drivers get initialized.
> Nope, never happened for me :-(
> (Watchdog timeouts are often 1s or less.)
you can do a lot in 1s
you start the board dowload the code from nfs and jump in the kernel
as I do on at91sam9261ek with barebox
> 
> >>>* All board specific information must come from a device tree and
> >>>be run-time detected.
> >>What do you mean by "run-time detected"?
> >>For powerpc, we currently have the device tree as DTS in the kernel
> >>and compile and bundle it together with the kernel.
> >>As you wrote above: "Discoverable hardware [...] is not going to happen"
> >
> >I mean writing
> >
> > if (device_is_compatible(dev, SOMETHING))
> > do_something();
> >
> >instead of
> >
> >#ifdef CONFIG_SOMETHING
> > do_something();
> >#endif
> >
> >The run-time information could come from anywhere (device tree, hardware
> >registers, today one might use the board number), the important point is
> >not to assume that hardware is present just because someone enabled
> >a Kconfig option.
> Understood and I agree.
> 
> >I believe that rule is generally accepted today, but we don't always
> >enforce it.
> Without device tree, Kconfig option is the only way that really
> works today (no runtime HW detection, and same board ID with different
> setups).
you can do it already today with system_rev DTS will allow to make it more
generic and pass more information and on at91 we could easly have only few
boards. Except for few case such as really short boottime requirement this
will not impact the system on contrary

Best Regards,
J.
> Device tree in my world is just one big Kconfig option instead of
> many small...
> 
>   Detlef
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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

2011-04-03 Thread Benjamin Herrenschmidt
On Fri, 2011-04-01 at 09:39 -0700, Linus Torvalds wrote:
> 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).

Not quite :-)

On the most common non-embedded platforms the device-tree comes from the
firmware which generates it (ie, pSeries, macs, ...)

On most embedded platforms, the device-tree is either flashed separately
in a separate flash partition (and thus comes from u-boot) or is wrapped
with the kernel zImage at install time.

We have almost no case of detecting the board via some magic ID and
using that to slap a device-tree at runtime, mostly because the old
embedded platforms before most bootloaders grew the ability to pass us
the DT blob from flash, simply didn't even have such a board ID...

They did pass -some- informations but to some extent we were in a worst
position than ARM which does have them.

However, what I've observed (sadly) in practice is that many
manufacturers just ship products with bogus board IDs as well, they make
them up, often non-registered or registered to other vendors, duplicate
between products etc..., I've seen that with my Marvell based D-Link NAS
box for example.

But yes, I agree with pretty much everything you said :-) There is -one-
advantage in -one- specific case to also provide device node
representation for devices that are otherwise discoverable (PCI etc..),
which is when the device-tree can carry useful auxiliary informations
that the devices themselves don't provide. The typical example is that
growing tendency in ARM world to stick USB ethernet controllers on board
without a MAC address SEEPROM  As long as the device is soldered
(and thus can be addressed via a stable "path" of ports/hubs), it can be
useful to stick a device-node for it (and for its parent controller,
potentially PCI, etc...).


Cheers,
Ben.


--
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

2011-04-03 Thread Nicolas Pitre
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 -> board linkage must not be hard (ie, no
> platform_restart, but a board_ops.restart() etc)

We have that on ARM already.  See for example the struct machine_desc 
definition in arch/arm/include/asm/mach/arch.h.

> - An average board file is a few hundreds line long, that's it, mostly
> it hooks up to generically provided functions, tho it gets the choice of
> _which_ ones to hookup.

Again that's largely the same situation on ARM.  Taking Kirkwood for 
example (wc -l arch/arm/mach-kirkwood/*-setup.c) the average for board 
file tends to be more towards 200 lines though.  Here DT could make a 
difference by moving the statically defined board resources elsewhere.

> - It can still quirk/fixup a thing or two if needed, I thinkt it's
> useful to keep that around, as long as such "quirks" remain small and
> few. At the end of the day, if dealing with one board special case gives
> you the choice between changing a ton of infrastructure/core to
> introduce a new abstraction to deal with -that- special case vs. having
> a one liner fixup in the platform code, the later is the most sensible
> option. The hard part of course is to have sensible maintainers to make
> sure this doesn't grow back to the old mess.

Totally agreed.  I think that's the core of the issue on ARM: we simply 
aren't factoring out the duplication aggressively enough in order to 
keep the board code to the absolute minimum.  The fact that different 
SoCs are totally alien to each other never encouraged that.


Nicolas
--
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

2011-04-03 Thread Arnd Bergmann
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 code. Libata itself has
> >   been in a good shape for a long time though.
> 
> And there are platforms where libata just doesn't work but the old
> ide driver does.  My firewall with a CF card in is completely unusable
> with libata, but works fine with the old IDE driver.
> 
> That's partly caused by there being no support for the ISA IOCS16 signal
> on that hardware, so the ISA bus needs specific handling depending on
> the behaviour of the ISA device being addressed.  Yes, crap hardware,
> nothing new there.

Yes, I think that also illustrates the approach: There is no fundamental
reason why it could not be made to work with libata, but there is also
no real incentive to do the work because all users can deal with the
IDE driver being essentially in bug-fix-only maintainance.

There is the occasional discussion about removing drivers/ide, but
right now it's more valuable to keep it, and the bug fixes cause
little trouble.

> Having just looked at the clocksource stuff, there's 9 up-counting 32-bit
> clocksources which are relatively easy to port to a single piece of code.
>
> 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().

All three methods for down-counting can be abstracted as offset-readl(),
right?

> Then there's those which are either 16-bit or 32-bit, and some of those
> 16-bit implementations must use readw() to avoid bus faults.
>
> Combining all those together you end up with something pretty disgusting,
> and an initialization function taking 7 arguments (iomem pointer, name,
> rating, tick rate, size, up/down counter, clocksource flags).

I probably wouldn't use seven arguments, but put all arguments that are
typically constant per board into a data structure. Not sure we'd even
need the name unless there are a lot of cases where we'd register
multiple those clocksources at once. Size and up/down are just
flags I guess.

> Does it lead to more maintainable code?  I'm not convinced - while it
> certainly reduces the amount of code, but the reduced code is rather
> more complex.

Isn't that always the tradeoff of generalizing the code? The big win
is that we don't get new copies of the same code with slightly different
bugs and that any changes to the code that are needed for supporting
new hardware have to get reviewed by people that know it.

The disadvantage is it's more complex code.

> Would an alternative be to introduce separate mmio-32bit-up, mmio-32bit-down,
> mmio-16bit-up and mmio-16bit-down clocksources?  That also doesn't give
> me a good feeling about the result.

Just two booleans doesn't really justify separate drivers, I guess.

> Then there's those which change the cs->read function pointer at runtime,

I found omap, mxs and mxc doing that. In all cases, the differences between
the functions that are set are for parameters that depend on the CPU core
(MMIO address, 16/32 bit read), so that would be covered by the detection
logic.

> and those which share that pointer with their sched_clock() implementation.

Abstracting sched_clock() to be run-time selected is something that
needs to be taken care of. Maybe we could have a generic sched_clock
implementation that is written on top of clocksource instead of jiffies,
and always select that on architectures that have a decent clocksource.
Are there any platforms on ARM where that would be a bad idea? I believe
the main reaons why they are separate is that on x86 you can use the TSC
for sched_clock in many cases where you cannot use it for clocksource.

> And those which need to do special things (like loop until read values are
> stable) in their read functions which probably can't ever be supported by
> common code.

That's probably fine, because it's basically why we have the abstraction
at the clocksource level and not below it.

Arnd
--
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

2011-04-03 Thread Arnd Bergmann
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 generic -> board linkage must not be hard (ie, no
> platform_restart, but a board_ops.restart() etc)
> 
> - An average board file is a few hundreds line long, that's it, mostly
> it hooks up to generically provided functions, tho it gets the choice of
> _which_ ones to hookup.

I believe a machine_type is more general than a board file, i.e. what
gets described as a machine in powerpc would often currently correspond
to multiple board files, if I am not mistaken.

The fact that we have a more diverse set of hardware on ARM, and that
it's growing quicker than powerpc also means that we should try harder
to reduce duplication than is necessary there.

> - It can still quirk/fixup a thing or two if needed, I thinkt it's
> useful to keep that around, as long as such "quirks" remain small and
> few. At the end of the day, if dealing with one board special case gives
> you the choice between changing a ton of infrastructure/core to
> introduce a new abstraction to deal with -that- special case vs. having
> a one liner fixup in the platform code, the later is the most sensible
> option. The hard part of course is to have sensible maintainers to make
> sure this doesn't grow back to the old mess.

I guess quirks are fine, as long as it's not required to have a them
for each board. We can have a function that gets called for any matching
"compatible" property of the root node, but I think the default should
be not to need it eventually.

This is one area where I think I can illustrate how a gradual change
from the status quo differs from a parallel new platform implementation:
To gradually change one board file, you would convert the existing
machine description to match the compatible property of the device
tree root node and possibly at a later stage remove that code again
once it's possible to work without it.
When starting out with a fresh implementation, we first need to
change all device drivers that are used on the board to work
without a machine description, but then would not have to change
any code twice, and the work for a similar board is almost done.

Arnd
--
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

2011-04-03 Thread Benjamin Herrenschmidt
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, but a board_ops.restart() etc)

- An average board file is a few hundreds line long, that's it, mostly
it hooks up to generically provided functions, tho it gets the choice of
_which_ ones to hookup.

- It can still quirk/fixup a thing or two if needed, I thinkt it's
useful to keep that around, as long as such "quirks" remain small and
few. At the end of the day, if dealing with one board special case gives
you the choice between changing a ton of infrastructure/core to
introduce a new abstraction to deal with -that- special case vs. having
a one liner fixup in the platform code, the later is the most sensible
option. The hard part of course is to have sensible maintainers to make
sure this doesn't grow back to the old mess.

Cheers,
Ben.


--
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

2011-04-03 Thread Russell King - ARM Linux
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 code. Libata itself has
>   been in a good shape for a long time though.

And there are platforms where libata just doesn't work but the old
ide driver does.  My firewall with a CF card in is completely unusable
with libata, but works fine with the old IDE driver.

That's partly caused by there being no support for the ISA IOCS16 signal
on that hardware, so the ISA bus needs specific handling depending on
the behaviour of the ISA device being addressed.  Yes, crap hardware,
nothing new there.

> We generally try to do gradual cleanups to any kernel code that is
> worth keeping, because as you say the duplication itself causes a
> lot of friction. For particularly hard cases, doing a replacement
> implementation is an exceptional way out. What we need to find a
> consensus on is how bad the problem in arch/arm/mach-*/ is:
> 
> 1. No fundamental problem, just needs some care to clean up (your
>position, I guess), so we do do what we always do and keep doing
>gradual improvements, including treewide API changes.
> 2. Bad enough that starting a new competing implementation is easier
>because it lets us try different things more easily and reduce
>the number of treewide changes to all existing platforms.
>(this is where I think we are) Like IDE and OSS, the old code
>can still get improved and bug fixed, but concentrating on new
>code gives us better freedom to make progress more quickly.
> 3. In need of a complete replacement, like arch/ppc and a lot of
>drivers/staging. I'm not arguing that it's that bad.

Having just looked at the clocksource stuff, there's 9 up-counting 32-bit
clocksources which are relatively easy to port to a single piece of code.

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 readw() to avoid bus faults.

Combining all those together you end up with something pretty disgusting,
and an initialization function taking 7 arguments (iomem pointer, name,
rating, tick rate, size, up/down counter, clocksource flags).

Does it lead to more maintainable code?  I'm not convinced - while it
certainly reduces the amount of code, but the reduced code is rather
more complex.

Would an alternative be to introduce separate mmio-32bit-up, mmio-32bit-down,
mmio-16bit-up and mmio-16bit-down clocksources?  That also doesn't give
me a good feeling about the result.

Then there's those which change the cs->read function pointer at runtime,
and those which share that pointer with their sched_clock() implementation.

And those which need to do special things (like loop until read values are
stable) in their read functions which probably can't ever be supported by
common code.
--
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

2011-04-03 Thread Arnd Bergmann
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 is already way too big of an infrastructure in place to simply 
> > > rewrite it in parallel to new OMAP versions coming up.
> > >
> > > 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 SOC specific files eventually is the data to register with that 
> > > library code.  Nothing so complicated as grand plans or planification 
> > > that makes it look like a mountain.
> > 
> > This is exactly the question it comes down to. So far, we have focused
> > on cleaning up platforms bit by bit. Given sufficient resources, I'm
> > sure this can work. You assume that continuing on this path is the
> > fastest way to clean up the whole mess, while my suggestion is based
> > on the assumption that we can do better by starting a small fork.
> 
> I don't think any fork would gain any traction.  That would only, heh, 
> fork the work force into two suboptimal branches for quite a while, and 
> given that we're talking about platform code, by the time the new branch 
> is usable and useful the hardware will probably be obsolete.  The only 
> way this may work is for totally new platforms but we're not talking 
> about a fork in that case.

Doing it just for new platforms could be an option if we decide not
to do a fork. The potential danger there is that new platform maintainers
could feel being treated unfairly because they'd have to do much more
work than the existing ones in order to get merged.

> > The things that I see as harder to do are where we need to change the
> > way that parts of the platform code interact with each other:
> > 
> > * platform specific IOMMU interfaces that need to be migrated to common
> >   interfaces
> 
> This can be done by actually forking the platform specific IOMMU code 
> only, just for the time required to migrate drivers to the common 
> interface.

True.

> > * duplicated but slightly different header files in include/mach/
> 
> Oh, actually that's part of the easy problems.  This simply require time 
> to progressively do the boring work.
> 
> With CONFIG_ARM_PATCH_PHYS_VIRT turned on we can get rid of almost all 
> instances of arch/arm/mach-*/include/mach/memory.h already.
> 
> Getting rid of all instances of arch/arm/mach-*/include/mach/vmalloc.h 
> can be trivially achieved by simply moving the VMALLOC_END values into 
> the corresponding struct machine_desc instances.
> 
> And so on for many other files.  This is all necessary for the 
> single-binary multi-SOC kernel work anyway.

I would phrase that differently: There are multiple good reaons why we
want to get rid of conflicting mach/*.h files, but there are at least
two ways to get there.

> > * static platform device definitions that get migrated to device tree
> >   definitions.
> 
> That require some kind of compatibility layer to make the transition 
> transparent to users.  I think Grant had some good ideas for this.

Yes, there are a number of good ideas (device tree fragments,
platform_data constructors, gradually replacing platform data
with properties, and possibly some more things). We'll probably
use a combination of these, and they something is needed either
way. 

> > The example that I have in mind is the time when we had a powerpc and a
> > ppc architecture in parallel, with ppc supporting a lot of hardware
> > that powerpc did not, but all new development getting done on powerpc.
> > 
> > This took years longer than we had expected at first, but I still think
> > it was a helpful fork. On ARM, we are in a much better shape in the
> > core code than what arch/ppc was, so there would be no point forking
> > that, but the problem on the platform code is quite similar.
> 
> Nah, I don't think we want to go there at all. The problem on the 
> platform code is probably much worse on ARM due to the greater diversity 
> of supported hardware.  If on PPC moving stuff across the fork took more 
> time on a year scale than expected, I think that on ARM we would simply 
> never see the end of it.  And the incentive would not really be there 
> either, unlike when the core code is concerned and everyone is affected.

What actually took really long was getting to the point where we
could completely delete the old arch/ppc directory, and we might
never want to do the equivalent here and move all existing platforms
over to common code.

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 code. Libata itself has
  been 

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-04-01 Thread Richard Cochran
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 self contained kernel when (not if) need be.

Yes, my experience with DT on powerpc teaches me that, although DT
sounds wonderful in theory, in practice kernel/dtb/uboot form a love
triangle (or perhaps a hate triangle) where all three points must be
exactly up to date with each other. If one part is even just a month
or two too old/new, then your kernel might not boot.

Richard
--
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

2011-04-01 Thread Mark Brown
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?

> There are multiple ways of dealing with this. One way would be to
> mandate that the boot loader does the quirks, ideally as little
> as possible.

Though we then get into the issues with bootloader quality and risk 

> Another option is to have a boot wrapper with board specific code,
> which gets run between the regular boot loader and the common
> kernel entry point. We might need such a wrapper anyway to pass the
> device tree to the kernel.

This sounds an awful lot like a board file which doesn't get to use any
of the in-kernel infrastructure like bus controller drivers or chip
drivers to help which feels retrograde.  I understand where you're
coming from on this but an absolute ban feels overly restrictive here,
it seems like we'd be better off allowing board files but pushing back
strongly on anything that should be data...

> > Realistically, I don't think you will ever get away from board files.
> > The trick is probably to make them as small as possible and common to as
> > many boards as possible (like the platforms directory for PowerPC).

> Perhaps. But we can start out with strict rules and add exceptions
> later when we run out of options.

...which is pretty much what you're saying here.
--
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

2011-04-01 Thread Mark Brown
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 
>create two generic GPIO drivers each covering those two common cases, 
>and those generic drivers would simply register with the higher level 
>gpiolib code, and all the board code would have to do is to provide 
>the data for those GPIOs (register offsets, number of GPIOs, etc.).  
>Whether this data eventually comes from DT is an orthogonal issue.

For this case we actually already have the basic_mmio_gpio driver in
tree, we should be pushing for wider usage of that.
--
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

2011-04-01 Thread Nicolas Pitre
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 to simply 
> > rewrite it in parallel to new OMAP versions coming up.
> >
> > 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 SOC specific files eventually is the data to register with that 
> > library code.  Nothing so complicated as grand plans or planification 
> > that makes it look like a mountain.
> 
> This is exactly the question it comes down to. So far, we have focused
> on cleaning up platforms bit by bit. Given sufficient resources, I'm
> sure this can work. You assume that continuing on this path is the
> fastest way to clean up the whole mess, while my suggestion is based
> on the assumption that we can do better by starting a small fork.

I don't think any fork would gain any traction.  That would only, heh, 
fork the work force into two suboptimal branches for quite a while, and 
given that we're talking about platform code, by the time the new branch 
is usable and useful the hardware will probably be obsolete.  The only 
way this may work is for totally new platforms but we're not talking 
about a fork in that case.

> I think we can both agree that by equally distributing the workforce
> to both approaches, we'd be off worse than doing one of them right ;-)

Absolutely.

> > I think what is needed here is a bunch of people willing to work on such 
> > things, extracting those common patterns, and creating the 
> > infrastructure to cover them.  Once that is in place then we will be in 
> > a position to push back on code submissions that don't use that 
> > infrastructure, and be on the lookout for new patterns to emerge.
> > 
> > Just with the above I think there is sufficient work to keep us busy for 
> > a while.
> 
> That is true, and I think we will need to do this. But as far as I can tell,
> the problems that you talk about addressing are a different class from the
> ones I was thinking of, because they only deal with areas that are already
> isolated drivers with an existing API.

They are areas with the best return on the investment.  This has the 
potential of making quite a bunch of code go away quickly.  And the 
goal is indeed to keep platform code hooking into existing APIs under 
control, so that global maintenance tasks such as the one tglx did are 
less painful.  Obscure board code that no one else care about because no 
other boards share the same hardware model, and which doesn't rely on 
common kernel infrastructure, is not really a problem even if it looks 
like crap because no one will have to touch it.  And eventually the 
board will become unused and we'll just delete that code.

> The things that I see as harder to do are where we need to change the
> way that parts of the platform code interact with each other:
> 
> * platform specific IOMMU interfaces that need to be migrated to common
>   interfaces

This can be done by actually forking the platform specific IOMMU code 
only, just for the time required to migrate drivers to the common 
interface.

> * duplicated but slightly different header files in include/mach/

Oh, actually that's part of the easy problems.  This simply require time 
to progressively do the boring work.

With CONFIG_ARM_PATCH_PHYS_VIRT turned on we can get rid of almost all 
instances of arch/arm/mach-*/include/mach/memory.h already.

Getting rid of all instances of arch/arm/mach-*/include/mach/vmalloc.h 
can be trivially achieved by simply moving the VMALLOC_END values into 
the corresponding struct machine_desc instances.

And so on for many other files.  This is all necessary for the 
single-binary multi-SOC kernel work anyway.

> * static platform device definitions that get migrated to device tree
>   definitions.

That require some kind of compatibility layer to make the transition 
transparent to users.  I think Grant had some good ideas for this.

> Changing these tree-wide feels like open-heart surgery, and we'd spend
> much time trying not to break stuff that could better be used to fix
> other stuff.

Well, depends how you see it.  Sure this might cause some occasional 
breakages, but normally those should be pretty obvious and easy to fix.  
And the more we can do that stuff, the better future code adhering to the 
new model will be.

> The example that I have in mind is the time when we had a powerpc and a
> ppc architecture in parallel, with ppc supporting a lot of hardware
> that powerpc did not, but all new development getting done on powerpc.
> 
> This took years longer than we had expected at first, but I still think
> it was a helpful fork

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-04-01 Thread Arnd Bergmann
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 CPU core doesn't matter at all.  Whether it is ARM926EJ-S, 
> XScale, PJ4 or Cortex-A8/A9, _that_ is the part that is extremely well 
> maintained and abstracted already.  The focus should instead be put on 
> those platforms that are the most used irrespective of their cores.  And 
> by selecting the most used platforms, we have a greater chance to create 
> community momentum, and good examples will be spread more quickly.

Agreed.

> 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 to simply 
> rewrite it in parallel to new OMAP versions coming up.
>
> 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 SOC specific files eventually is the data to register with that 
> library code.  Nothing so complicated as grand plans or planification 
> that makes it look like a mountain.

This is exactly the question it comes down to. So far, we have focused
on cleaning up platforms bit by bit. Given sufficient resources, I'm
sure this can work. You assume that continuing on this path is the
fastest way to clean up the whole mess, while my suggestion is based
on the assumption that we can do better by starting a small fork.

I think we can both agree that by equally distributing the workforce
to both approaches, we'd be off worse than doing one of them right ;-)

> Two patterns were identified so far, and they are:
> 
> 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 
>create two generic GPIO drivers each covering those two common cases, 
>and those generic drivers would simply register with the higher level 
>gpiolib code, and all the board code would have to do is to provide 
>the data for those GPIOs (register offsets, number of GPIOs, etc.).  
>Whether this data eventually comes from DT is an orthogonal issue.

Yes, this sounds like a great idea, but it's also unrelated to whether
we'd do a new platform, or introduce this into the existing platforms.

> 2) IRQ chip drivers
> 
>Again, as Thomas observed, the same issue exists with the majority of 
>the IRQ chip drivers.  Most of them follow a common simple pattern 
>that can be abstracted in some generic library code due to their very 
>similar mode of operation.  Writing a common driver would leave the 
>board specific code with only a data table describing hardware 
>registers.

Also sounds really good.

> I think what is needed here is a bunch of people willing to work on such 
> things, extracting those common patterns, and creating the 
> infrastructure to cover them.  Once that is in place then we will be in 
> a position to push back on code submissions that don't use that 
> infrastructure, and be on the lookout for new patterns to emerge.
> 
> Just with the above I think there is sufficient work to keep us busy for 
> a while.

That is true, and I think we will need to do this. But as far as I can tell,
the problems that you talk about addressing are a different class from the
ones I was thinking of, because they only deal with areas that are already
isolated drivers with an existing API.

The things that I see as harder to do are where we need to change the
way that parts of the platform code interact with each other:

* platform specific IOMMU interfaces that need to be migrated to common
  interfaces
* duplicated but slightly different header files in include/mach/
* static platform device definitions that get migrated to device tree
  definitions.

Changing these tree-wide feels like open-heart surgery, and we'd spend
much time trying not to break stuff that could better be used to fix
other stuff.

The example that I have in mind is the time when we had a powerpc and a
ppc architecture in parallel, with ppc supporting a lot of hardware
that powerpc did not, but all new development getting done on powerpc.

This took years longer than we had expected at first, but I still think
it was a helpful fork. On ARM, we are in a much better shape in the
core code than what arch/ppc was, so there would be no point forking
that, but the problem on the platform code is quite similar.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vge

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-04-01 Thread Catalin Marinas
On Friday, 1 April 2011, Arnd Bergmann  wrote:
> On Friday 01 April 2011 23:10:04 Kevin Hilman wrote:
>> Arnd Bergmann  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 talking about.
>> > Platforms that have been working forever and only need to get
>> > the occasional bug fix are boring, i.e. not the problem.
>>
>> I'm not sure I follow the ARMv7-only thinking either.
>>
>> Picking ARMv7 only would be a good way to avoid part of the problem, but
>> IMO, it doesn't really address the root causes.  Part of the ugliness of
>> the platform-specific hackery (and the "churn" to clean some of it up)
>> is precisely due to support for multiple ARM architecture versions, and
>> the various SoCs in a family that use them.  For example, linux-omap
>> supports OMAP1 (ARMv5), OMAP2 (ARMv6), OMAP3 (ARMv7) and OMAP4 (ARMv7
>> SMP), and OMAP2/3/4 in a single binary.
>>
>> Also, since we've only very recently got to the point of being able to
>> support ARMv6 + ARMv7 UP & SMP in the same kernel, making a decision now
>> that only ARMv7 is important seems like a step backwards.  If the
>> ultimate goal is getting to a point where we have infrastrucure that can
>> be cross-SoC, surely this same infrastrucure should support multiple ARM
>> architecture revisions.
>
> Yes, forget about the ARMv7 part of my proposal, that was not a main point.
>
> If we decide to have a new clean platform variant the way I suggested,
> it would be nice to support all machines in a single kernel binary,
> and at least v6+v7 is a solved problem.
>
> Supporting a second kernel binary up to v5 with the same source is also
> simple, as would be big-endian/little-endian variants, or thumb2/arm variants.
> We might not want to do all combinations from the start though, and I would
> choose ARMv6/v7-thumb2-le simply because that's what Linaro is focusing
> on. The idea is to start with a clearly defined set, but write the code
> in a way that makes it possible to extend in other directions.

Thumb-2 is ARMv7 only. If you want a v6+v7 binary it would need to be
compiled to ARM.


-- 
Catalin
--
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

2011-04-01 Thread Arnd Bergmann
On Friday 01 April 2011 23:10:04 Kevin Hilman wrote:
> Arnd Bergmann  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 talking about.
> > Platforms that have been working forever and only need to get
> > the occasional bug fix are boring, i.e. not the problem.
> 
> I'm not sure I follow the ARMv7-only thinking either.  
> 
> Picking ARMv7 only would be a good way to avoid part of the problem, but
> IMO, it doesn't really address the root causes.  Part of the ugliness of
> the platform-specific hackery (and the "churn" to clean some of it up)
> is precisely due to support for multiple ARM architecture versions, and
> the various SoCs in a family that use them.  For example, linux-omap
> supports OMAP1 (ARMv5), OMAP2 (ARMv6), OMAP3 (ARMv7) and OMAP4 (ARMv7
> SMP), and OMAP2/3/4 in a single binary.
> 
> Also, since we've only very recently got to the point of being able to
> support ARMv6 + ARMv7 UP & SMP in the same kernel, making a decision now
> that only ARMv7 is important seems like a step backwards.  If the
> ultimate goal is getting to a point where we have infrastrucure that can
> be cross-SoC, surely this same infrastrucure should support multiple ARM
> architecture revisions.

Yes, forget about the ARMv7 part of my proposal, that was not a main point.

If we decide to have a new clean platform variant the way I suggested,
it would be nice to support all machines in a single kernel binary,
and at least v6+v7 is a solved problem.

Supporting a second kernel binary up to v5 with the same source is also
simple, as would be big-endian/little-endian variants, or thumb2/arm variants.
We might not want to do all combinations from the start though, and I would
choose ARMv6/v7-thumb2-le simply because that's what Linaro is focusing
on. The idea is to start with a clearly defined set, but write the code
in a way that makes it possible to extend in other directions.

Arnd
--
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

2011-04-01 Thread Kevin Hilman
Arnd Bergmann  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 talking about.
> Platforms that have been working forever and only need to get
> the occasional bug fix are boring, i.e. not the problem.

I'm not sure I follow the ARMv7-only thinking either.  

Picking ARMv7 only would be a good way to avoid part of the problem, but
IMO, it doesn't really address the root causes.  Part of the ugliness of
the platform-specific hackery (and the "churn" to clean some of it up)
is precisely due to support for multiple ARM architecture versions, and
the various SoCs in a family that use them.  For example, linux-omap
supports OMAP1 (ARMv5), OMAP2 (ARMv6), OMAP3 (ARMv7) and OMAP4 (ARMv7
SMP), and OMAP2/3/4 in a single binary.

Also, since we've only very recently got to the point of being able to
support ARMv6 + ARMv7 UP & SMP in the same kernel, making a decision now
that only ARMv7 is important seems like a step backwards.  If the
ultimate goal is getting to a point where we have infrastrucure that can
be cross-SoC, surely this same infrastrucure should support multiple ARM
architecture revisions.

The kernel is only part of many open-source projects, and many of these
projects are still using older hardware because it's cheap, available
and hackable.  Supporting ARMv7 only might be a win for those selling
new hardware, but not necessarily a win for the broader open-source
community.

Kevin (obviously not speaking for my new employer)
--
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

2011-04-01 Thread Uwe Kleine-König
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 SOC specific files eventually is the data to register with that 
> library code.  Nothing so complicated as grand plans or planification 
> that makes it look like a mountain.
> 
> Two patterns were identified so far, and they are:
> 
> 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 
>create two generic GPIO drivers each covering those two common cases, 
>and those generic drivers would simply register with the higher level 
>gpiolib code, and all the board code would have to do is to provide 
>the data for those GPIOs (register offsets, number of GPIOs, etc.).  
>Whether this data eventually comes from DT is an orthogonal issue.
> 
> 2) IRQ chip drivers
> 
>Again, as Thomas observed, the same issue exists with the majority of 
>the IRQ chip drivers.  Most of them follow a common simple pattern 
>that can be abstracted in some generic library code due to their very 
>similar mode of operation.  Writing a common driver would leave the 
>board specific code with only a data table describing hardware 
>registers.
> 
> A good example of such rationalization that already happened is the 
> leds-gpio driver (./drivers/leds/leds-gpio.c), or similarly the 
> gpio-keys driver (drivers/input/keyboard/gpio_keys.c).  I remember when 
> those board files were implementing their own simple drivers hooking 
> directly to the input API or the LED API.
> 
> After that let's take another identified common pattern and factorize it 
> out from board code.  That might be timers (see RMK's recent 
> sched_clock() rationalization).  That might be clocks (patches from 
> Jeremy Kerr exist and need merged). Etc.
Another one is pwm (git ls-files arch/arm | grep pwm). A general
pwm framework was already discussed on lkml and linux-embedded
(http://thread.gmane.org/gmane.linux.ports.mips.general/29037/focus=44475);
I don't know the details though.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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

2011-04-01 Thread Nicolas Pitre
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)
> > > 3. The amount of crap in platform specfic files is growing exponentially,
> > >despite the best efforts of a handful of people to clean it up.
> > > 4. Having one source file per board does not scale any more.
> > > 5. Discoverable hardware would solve this, but is not going to happen
> > >in practice.
> > > 6. Board firmware would not solve this and is usually not present.
> > > 7. Boot loaders can not be trusted to pass valid information
> > > 8. Device tree blobs can solve a lot of the problems, and nobody has
> > >come up with a better solution.
> > 
> > Right, so this is directly related to point (5) because in essence FDT
> > is a way to make undiscoverable hardware discoverable by probing the
> > tree. The `it's just data' mantra sums it up nicely.
> 
> Well, except that because of point 7, device trees are still inferior to
> having correct and complete information in hardware.

I helped with the design of a rather simple patch for ARM allowing for:

cat zImage foobar.dtb > zImage_with_dtb

Then the kernel is smart enough to detect it has a dtb on its tail and 
use it.

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 self contained kernel when (not if) need be.

> > > 9. All interesting work is going into a handful of platforms, all of which
> > >are ARMv7 based.
> > 
> > I think starting out ARMv7-only might make this more manageable but
> > there are still shed loads of pre-v7 chips out there which we should try
> > not to break.
> 
> Yes, see below: the idea is to touch as little of the existing code
> as possible, at least in the first stages.

I don't think this is a realistic approach.  See my previous mail. Once 
you start identifying concrete and well defined areas that needs 
cleaning, it is best to come up with solutions that covers as much 
existing code as possible, validating that the solution is also worth it 
in the process.  The more existing code you may cover with your cleanup, 
the more likely it will fit future hardware as well.


Nicolas
--
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

2011-04-01 Thread Nicolas Pitre
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 of 
> > >>> which
> > >>>  are ARMv7 based.
> > >> Define interesting.
> > >
> > > The ones that are causing the churn that we're talking about.
> > > Platforms that have been working forever and only need to get
> > > the occasional bug fix are boring, i.e. not the problem.
> > In the ARM tree I only know mach-at91.
> > Atmel still introduces new SOCs based on ARM926EJ-S, and that makes
> > perfect sense for lots of applications.
> 
> 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 CPU core doesn't matter at all.  Whether it is ARM926EJ-S, 
XScale, PJ4 or Cortex-A8/A9, _that_ is the part that is extremely well 
maintained and abstracted already.  The focus should instead be put on 
those platforms that are the most used irrespective of their cores.  And 
by selecting the most used platforms, we have a greater chance to create 
community momentum, and good examples will be spread more quickly.

> > >>> 12. Supporting many different boards with a single kernel binary is a
> > >>>   useful goal.
> > >> Generally not for embedded systems (for me, a mobile PDA/phone is just a
> > >> small computer with a crappy keyboard, but not an embedded system).
> > >
> > > True. For embedded, this would not be an important thing to do, but
> > > also not hurt.
> > It costs you flash space.
> 
> Well, the idea was not to force everyone to enable all options. When this
> is done right, the kernel would not be any bigger.

With many SOCs each with their own peculiarities, the kernel would 
obviously grow bigger.  But the major advantage of being _able_ to do 
that is not ultimately to have only one kernel with multi-board support 
even if in some context this has great value, but rather to enforce good 
code reuse and abstraction.

Russell suggested that we enable CONFIG_ARM_PATCH_PHYS_VIRT by 
default.  This is already one way to remove one of the most 
fundamental board specific piece of information that can be deduced at 
run time instead of having compile time constants per SOC.

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 to simply 
rewrite it in parallel to new OMAP versions coming up.

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 SOC specific files eventually is the data to register with that 
library code.  Nothing so complicated as grand plans or planification 
that makes it look like a mountain.

Two patterns were identified so far, and they are:

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 
   create two generic GPIO drivers each covering those two common cases, 
   and those generic drivers would simply register with the higher level 
   gpiolib code, and all the board code would have to do is to provide 
   the data for those GPIOs (register offsets, number of GPIOs, etc.).  
   Whether this data eventually comes from DT is an orthogonal issue.

2) IRQ chip drivers

   Again, as Thomas observed, the same issue exists with the majority of 
   the IRQ chip drivers.  Most of them follow a common simple pattern 
   that can be abstracted in some generic library code due to their very 
   similar mode of operation.  Writing a common driver would leave the 
   board specific code with only a data table describing hardware 
   registers.

A good example of such rationalization that already happened is the 
leds-gpio driver (./drivers/leds/leds-gpio.c), or similarly the 
gpio-keys driver (drivers/input/keyboard/gpio_keys.c).  I remember when 
those board files were implementing their own simple drivers hooking 
directly to the input API or the LED API.

After that let's take another identified common pattern and factorize it 
out from board code.  That might be timers (see RMK's recent 
sched_clock() rationalization).  That might be clocks (patches from 
Jeremy Kerr exist and need merged). Etc.

Eventually we won't be able to find any more identifiable patterns which 
are factorisable, and what will be left in board files is only genuine 
SOC differences.  And if all that is left is actually only data tables, 
then maybe such board files could go entirel

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-04-01 Thread Russell King - ARM Linux
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 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 working forever and only need to get
> > > the occasional bug fix are boring, i.e. not the problem.
> > In the ARM tree I only know mach-at91.
> > Atmel still introduces new SOCs based on ARM926EJ-S, and that makes
> > perfect sense for lots of applications.
> 
> 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.

If they're M3 then they're a microcontroller, and so would be using uclinux.
--
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

2011-04-01 Thread Linus Torvalds
On Fri, Apr 1, 2011 at 8:55 AM, Arnd Bergmann  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

2011-04-01 Thread Arnd Bergmann
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 files is growing exponentially,
> >despite the best efforts of a handful of people to clean it up.
> > 4. Having one source file per board does not scale any more.
> > 5. Discoverable hardware would solve this, but is not going to happen
> >in practice.
> > 6. Board firmware would not solve this and is usually not present.
> > 7. Boot loaders can not be trusted to pass valid information
> > 8. Device tree blobs can solve a lot of the problems, and nobody has
> >come up with a better solution.
> 
> Right, so this is directly related to point (5) because in essence FDT
> is a way to make undiscoverable hardware discoverable by probing the
> tree. The `it's just data' mantra sums it up nicely.

Well, except that because of point 7, device trees are still inferior to
having correct and complete information in hardware.

> > 9. All interesting work is going into a handful of platforms, all of which
> >are ARMv7 based.
> 
> I think starting out ARMv7-only might make this more manageable but
> there are still shed loads of pre-v7 chips out there which we should try
> not to break.

Yes, see below: the idea is to touch as little of the existing code
as possible, at least in the first stages.

> > 10. We do not want to discontinue support for old boards that work fine.
> 
> [...]
> 
> > Based on these assumptions, my preferred strategy would be to a new
> > mach-nocrap directory with a documented set of rules (to be adapted when
> > necessary):
> 
> This is a nice idea, but I don't think it's entirely practical:
> 
> > * Strictly no crap
> >  * No board files
> 
> 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?

There are multiple ways of dealing with this. One way would be to
mandate that the boot loader does the quirks, ideally as little
as possible.

Another option is to have a boot wrapper with board specific code,
which gets run between the regular boot loader and the common
kernel entry point. We might need such a wrapper anyway to pass the
device tree to the kernel.

> Realistically, I don't think you will ever get away from board files.
> The trick is probably to make them as small as possible and common to as
> many boards as possible (like the platforms directory for PowerPC).

Perhaps. But we can start out with strict rules and add exceptions
later when we run out of options.

> >  * No hardcoded memory maps
> >  * No lists of interrupts and GPIOs
> 
> This is largely just data, so should be do-able once this stuff isn't
> needed at compile-time (which is becoming the case with stuff like
> dynamic p2v).

Right.

Arnd
--
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

2011-04-01 Thread Arnd Bergmann
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 interesting.
> >
> > The ones that are causing the churn that we're talking about.
> > Platforms that have been working forever and only need to get
> > the occasional bug fix are boring, i.e. not the problem.
> In the ARM tree I only know mach-at91.
> Atmel still introduces new SOCs based on ARM926EJ-S, and that makes
> perfect sense for lots of applications.

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.

> >>> 12. Supporting many different boards with a single kernel binary is a
> >>>   useful goal.
> >> Generally not for embedded systems (for me, a mobile PDA/phone is just a
> >> small computer with a crappy keyboard, but not an embedded system).
> >
> > True. For embedded, this would not be an important thing to do, but
> > also not hurt.
> It costs you flash space.

Well, the idea was not to force everyone to enable all options. When this
is done right, the kernel would not be any bigger.

> >>> * Strictly no crap
> >>>* No board files
> >> Where do you put code that needs to run very early (e.g. pinging the
> >> watchdog)?
> >
> > Don't know. I'd hope we can get fast enough to the phase where device
> > drivers get initialized.
> Nope, never happened for me :-(
> (Watchdog timeouts are often 1s or less.)

1s is a long time. Most of the boot process is drivers anyway, so we
just need to make sure that the watchdog is early enough.

> > I believe that rule is generally accepted today, but we don't always
> > enforce it.
> Without device tree, Kconfig option is the only way that really
> works today (no runtime HW detection, and same board ID with different
> setups).

I believe that has never been an accepted way of doing things, you are
supposed to get a new board ID for every new board, hence the name ;-).

ARnd
--
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

2011-04-01 Thread Will Deacon
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,
> based on these observations (please correct me if some of them they don't make
> sense):
> 
> 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 files is growing exponentially,
>despite the best efforts of a handful of people to clean it up.
> 4. Having one source file per board does not scale any more.
> 5. Discoverable hardware would solve this, but is not going to happen
>in practice.
> 6. Board firmware would not solve this and is usually not present.
> 7. Boot loaders can not be trusted to pass valid information
> 8. Device tree blobs can solve a lot of the problems, and nobody has
>come up with a better solution.

Right, so this is directly related to point (5) because in essence FDT
is a way to make undiscoverable hardware discoverable by probing the
tree. The `it's just data' mantra sums it up nicely.

> 9. All interesting work is going into a handful of platforms, all of which
>are ARMv7 based.

I think starting out ARMv7-only might make this more manageable but
there are still shed loads of pre-v7 chips out there which we should try
not to break.

> 10. We do not want to discontinue support for old boards that work fine.

[...]

> Based on these assumptions, my preferred strategy would be to a new
> mach-nocrap directory with a documented set of rules (to be adapted when
> necessary):

This is a nice idea, but I don't think it's entirely practical:

> * Strictly no crap
>  * No board files

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?

Realistically, I don't think you will ever get away from board files.
The trick is probably to make them as small as possible and common to as
many boards as possible (like the platforms directory for PowerPC).

>  * No hardcoded memory maps
>  * No lists of interrupts and GPIOs

This is largely just data, so should be do-able once this stuff isn't
needed at compile-time (which is becoming the case with stuff like
dynamic p2v).

Will

--
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

2011-04-01 Thread Arnd Bergmann
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 working forever and only need to get
the occasional bug fix are boring, i.e. not the problem.
 
> > 12. Supporting many different boards with a single kernel binary is a
> >  useful goal.
> Generally not for embedded systems (for me, a mobile PDA/phone is just a
> small computer with a crappy keyboard, but not an embedded system).

True. For embedded, this would not be an important thing to do, but
also not hurt. For anything that a user might want to put a new
kernel on, this would be helpful though.

> >
> > Based on these assumptions, my preferred strategy would be to a new
> > mach-nocrap directory with a documented set of rules (to be adapted when
> > necessary):
> >
> > * Strictly no crap
> >   * No board files
> Where do you put code that needs to run very early (e.g. pinging the
> watchdog)?

Don't know. I'd hope we can get fast enough to the phase where device
drivers get initialized.
 
> >   * No hardcoded memory maps
> >   * No lists of interrupts and GPIOs
> > * All infrastructure added must be portable to all ARMv7 based SoCs.
> >(ARMv6 can be added later)
> > * 64 bit safe code only.
> > * SMP safe code only.
> > * All board specific information must come from a device tree and
> >be run-time detected.
> What do you mean by "run-time detected"?
> For powerpc, we currently have the device tree as DTS in the kernel
> and compile and bundle it together with the kernel.
> As you wrote above: "Discoverable hardware [...] is not going to happen"

I mean writing

if (device_is_compatible(dev, SOMETHING))
do_something();

instead of

#ifdef CONFIG_SOMETHING
do_something();
#endif

The run-time information could come from anywhere (device tree, hardware
registers, today one might use the board number), the important point is
not to assume that hardware is present just because someone enabled
a Kconfig option.

I believe that rule is generally accepted today, but we don't always
enforce it.

> > * Must use the same device drivers as existing platforms
> > * Should share platform drivers (interrupt controller, gpio, timer, ...)
> >with existing platforms where appropriate.
> > * Code quality takes priority over stability in mach-nocrap, but must not
> >break other platforms.
> 
> I agree with the general idea, but nailing down the details in a world
> as diverse as the ARM world will not be easy...

Absolutely, I did not claim to have the single solution that everyone else
couldn't see. Please see this more as an RFC.

Arnd
--
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

2011-04-01 Thread Arnd Bergmann
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 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.
> 
> The reason that we've ended up with a flat heirarchy in terms of
> developers is down to pressure.  There was a time when we had a more
> structured system, where the sub-tree people submitted their patches
> to me and the list, they'd be reviewed (mostly and mostly only) by me
> before being merged into my tree and going upstream from there.
> 
> As the community grew, it got harder and harder to do decent reviewed
> of those patches and so the acceptance rate dropped.
> 
> Eventually we switched to the current arrangement where I'm essentially
> only concerned about core ARM code, and a few platforms which I have
> personal interest in (or are contracted to look after.)
> 
> For the rest I just look at the patches, and send back what feedback I
> can on them (which is mostly when my mailer turns a line red because
> it's matched one of my mutt regexps for spotting common mistakes.)

Thanks for the background information.

> > This would be no easier if everyone was asking you to pull their trees,
> > as I believe was the case before that. The amount of code getting changed
> > there is too large to get reviewed by a single person, and I believe
> > neither of you really wants the burden to judge if all of the branches
> > are ok (and complain to the authors when they are not).
> 
> Absolutely right - and the problem is that we still have no one who is
> willing to step up and do the review.
> 
> What I was promised at the time was that by giving sub-tree maintainers
> the loaded pistol, this problem of code quality would in effect be self-
> correcting.  If they make a hash out of it, they'd have to be the ones
> to fix it themselves.
> 
> Instead, what's happening is that the _entire_ ARM community, ARM
> hardware manufacturers and so forth is being blamed here.

This is not my impression. A lot of people are pointing out that there
are problems, and how they perceive them, but I don't think that anyone
really wants to blame the entire community.  Even less I believe that
people that understand the situation are blaming you personally.

> > Russell, do you think it would help to have an additional ARM platform
> > tree that collects all the changes that impact only the platform code but
> > not the core architecture? I believe that would be a way out, but requires
> > a careful selection of people responsible for it. In particular, I don't
> > think a single person can handle it without good sub-maintainers.
> 
> It's not that simple, as what happens when we have core ARM code updates
> which ends up touching every single board file?  The result is conflicts
> between trees, and that could get extremely messy indeed.

I believe that conflicts between two trees are really not the issue,
we have tools to solve those in multiple ways, e.g. by pulling in such
updates from a topic branch into both trees, or by declaring one of
the two trees the master that can pull in the other one occasionally
in order to resolve the conflicts.

> To be honest, given the politics, I don't want to be the one stuck in the
> middle, receiving and endless stream of Linus' complaints about the way
> the ARM community works, or the board support code.  However, inspite of
> the sub-tree maintainers having the responsibility for their own code I
> still find myself in the firing line.

I think that is partly a perception problem on your side. Understandably,
you still identify yourself with all of the code under arch/arm, so
if someone says that the ARM architecture code has problems, you take
it personally, even though the problems that are cited are almost
exclusively for code that you are not responsible for.

> And I have got to the point of just not giving a damn.  I can't change
> the ARM community (I've tried over the years to get more active review
> of platform changes and failed - and had it pointed out by folk like
> Alan Cox, that such a system is impossible due to lack of motivation
> by, eg, an OMAP person to review a Samsung change.)

I think we're actually just getting there. You were not the only one
to point out the problem and Linaro was specifically founded to solve
this issue, as far as I can tell. 

Arnd
--
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

2011-04-01 Thread Arnd Bergmann
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 technical and actionable - avoid sweeping, 
> impossible to meet requirements. Do not require people to clean up all of the 
> existing mess straight away (they cannot realistically do it), do not 
> summarily 
> block the flow of patches, but be firm about drawing a line in the sand and 
> be 
> firm about not introducing new mess in a gradually growing list of 
> well-chosen 
> areas of focus.
> 
> Rinse, repeat.

I believe getting to point 1 is the hard part here. There are a lot of things
that are wrong with the mach-* (and also plat-*) implementations, and I don't
think we have one today that can really serve as an example. Most decisions
made in there made a lot of sense when they were introduced, and declaring
code that was perfectly acceptable yesterday to be unacceptable crap today
is not going to be met with much understanding by the someone who just
wants to add support for one more board to 100 already existing ones in the
same SoC family.

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,
based on these observations (please correct me if some of them they don't make
sense):

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 files is growing exponentially,
   despite the best efforts of a handful of people to clean it up.
4. Having one source file per board does not scale any more.
5. Discoverable hardware would solve this, but is not going to happen
   in practice.
6. Board firmware would not solve this and is usually not present.
7. Boot loaders can not be trusted to pass valid information
8. Device tree blobs can solve a lot of the problems, and nobody has
   come up with a better solution.
9. All interesting work is going into a handful of platforms, all of which
   are ARMv7 based.
10. We do not want to discontinue support for old boards that work fine.
11. Massive changes to existing platforms would cause massive breakage.
12. Supporting many different boards with a single kernel binary is a
useful goal.
13. Infrastructure code should be cross-platform, not duplicated across
platforms.
14. 32 bit ARM is hitting the wall in the next years (Cortex-A15 is
actually adding PAE support, which has failed to solve this on
other architectures).
15. We need to solve the platform problem before 64 bit support comes
and adds another dimension to the complexity.

Based on these assumptions, my preferred strategy would be to a new
mach-nocrap directory with a documented set of rules (to be adapted when
necessary):

* Strictly no crap
 * No board files
 * No hardcoded memory maps
 * No lists of interrupts and GPIOs
* All infrastructure added must be portable to all ARMv7 based SoCs.
  (ARMv6 can be added later)
* 64 bit safe code only.
* SMP safe code only.
* All board specific information must come from a device tree and
  be run-time detected.
* Must use the same device drivers as existing platforms
* Should share platform drivers (interrupt controller, gpio, timer, ...)
  with existing platforms where appropriate.
* Code quality takes priority over stability in mach-nocrap, but must not
  break other platforms.

Until we have something working there, I think we should still generally
allow new code to the existing platforms, and even new platforms to be
added, while trying to keep the quality as high as possible but without
changing the rules for them or doing any major treewide reworks.

Once the mach-nocrap approach has turned into something usable, we can
proceed on three fronts:
1. delete actively maintained boards from the other platforms once they
   are no longer needed there
2. generalize concepts from mach-nocrap by applying them to all boards,
   similar to the cleanup work that people have always been doing.
3. gradually make the rules for adding new code in other platforms stricter,
   up to the point where they are bugfix only.

> If companies do not 'bother to push upstream', then management will 
> eventually 
> notice negative economic consequences:
> 
> ...

Good points, I fully agree with these. I also think that the SoC companies
are actually understanding this nowadays, and that is exactly the reason
why we see so much code getting pushed in.

Arnd
--
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 a

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-04-01 Thread Arnd Bergmann
On Thursday 31 March 2011, Bill Gatliff wrote:
> On Thu, Mar 31, 2011 at 8:01 AM, Russell King - ARM Linux 
>  wrote:

> > Just look at the removal of AAEC2000, LH7A40x and 2000 lines from the
> > mach-types file removed 6000 lines, which in itself is about the number
> > of lines of change submitted during the last merge window for any one
> > non-ARM architecture.  At this point in time with this complaint, I've
> > absolutely no idea why I bothered to do that.  I should've left it well
> > alone and then the diffstat percentage would've been smaller.  After
> > all, it's "pointless churn".
> 
> I think you did it because it was the Right Thing To Do.  Even
> positive change can be painful at times.
> 
> The majority is exceedingly grateful for the effort you make.

Defintely. I haven't seen anyone in this thread blame Russell for the
mess. As far as I'm concerned, the code in arch/arm consists of
the well-maintained {mm,kernel,lib,common,tools,include} directories
that are actively being taken care of by Russell, and a huge amount
of crap that has accumulated in mach-* and plat-*. Some of it is
arguably better than other parts, but the problem is not that someone
in particular did a bad job writing the code. The problem is that
nobody today is pushing back hard enough on crap getting added.

There is a lot of good work going on to reduce the amount of crap in
the mach code, but my feeling is that it's not keeping up with the
rate of crap getting added by other people. In some ways, the Linaro
project has actually made this worse by helping people get their code
into shape for inclusion (which of course is generally a good thing
to do).

Arnd
--
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

2011-04-01 Thread Tomi Valkeinen
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 back quite hard on some of the aspects there, which probably
> prevented it from going in so far. If the code is as much based on
> the OMAP DSS as I think, quite a number of changes are required to
> both in order to get them into shape for a decent cross-platform layer,
> but there should not be any fundamental issues.

I only looked it briefly, but I'm not sure if there's that much code
that could be common. But I need to read the mail thread properly.

The driver for the display HW on the SoC doesn't probably have anything
in common with OMAP one. What could and should be common is the panel
side, which was just a single patch in that patch set.

 Tomi


--
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

2011-04-01 Thread Arnd Bergmann
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
prevented it from going in so far. If the code is as much based on
the OMAP DSS as I think, quite a number of changes are required to
both in order to get them into shape for a decent cross-platform layer,
but there should not be any fundamental issues.

Arnd
--
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

2011-04-01 Thread Tomi Valkeinen
(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 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 abstractions in mind.
> > 
> > If you mean the panel drivers, then I disagree. They are currently OMAP
> > specific, but they are designed so that making them generic shouldn't be
> > too difficult. It's been my aim for a long time already to make the
> > panel drivers generic, but I've never had time and it's never been quite
> > clear to me what would be the best way to do that.
> > 
> > The core DSS driver is OMAP specific, and while the DSS IP could in
> > theory be used in some other platform, that is not currently the case
> > and I wouldn't want to needlessly start abstracting things for just the
> > sake of abstracting.
> 
> Ok, fair enough. I haven't looked at the OMAP DSS code in detail, so
> I apologise if I did it injustice. What I did review is the ST Ericsson
> MCDE code which was written by taking the OMAP code as an example.
> 
> The symptom I'm describing is that infrastructure is getting added
> to platform specific code without making clear that it is mean to
> be generic. I.e. the code is hidded away in the drivers/video/omap
> directory, where other people would not go looking for it.
> 
> What I would have hoped you to do is to tell the ST Ericsson people
> when they posted their code that they should instead work with you
> to integrate the two implementations. As far as I remember (I may be
> wrong again), that did not happen.

I don't seem to remember seeing anything from ST Ericsson... While my
memory doesn't always serve me well, I would imagine I'd remember if I'd
seen code based on my code.

Ah, found them from fbdev mail archive. I was rather busy at that
period, I didn't really read the mailing lists.

I totally agree with you that we should have a common panel interface
layer. As I said, I've had it as a target for a long time. And hopefully
now that I moved from Nokia to TI I'll finally have time to work on it
also.

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.

 Tomi


--
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

2011-04-01 Thread Arnd Bergmann
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 there are more obvious examples than the ones I've
given, those were just the ones that I had noticed myself.
 
> Even the OMAP "consolidated" code is silly:
>
> But the code above has 6 cases in the switch because nobody abstracted
> it out consequently. Not to talk about the ifdef mess.

Nice illustration.

Arnd
--
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

2011-04-01 Thread Arnd Bergmann
On Thursday 31 March 2011, Kevin Hilman wrote:
> Arnd Bergmann  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 are actually actively working infrastructure that is
> cross SoC, like runtime PM.  It might start because of an abstraction
> within an SoC family like supporting both SH and SH-mobile, or
> OMAP[12345], but it does sometimes result in not only cross-SoC code but
> cross-platform frameworks.
> 
> Admiteddly, the percentage of ARM SoC developers actively working on
> these common, cross-platform infrastructure layers is rather small, but
> at least it is non-zero. :)

True, I was oversimplifying. Still, the problem exists that to a large
degree, infrastructure also gets added to platform specific code where it
has no place.

> With that as background, hwmod was never inteded as something to be
> cross-SoC.  If you look at the data that's in an omap_hwmod, it's
> entirely OMAP hardware specific, and mostly focused on power management
> hardware details, register descriptions, feature capabilities etc.  This
> allows the OMAP PM core code to be generalized and work across all SoCs
> in the OMAP family.  But again, it was intended for OMAP PM core code.
> At that level, there really isn't much to share with other SoCs since
> the PM hardware for the various SoC vendors is so "differentiated"
> (a.k.a fsck'd up in extremely different ways.)

There is an important difference between code that knows about board,
soc and platform specific issues ("drivers") and code that manages
these ("infrastructure"). Obviously, any hardware implementation, broadly
speaking, that is different from the other ones needs a driver.

However, the infrastructure for managing multiple drivers should be
written in a way that works for as many similar drivers as possible.

My complaint about the four examples I've given is that they mix the
driver with the infrastructure.

Arnd
--
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

2011-04-01 Thread Arnd Bergmann
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 clearly not written with
> >   cross-vendor abstractions in mind.
> 
> If you mean the panel drivers, then I disagree. They are currently OMAP
> specific, but they are designed so that making them generic shouldn't be
> too difficult. It's been my aim for a long time already to make the
> panel drivers generic, but I've never had time and it's never been quite
> clear to me what would be the best way to do that.
> 
> The core DSS driver is OMAP specific, and while the DSS IP could in
> theory be used in some other platform, that is not currently the case
> and I wouldn't want to needlessly start abstracting things for just the
> sake of abstracting.

Ok, fair enough. I haven't looked at the OMAP DSS code in detail, so
I apologise if I did it injustice. What I did review is the ST Ericsson
MCDE code which was written by taking the OMAP code as an example.

The symptom I'm describing is that infrastructure is getting added
to platform specific code without making clear that it is mean to
be generic. I.e. the code is hidded away in the drivers/video/omap
directory, where other people would not go looking for it.

What I would have hoped you to do is to tell the ST Ericsson people
when they posted their code that they should instead work with you
to integrate the two implementations. As far as I remember (I may be
wrong again), that did not happen.

Arnd
--
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

2011-04-01 Thread Ingo Molnar

* David Brown  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 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 technical and actionable - avoid sweeping, 
impossible to meet requirements. Do not require people to clean up all of the 
existing mess straight away (they cannot realistically do it), do not summarily 
block the flow of patches, but be firm about drawing a line in the sand and be 
firm about not introducing new mess in a gradually growing list of well-chosen 
areas of focus.

Rinse, repeat.

If companies do not 'bother to push upstream', then management will eventually 
notice negative economic consequences:

 - Higher short-term production costs: upstream feedback/review/testing
   improves the product, so the lack of upstream feedback/review/testing
   increases the production costs of the product.

 - Higher long-term production costs: gradually slower SoC development due to a 
   morass of out-of-tree hacks that werent pushed upstream causing gradually 
   higher development costs. This means higher payroll costs and longer time to
   market - in which time more flexible competitors can beat you.

 - Brain drain: developers like to show their good work upstream as well, not
   just in some ship-and-forget out-of-tree kernel. Good developers will
   gravitate towards SoC companies that encourage them to work upstream.
   No matter how good of a business idea a company has if there's no good 
   developers.

 - Less revenue: a product can not possibly be more appealing to SoC customers
   if the upstream Linux kernel does not support it. As ARM moves up the food 
   chain towards more complex, higher profit margin products longer term 
   thinking gains foothold gradually.

 - Competitive disadvantages: most SoC competitors push their changes upstream,
   so they get free development assistance, they get free exposure, they get 
   free PR and they get opportunities. Not pushing upstream is a lost 
   opportunity.

All of these effects translate into real $$$ and affect the bottom line 
very directly, both short and long term. These costs also increase with time so 
they are not fixed.

If management does not actively encourage upstream-quality changes then 
management will have to justify why they exposed the company to these extra 
costs, complications and risks - just to save on the relatively minor (and 
fixed) cost of working with upstream.

If despite all that management still believes (rightly or wrongly) that it's 
cheaper for the company to do low quality throw-away code and does not care 
about any of the short and long-term costs listed above then this really means 
that they really do not care about you or about the upstream kernel - so they 
do not exist as far as the upstream kernel is concerned.

Why should you then reward them with pulling crap and why should you be willing 
to invest future maintenance overhead into their "we do not care about you" 
solution?

Working with upstream is a quid pro quo with plenty of advantages on both 
sides, which gives maintainers a heck of a leverage to push back on crap while 
still having all the incentives in the world to help produce a high quality 
kernel.

Thanks,

Ingo
--
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

2011-04-01 Thread Tomi Valkeinen
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 abstractions in mind.

If you mean the panel drivers, then I disagree. They are currently OMAP
specific, but they are designed so that making them generic shouldn't be
too difficult. It's been my aim for a long time already to make the
panel drivers generic, but I've never had time and it's never been quite
clear to me what would be the best way to do that.

The core DSS driver is OMAP specific, and while the DSS IP could in
theory be used in some other platform, that is not currently the case
and I wouldn't want to needlessly start abstracting things for just the
sake of abstracting.

 Tomi


--
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

2011-03-31 Thread David Brown
On Thu, Mar 31 2011, Nicolas Pitre wrote:

> Leaf nodes on ARM are people coming from corporate background with the 
> old school software development methodologies.  They do it as a _job_ 
> first and foremost.  They only work on Linux because that's what their 
> boss assigned them to. Don't get me wrong: that doesn't mean they are 
> bad people.  Simply that they are not into it for the public recognition 
> (or flaming) from their peers.  Once their code works they lose interest 
> and move on.  That mindset is extremely hard to change and take time, on 
> a scale of years.  Much more time than required to produce the code 
> needed to support that new SOC out of the pipeline.  There are notable 
> exceptions obviously.  But this is still a scalability problem in 
> itself.  So we need men-in-the-middle attacks.

An additional mindset that is difficult to work with in this environment
is that the corporate development methodology has a focus on schedules
and deliverables.  Even people who would otherwise like to contribute
will have pressure to get something done.  Many think of "submit to
mainline" is kind of a last step in a development process, instead of
even a goal to accomplish.

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.  Practically, someone just sent out a
fairly complete DMA driver for a new MSM device.  Naturally, this
hardware is nothing like anyone else's DMA, but the driver itself pretty
much independent from other kernel APIs.  It isn't even similar to the
existing DMA driver in the MSM.  With it are patches to ifdef-up various
drivers to use the appropriate DMA.

The DMA code, by itself, seems reasonably well written (with some
cleanup and such needed), but it makes everything that uses it messy.
In this particular case, DMA engine will probably need some work to
either incorporate the unique capabilities of this hardware, or at least
allow them to be used.  The author probably won't be able to do this on
their own.

I could pull the driver into the tree, and now we have yet another
driver with yet another API.  If I push back, realistically, it will
probably end up out-of-tree, along with everything that depends on it.

Up until now, it seems that attitude has been that it is better to be
in-tree than out of tree, but are we getting too much stuff to continue
that?

Today, most of the MSM code lives out of tree.  The QuIC tree for MSM
(currently based off of 2.6.35):

  git diff --stat v2.6.35..HEAD | tail -1
   3432 files changed, 1144473 insertions(+), 17315 deletions(-)
  git diff --stat v2.6.35..HEAD arch/arm/mach-msm | tail -1
   595 files changed, 286054 insertions(+), 1928 deletions(-)

There's a large amount of work just to get the code up to kernel
standards (the coding style has been fairly well enforced), and there is
constant development for new hardware.

Thanks,
David Brown

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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

2011-03-31 Thread Mark Brown
On Thu, Mar 31, 2011 at 12:56:33AM +0200, Thomas Gleixner wrote:
> On Wed, 30 Mar 2011, Tony Lindgren wrote:
> > * Thomas Gleixner  [110330 15:22]:
> > > On Wed, 30 Mar 2011, Tony Lindgren wrote:

> > > > One thing that will help here and distribute the load is to move
> > > > more things under drivers/ as then we have more maintainers looking
> > > > at the code.

> > > Guess what's that going to solve? Nothing, nada.

> > > Really, you move the problem to people who are not prepared to deal
> > > with the wave either. So what's the gain?

> > I guess my point is that with creating more common frameworks people
> > will be using common code. Some examples that come to mind are clock
> > framework, gpiolib, dma engine, runtime PM and so on.

> For all that to happen you need a really experienced team with a
> strong team lead to fight that through and go through the existing
> horror while dealing  with the incoming flood at the same time.

My experience is that it's not that bad doing this providing you can
convince people to actually show their code to the relevant subsystem
maintainers and they have time to look at the code.  The first step is
reasonably tractable since it's a fairly basic level of review and as a
subsystem maintainer you're well enough motivated to at least ensure
that people aren't breaking the abstractions enough to cause problems
for anyone but the people directly working with the drivers.
--
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

2011-03-31 Thread Mark Brown
On Wed, Mar 30, 2011 at 03:14:10PM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux  [110330 14:05]:

> > And I have got to the point of just not giving a damn.  I can't change
> > the ARM community (I've tried over the years to get more active review
> > of platform changes and failed - and had it pointed out by folk like
> > Alan Cox, that such a system is impossible due to lack of motivation
> > by, eg, an OMAP person to review a Samsung change.)

> I think this is happening more and more as we have more ARM generic
> and Linux generic code.

Plus you've now got some non-trivial code for off-SoC devices which
means you've got a growing number of people who do actively work over
many SoCs.
--
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

2011-03-31 Thread Mark Brown
On Thu, Mar 31, 2011 at 06:49:11PM -0400, Nicolas Pitre wrote:
> On Thu, 31 Mar 2011, Linus Torvalds wrote:

> > 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.
> 
> Leaf nodes on ARM are people coming from corporate background with the 
> old school software development methodologies.  They do it as a _job_ 
> first and foremost.  They only work on Linux because that's what their 
> boss assigned them to. Don't get me wrong: that doesn't mean they are 
> bad people.  Simply that they are not into it for the public recognition 
> (or flaming) from their peers.  Once their code works they lose interest 
> and move on.  That mindset is extremely hard to change and take time, on 
> a scale of years.  Much more time than required to produce the code 
> needed to support that new SOC out of the pipeline.  There are notable 
> exceptions obviously.  But this is still a scalability problem in 
> itself.  So we need men-in-the-middle attacks.

It's also often the case that the leaf maintainers are themselves
overloaded with work, especially those who don't have much code in tree
already or who have advanced power management features in their devices
that they're trying to support (which tend to be the area that requires
most work as they're system wide in impact).  

> > 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?

> Embedded vendors did keep their code out of the kernel before.  We've 
> been hammering them about upstreaming their code for years.  Now they 
> are striking back with too much code for our review capacity.  So 
> problematic code gets merged without anyone noticing because it compiles 
> and does work, until someone comes along with a wide scale API cleanup 
> and stumble on it.

Plus the fact that even if the code isn't of the quality we'd ideally
like you do tend to get *some* quality improvement from pushing things
into mainline simply by virtue of 1000 foot review and it's much more
likely that random people will come along and contribute improvements to
mainline than to vendor BSPs.  Speaking as someone who works over many
different embedded CPUs (not just ARM) I'm generally thankful when I'm
working with mainline code, even if it's not the mainline code I might
dream of.  There are some great out of tree BSPs but there's also
others.
--
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

2011-03-31 Thread Nicolas Pitre
On Thu, 31 Mar 2011, Linus Torvalds wrote:

> On Thu, Mar 31, 2011 at 12:25 PM, Nicolas Pitre  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.

True.  My remark about core kernel people still stands though.

> 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.

Leaf nodes on ARM are people coming from corporate background with the 
old school software development methodologies.  They do it as a _job_ 
first and foremost.  They only work on Linux because that's what their 
boss assigned them to. Don't get me wrong: that doesn't mean they are 
bad people.  Simply that they are not into it for the public recognition 
(or flaming) from their peers.  Once their code works they lose interest 
and move on.  That mindset is extremely hard to change and take time, on 
a scale of years.  Much more time than required to produce the code 
needed to support that new SOC out of the pipeline.  There are notable 
exceptions obviously.  But this is still a scalability problem in 
itself.  So we need men-in-the-middle attacks.

> 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.

I wish we could be sufficient people to be able to determine what we 
actually don't like about the code.  There is simply not enough core 
kernel people with the required visibility doing such work in ARM land.  
That's the fundamental problem.  The fact that the most successful 
"real" ARM devices running Linux out there still aren't supported in 
mainline doesn't help building a community of enthusiasts around it 
either.

> > 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?

Embedded vendors did keep their code out of the kernel before.  We've 
been hammering them about upstreaming their code for years.  Now they 
are striking back with too much code for our review capacity.  So 
problematic code gets merged without anyone noticing because it compiles 
and does work, until someone comes along with a wide scale API cleanup 
and stumble on it.

The alternative is to only accept fully reviewed code, but to scale with 
the numbers we've all seen, 60% of the reviewers should be looking at 
ARM code and that's not happening.  We've been there before, like two 
years ago or so. Pressure builds up at the maintainer gate as the 
backlog grows and key people get burned out, then the system collapses.  
No one wants to go back there.

> > 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".

DT has to prove itself on ARM with a few existing platforms before we 
can open the flood gate towards it.  If something is wrong with DT 
support it is best to fix only the core stuff without also having to fix 
all users and possibly all bootloaders, etc.  That work is progressing 
slowly because there are more people praising DT than people doing the 
actual work.


Nicolas


Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-03-31 Thread Thomas Gleixner
On Thu, 31 Mar 2011, Nicolas Pitre wrote:
> 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 does that, and 
> maybe less than a handful of other important people I'm not listing 
> (sorry).  But clearly we are far far from being enough people doing that 
> kind of work.  And the fact is that the volume of ARM platform code is 
> steadily being produced at a rate far surpassing X86, and even higher 
> than all the other architectures put together.  Linaro is trying to help 
> here, but Linaro cannot conjure the needed experience and knowledge for 
> that kind of work with a magic wand.
> 
> 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 

The main help we can give (aside of actually looking at code and
concepts) is to feed back the experience we have with massive cleanups
and which mechanisms work and which not and - at least I can speak for
myself - to stand at your side when it comes to pushing that through.

One thing what really helps to force people to get their act together
is that you as maintainers identify trouble spots which are easily
addressable. Then put those spots on your list and require people who
want to submit new features in that area to cleanup the mess first and
then put their new feature thing on top. We successfully used this to
get the unification work after the mechanical i386/x86_64 merger
done. It requires a lot of stubborness, but it reduces the work burden
of the maintainers a lot.

Once you have the easy spots addressed, that could be device tree
stuff, gpio, irq_chips for the beginning and see how it works out,
then go steps further.

The important point here is from my POV that you put down the
requirements with no wiggle room and just ignore the "oh it could be
done better" whining. Either people come up with a patch which solves
the whole issue better or they just will cope. But when you have
consolidated stuff then you can and need to look from a high level
perspective and refine the infrastructure.

I really regret in hindsight, that I did not enforce the cleanup of
the irq layer way earlier and that I did not see the abuse of it early
enough. At some point I realized that being polite is the wrong
solution, so I forced myself to push this cleanup through. That's an
experience which I don't wish anybody else to make. Especially because
as long as the oldstyle stuff works oldstyle crap comes in faster than
you can fix it. See commit 9ad198c. And it's a massive effort to do
something which results in:

Total patches: 414
Total files touched:   702  
Total insertions: 6805
Total deletions:  8632
Lines added  -1827

And that massive effort is just because you cannot break stuff after
the fact in a massive scale. The whole thing introduced a mere 6
patches fixup fallout which were applied one day after rc1. It could
have been avoided, but 

So yes, we can and will help with advise, a certain amount of review
(especially on the concept level) and giving you all the support you
need to fight that trough.

Thanks,

tglx
--
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

2011-03-31 Thread Linus Torvalds
On Thu, Mar 31, 2011 at 1:05 PM, Linus Torvalds
 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

2011-03-31 Thread Kevin Hilman
Arnd Bergmann  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 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 are actually actively working infrastructure that is
cross SoC, like runtime PM.  It might start because of an abstraction
within an SoC family like supporting both SH and SH-mobile, or
OMAP[12345], but it does sometimes result in not only cross-SoC code but
cross-platform frameworks.

Admiteddly, the percentage of ARM SoC developers actively working on
these common, cross-platform infrastructure layers is rather small, but
at least it is non-zero. :)

> Allow me to use OMAP as a bad example while pointing out that it's
> really one of the best supported platforms we currently have, while
> the others are usually much worse in terms of working with the
> community (or at least they are behind on the learning curve but
> getting there):
>
> * OMAP2 introduced the hwmod concept as an attempt to reduce duplication
 >   between board code, but the code was done on the mach-omap2 level
>   instead of finding a way to make it work across SOC vendors, or using
>   an existing solution.

Well, before deciding whether something like hwmod should be a cross-SoC
abstraction, it's important to be clear about what level of abstraction
is needed, or practical for a given feature.  For power management, we
already have (and use) existing abstractions for the drivers.  The clock
framework, system PM and runtime PM framework are all existing
abstraction layers for drivers.

Remember that power management is one of those areas that ARM SoC
vendors like to "differentiate" on, so the hardware is vastly different
between ARM vendors.  Having worked on embedded Linux power management
for a while now, I currently do not think any cross-SoC abstractions
below the clock framework or runtime PM are worth it.  I'm certainly
willing to be pursuaded otherwise, but currently don't see the
usefulness.

With that as background, hwmod was never inteded as something to be
cross-SoC.  If you look at the data that's in an omap_hwmod, it's
entirely OMAP hardware specific, and mostly focused on power management
hardware details, register descriptions, feature capabilities etc.  This
allows the OMAP PM core code to be generalized and work across all SoCs
in the OMAP family.  But again, it was intended for OMAP PM core code.
At that level, there really isn't much to share with other SoCs since
the PM hardware for the various SoC vendors is so "differentiated"
(a.k.a fsck'd up in extremely different ways.)

Kevin
--
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

2011-03-31 Thread Linus Torvalds
On Thu, Mar 31, 2011 at 12:25 PM, Nicolas Pitre  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

2011-03-31 Thread Nicolas Pitre
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 does that, and 
maybe less than a handful of other important people I'm not listing 
(sorry).  But clearly we are far far from being enough people doing that 
kind of work.  And the fact is that the volume of ARM platform code is 
steadily being produced at a rate far surpassing X86, and even higher 
than all the other architectures put together.  Linaro is trying to help 
here, but Linaro cannot conjure the needed experience and knowledge for 
that kind of work with a magic wand.

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.

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.

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.

Also there is some work to be able to build a kernel supporting more 
than one SOC family at once.  Of course there is no practical use for a 
single kernel binary that boots on all existing boards, but moving 
towards such a goal has beneficial side effects such as good 
consolidation when possible.

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.


Nicolas
--
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

2011-03-31 Thread Linus Torvalds
On Thu, Mar 31, 2011 at 10:56 AM, Nicolas Pitre  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 th

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-03-31 Thread Thomas Gleixner
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 many
> > sources which are relevant. This makes sense in all aspects:
> > 
> >   1) less and better code
> >   2) faster setup for new SoCs
> >   3) shared benefit for all vendors
> 
> If this was always true.  Someone commented on the fact that the IP 
> block providing USB on OMAP is shared with a couple other platforms.  
> But about 2600 lines of pure glue is still necessary around the common 
> driver to make it work for everyone.  I'm not saying that separate 
> drivers are called for here, simply that hardware people _will_ screw it 
> up, especially when they are hooking it up to a non-standard 
> SOC-specific bus.

Right. That's a problem, but we should not ignore the places where
reusing stuff is easy possible. And making good examples out of it.

And it really _IS_ worth the trouble. Look at the git log of
drivers/spi/pxa2xx* . We could have slapped the other "x86" driver
into spi, but that does not make any sense from a software engineering
and maintainability POV. And it would have been more work in the end
to cleanup the separate driver than isolating the existing one and
reuse it.

This is a sustainability issue. And we need to become more clever
about identifying the places where we can abstract stuff into shared
drivers and infrastructure when we want to sustain Linux for another
few decades.

> And what would the hardware guys tell you?  That software is cheap.

If you can prove with simple examples that using existing software
removes 6 month of useless reinventing the wheel and another 6 month
of testing plus the fight with the kernel folks, then eventually they
start to listen as you can express this in $$$.

Thanks,

tglx
--
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

2011-03-31 Thread Thomas Gleixner
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 is just because 
> > there
> > is so much variation in ARM"
>
> 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.  Instead this only 
> creates despair and the splashed people may simply decide to throw in 
> the towel, at which point things will collapse for real.  In reality, 
> the system has been going as it is for quite a while and with more or 
> less the same level of intensity.  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.

And that's the whole point why I was ranting in the first place. I
know that there are clever folks working on the solution, but it's
entirely clear to me, that they are simply not enough compared to the
massive inbound flood. So neither you nor Russell can cope with it,
you simply do not scale. That's why I suggested that the ARM community
needs to push competent man power into this.

You say the concept of subarch maintainers is working quite well. That
depends on the definition of working. It works in terms of users can
use it, but it does not work from a maintainability POV.

Nobody wants to bash on those who are working on it, but IMNSHO the
current way is running into an utter nightmare even w/o you and
Russell throwing in the towel.

I went through quite a few iterations of large scale cleanups, so I
know how you feel.

Thanks,

tglx


--
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

2011-03-31 Thread Jesse Barnes
On Thu, 31 Mar 2011 19:17:51 +0100
Russell King - ARM Linux  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
> > > particularly want to deal with ARM defconfig changes anymore.
> > 
> > I thought we solved this with the introduction of "make savedefconfig"
> > that created much much smaller defconfig.
> 
> Did we solve it to Linus' satisfaction, or did we solve it sufficiently
> to avoid the immediate threat of them all being removed and we still have
> work to do?  I've no idea.
> 
> Personally, I'd still like to see less of them but without significantly
> impacting the usefulness of automated built tooks like Simtec's
> kautobuild.

Might be neat if kbuild could wget config files automatically from a
known location.  Bonus points if it properly detected the right one to
grab in the first place...

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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

2011-03-31 Thread Nicolas Pitre
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 sense in all aspects:
> 
>   1) less and better code
>   2) faster setup for new SoCs
>   3) shared benefit for all vendors

If this was always true.  Someone commented on the fact that the IP 
block providing USB on OMAP is shared with a couple other platforms.  
But about 2600 lines of pure glue is still necessary around the common 
driver to make it work for everyone.  I'm not saying that separate 
drivers are called for here, simply that hardware people _will_ screw it 
up, especially when they are hooking it up to a non-standard 
SOC-specific bus.

Another example: there used to be many different IP blocks providing 
MMC/SD/SDIO support that people were adding to their SOCs.  Each SOC 
would have its own reinvention of the wheel but they were all different 
but simple wheels, and drivers for them were obvious and straight 
forward.  Then came the SDHCI "standard".  At first few implementation 
existed so the sdhci driver was, too, rather straight forward.  But 
hardware manufacturers thought (rightfully) that this would be a good 
idea to use that standard instead of using their custom simple wheel.  
And so they did, releasing new SOC revision with the old wheel replaced 
by a square implementation of the sdhci one.  Today the sdhci driver is 
literally bastardized by all the quirks needed to work around all the 
different and creative bugs or even standard misinterpretation of the 
standard out there in the field.  And in many cases the sdhci version is 
even _less_ functional than the custom and already supported 
implementation it replaced.

And what would the hardware guys tell you?  That software is cheap.


Nicolas
--
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

2011-03-31 Thread Russell King - ARM Linux
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 the introduction of "make savedefconfig"
> that created much much smaller defconfig.

Did we solve it to Linus' satisfaction, or did we solve it sufficiently
to avoid the immediate threat of them all being removed and we still have
work to do?  I've no idea.

Personally, I'd still like to see less of them but without significantly
impacting the usefulness of automated built tooks like Simtec's
kautobuild.
--
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

2011-03-31 Thread Sam Ravnborg
> 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 smaller defconfig.
At least the defconfigs should be down in the noise level in the
diffstats.

We can always argue about the usefullness of the 100+ defconfigs,
that is still unreadable.
But at least they no longer dominate the diffs (if people remember
to use "make savedefconfig".

Sam
--
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

2011-03-31 Thread Koen Kooi

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 IRQ controllers, different keyboard
>>> controllers (USB), PCI Express, an IOMMU, NCQ SATA, ACPI, graphics
>>> running in shared host memory able to give/take pages from the host,
>>> extra instructions, etc etc
>>> 
>>> And the same kernel boots just fine on both just fine.
>> 
>> We've been there for a long time with ARM.  Right from the start I had
>> a single kernel image which booted over a range of ARM CPUs and
>> platforms.
>> 
>> As far as ARM CPU architectures go, today we can have a single kernel
>> image which covers ARMv3 to ARMv5, and a separate kernel image which
>> covers ARMv6 to ARMv7 including SMP and UP variants.  The thing which
>> currently stops ARMv3 to ARMv7 all together is the different page table
>> layouts, the ASID tagging, the exclusive load/store support for cmpxchg
>> and other atomic operations, etc.
> 
> I don't think the push is to get a single kernel image that boots absolutly 
> everywhere. having separate ARM5 and ARM7 kernels doesn't seem to be a big 
> deal to anyone.

You mean ARMv5 and ARMv7, right? ARM5 and ARM7 are completely different things.

The short, but inaccurate version:

ARM9 -> ARMv4t, ARMv5te*
ARM11 -> ARMv6*
CORTEX-A* -> ARMv7a

regards,

Koen--
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

2011-03-31 Thread Alexander Holler

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 peripherals for ten years, but the SoC people haven't
really taken them up - and when they do, they seem to always introduce
their own tweaks, sometimes with no way to detect those tweaks.


As a user of several ARM boards I fully agree. I've come to the 
conclusion that if device tree or something similiar won't come up, 
which offers a vendor independent description of the hardware, the ARM 
market (at least with Linux as an OS) won't function. It's already 
almost impossible to update an old vendor kernel to a mainline kernel 
version without having schematics. Up to now this isn't a big problem 
because most ARM-HW people are playing with are developer boards, but 
thats already changing and more and more stuff will come without schematics.
And without the help of something like the x86 BIOS (or DT for ARM) you 
are just lost using an ARM-HW where you don't have the schematics, when 
you don't want to use the vendor provided kernel sources (for which you 
almost never get e.g. any security fixes). Finding all the small knobs 
to turn out of vendor provided kernel sources is a pain and just a waste 
of time you almost never can't finish before the HW in question got 
obsolete.


Just my 2¢ on that topic from a somewhat user point of view from one who 
isn't really involved that much in kernel development.


At least I find such a rant from Linus from time to time a good thing. 
Sometimes it helps if someone speaks out loud whats wrong. And if Linus 
wouldn't be that one, who else would be courageous enough to do that? I 
wouldn't (and I can't, I have to thank all kernel developers for their 
hard work).


Regards,

Alexander

--
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

2011-03-31 Thread Nicolas Pitre
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 ARM"

The problem is two-fold:

1) - "ARM hardware manufacturers are morons"... 
   - ARM vendors "do things differently just to be difficult"...
   - "the crazy arm fragmentation"...
   Translate this into whatever ways you like.  The fact is that ARM
   is quite popular as a CPU core but there is very little in terms of 
   standardization around that CPU core.  *OBVIOUSLY* this is a problem.
   But there is _nothing_ we can do about that besides the current 
   moaning and the hope that those vendors will hear us and stop trying 
   to be different from their competitors.  Apparently that won't happen 
   in the near future, so we can either sit on our arses proclaiming 
   repeatedly that this is a problem until those hardware vendors put 
   their acts together, or we find ways to deal with it somehow.

2) Because of (1) we do end up being floded by SOC specific support code
   with an unprecedented scale.  Here's the stat:

   $ git diff --shortstat v2.6.38..v2.6.39-rc1 arch/arm/
1319 files changed, 61303 insertions(+), 33780 deletions(-)
   $ git diff --shortstat v2.6.38..v2.6.39-rc1 arch/x86/
241 files changed, 6508 insertions(+), 4326 deletions(-)

   That's ten (10) times more lines added in the ARM directory than in 
   the X86 directory.  Is this a sudden burst or a tendency?

   $ git diff --shortstat v2.6.37..v2.6.38 arch/arm/
1257 files changed, 72412 insertions(+), 29361 deletions(-)
   $ git diff --shortstat v2.6.37..v2.6.38 arch/x86/
216 files changed, 10021 insertions(+), 5016 deletions(-)

   $ git diff --shortstat v2.6.36..v2.6.37 arch/arm/
1314 files changed, 55072 insertions(+), 17620 deletions(-)
   $ git diff --shortstat v2.6.36..v2.6.37 arch/x86/
299 files changed, 16130 insertions(+), 12800 deletions(-)

   $ git diff --shortstat v2.6.35..v2.6.36 arch/arm
1041 files changed, 53428 insertions(+), 25722 deletions(-)
   $ git diff --shortstat v2.6.35..v2.6.36 arch/x86/
231 files changed, 7216 insertions(+), 8028 deletions(-)

   So that appears to be quite "normal" to see ARM vendors together 
   producing many times the level of activities compared to X86.

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.

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.  Instead this only 
creates despair and the splashed people may simply decide to throw in 
the towel, at which point things will collapse for real.  In reality, 
the system has been going as it is for quite a while and with more or 
less the same level of intensity.  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.


Nicolas

--
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

2011-03-31 Thread david

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 IOMMU, NCQ SATA, ACPI, graphics
running in shared host memory able to give/take pages from the host,
extra instructions, etc etc

And the same kernel boots just fine on both just fine.


We've been there for a long time with ARM.  Right from the start I had
a single kernel image which booted over a range of ARM CPUs and
platforms.

As far as ARM CPU architectures go, today we can have a single kernel
image which covers ARMv3 to ARMv5, and a separate kernel image which
covers ARMv6 to ARMv7 including SMP and UP variants.  The thing which
currently stops ARMv3 to ARMv7 all together is the different page table
layouts, the ASID tagging, the exclusive load/store support for cmpxchg
and other atomic operations, etc.


I don't think the push is to get a single kernel image that boots 
absolutly everywhere. having separate ARM5 and ARM7 kernels doesn't seem 
to be a big deal to anyone.



Outside of the CPU architecture, things become a lot more complicated.


exactly, and this is where there is an issue.


The biggest one up until this merge window was that there is no fixed
address for system RAM, which makes stuff like virt_to_phys() rather
horrible to deal with - which in turn makes setting up and walking page
tables a nightmare.  We've just solved that issue with run-time patching
of the kernel code to replace the add/sub instructions with ones with
the appropriate offset, so we're a step closer to unifying everything
into one single kernel image.  This work alone produced this diffstat:

87 files changed, 450 insertions(+), 190 deletions(-)

so it actually resulted in a net increase in the amount of code to be
maintained rather than reducing it.  That's hardly surprising as what
that replaced was just a bunch of #define's for PHYS_OFFSET with some
complex assembly code to do run-time patching of instructions.


but I don't think this sort of work is what anyone is complaining about.


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.


it sounds like you are part of the solution, not part of the problem. the 
biggest problem is the general response from 'the ARM community' when 
these sorts of issues are raised claiming that there is no problem. you 
seem to be very aware of the problem and are working to fix it. that is a 
very different situaion.


David Lang

--
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

2011-03-31 Thread Linus Torvalds
On Thu, Mar 31, 2011 at 9:45 AM, Russell King - ARM Linux
 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

2011-03-31 Thread Thomas Gleixner
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.
> 
> But that's the point. The incentive is there for managing the infrastructure
> within the SoC, but not across SoCs. Allow me to use OMAP as a bad example
> while pointing out that it's really one of the best supported platforms
> we currently have, while the others are usually much worse in terms of
> working with the community (or at least they are behind on the learning
> curve but getting there):
> 
> * OMAP2 introduced the hwmod concept as an attempt to reduce duplication
>   between board code, but the code was done on the mach-omap2 level
>   instead of finding a way to make it work across SOC vendors, or using
>   an existing solution.
> 
> * The IOMMU code in omap2 duplicates the API we have in the common kernel,
>   with slight differences, instead of using the existing code, making it
>   impossible to share a driver between SOC families.
> 
> * The ti-st code duplicates parts of the bluetooth layer (apparently
>   that is getting fixed soon).
> 
> * 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 abstractions in mind.

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.

Even the OMAP "consolidated" code is silly:

static void _set_gpio_dataout(struct gpio_bank *bank, int gpio, int enable)
{
void __iomem *reg = bank->base;
u32 l = 0;

switch (bank->method) {
#ifdef CONFIG_ARCH_OMAP1
case METHOD_MPUIO:
reg += OMAP_MPUIO_OUTPUT / bank->stride;
l = __raw_readl(reg);
if (enable)
l |= 1 << gpio;
else
l &= ~(1 << gpio);
break;
#endif
#ifdef CONFIG_ARCH_OMAP15XX
case METHOD_GPIO_1510:
reg += OMAP1510_GPIO_DATA_OUTPUT;
l = __raw_readl(reg);
if (enable)
l |= 1 << gpio;
else
l &= ~(1 << gpio);
break;
#endif
#ifdef CONFIG_ARCH_OMAP16XX
case METHOD_GPIO_1610:
if (enable)
reg += OMAP1610_GPIO_SET_DATAOUT;
else
reg += OMAP1610_GPIO_CLEAR_DATAOUT;
l = 1 << gpio;
break;
#endif
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
case METHOD_GPIO_7XX:
reg += OMAP7XX_GPIO_DATA_OUTPUT;
l = __raw_readl(reg);
if (enable)
l |= 1 << gpio;
else
l &= ~(1 << gpio);
break;
#endif
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
case METHOD_GPIO_24XX:
if (enable)
reg += OMAP24XX_GPIO_SETDATAOUT;
else
reg += OMAP24XX_GPIO_CLEARDATAOUT;
l = 1 << gpio;
break;
#endif
#ifdef CONFIG_ARCH_OMAP4
case METHOD_GPIO_44XX:
if (enable)
reg += OMAP4_GPIO_SETDATAOUT;
else
reg += OMAP4_GPIO_CLEARDATAOUT;
l = 1 << gpio;
break;
#endif
default:
WARN_ON(1);
return;
}
__raw_writel(l, reg);
}

So we have 2 types of sections:

#1
  data = read_reg();
  if (enable)
 data |= bit;
  else
 data &= ~bit;
  write_reg(data);

#2
  if (enable)
 write_enable_reg(bit);
  else
 write_disable_reg(bit);

But the code above has 6 cases in the switch because nobody abstracted
it out consequently. Not to talk about the ifdef mess.

So now look at tons of other gpio implementations all over the DOZENS
of ARM plat-/mach- space and guess what.

Most have either type #1 or type #2 just slightly different copied,
less or better abstracted and I'm pretty damned sure, that you could
consolidate all that stuff into a handful or even less drivers which
provide the code across the board.

Same for irq chips. Most of these gpio things have callbacks which do:

irq_xxx(struct irq_data *d)
{
gpio = irq_data_get_irq_chip_data(d);
irq = d->irq - gpio->base_irq;
reg = convert_to_reg(gpio, irq);
mask = convert_to_mask(gpio);

write(reg, mask);
}

I saw all those incarnations lately and you can boil them down to a
handful or less as

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-03-31 Thread Russell King - ARM Linux
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' 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.
--
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

2011-03-31 Thread david

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 you realize and appreciate that you really have not
understood the problem i think.


No, I think it is the other way around.  Folk like me and Nicolas over
the last ten years have put considerable amounts of effort into trying
to keep the ARM support code as clean and maintainable as possible.


In this case I owe you and Nicolas an apology.

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 ARM"


Linus does look at the code he pulls, if he is pulling changesets that are 
described as consolodations and cleanups, he won't be whining about code 
churn.


but if he is just pulling chnagesets that are described as "addsupport for 
board X" or "modify defconfig defaults" he is going to complain.


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. It's that the changes are conflicting 
with each other (due to things like central config tables that multiple 
people are updating in different ways) and the same files getting modified 
frequently, many times in ways that don't seem to have a clear direction 
(defconfigs for example)


David Lang
--
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

2011-03-31 Thread david

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  writes:



Yes, ARM SoC maintainers have to make up some ground.  But compare this
to just a couple years ago where the common complaint was "why aren't
embedded SoC people contributing code to mainline", and you'll see we
have come a long way.


Well, code comes in, which is progress. But we need to figure out how
to deal with the increasingly growing flood before we drown in it.


How about we declare the remainder of this cycle and the next merge window
as being only for bug and regression fixes, and consolidation of stuff like
the IRQ controller and GPIO controller code for the next merge window?


well, now that -rc1 has been released, the remainder of this cycleis 
already only bug and regression fixes.


declaring the next merge window as the same may or may not help, depending 
on if it pushes people to do more consolodations work or just delay 
submitting the work they are doing.


David Lang
--
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

2011-03-31 Thread Arnd Bergmann
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 for managing the infrastructure
within the SoC, but not across SoCs. Allow me to use OMAP as a bad example
while pointing out that it's really one of the best supported platforms
we currently have, while the others are usually much worse in terms of
working with the community (or at least they are behind on the learning
curve but getting there):

* OMAP2 introduced the hwmod concept as an attempt to reduce duplication
  between board code, but the code was done on the mach-omap2 level
  instead of finding a way to make it work across SOC vendors, or using
  an existing solution.

* The IOMMU code in omap2 duplicates the API we have in the common kernel,
  with slight differences, instead of using the existing code, making it
  impossible to share a driver between SOC families.

* The ti-st code duplicates parts of the bluetooth layer (apparently
  that is getting fixed soon).

* 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 abstractions in mind.

Arnd
--
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

2011-03-31 Thread Russell King - ARM Linux
On Thu, Mar 31, 2011 at 05:01:40PM +0200, Thomas Gleixner wrote:
> On Thu, 31 Mar 2011, Kevin Hilman wrote:
> 
> > Thomas Gleixner  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. 
> > 
> > zero incentive?  that's a bit strong, IMO.
> > 
> > That may be true for some SoCs, it's not really fair as a sweeping
> > statement.
> 
> Fair enough, but it's the perception in general.
> 
> > Conference (ELC, US and Europe.)  Especially as IP blocks are reused
> > across SoC families, abstractions like runtime PM are the only way to
> > keep the SoC specifics of PM out of the common driver.
> 
> Right, I know that these things happen, but at the same time the sheer
> amount of stuff flowing in makes it hard that these infrastructure
> stuff really works out. And we are only at the beginning of the big
> shuffle "code in to mainline" game.
> 
> After cleaning up the whole irq stuff across the tree I can tell you,
> that the mess is non-linear growing with the number of instances.
> 
> You can see the patterns which are:
> - copy and paste
> - introduce different bugs
> - add more abuse
> 
> That's what I'm really concerned about.
> 
> > Yes, ARM SoC maintainers have to make up some ground.  But compare this
> > to just a couple years ago where the common complaint was "why aren't
> > embedded SoC people contributing code to mainline", and you'll see we
> > have come a long way.
> 
> Well, code comes in, which is progress. But we need to figure out how
> to deal with the increasingly growing flood before we drown in it.

How about we declare the remainder of this cycle and the next merge window
as being only for bug and regression fixes, and consolidation of stuff like
the IRQ controller and GPIO controller code for the next merge window?
--
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

2011-03-31 Thread Thomas Gleixner
On Thu, 31 Mar 2011, Kevin Hilman wrote:

> Thomas Gleixner  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. 
> 
> zero incentive?  that's a bit strong, IMO.
> 
> That may be true for some SoCs, it's not really fair as a sweeping
> statement.

Fair enough, but it's the perception in general.

> Conference (ELC, US and Europe.)  Especially as IP blocks are reused
> across SoC families, abstractions like runtime PM are the only way to
> keep the SoC specifics of PM out of the common driver.

Right, I know that these things happen, but at the same time the sheer
amount of stuff flowing in makes it hard that these infrastructure
stuff really works out. And we are only at the beginning of the big
shuffle "code in to mainline" game.

After cleaning up the whole irq stuff across the tree I can tell you,
that the mess is non-linear growing with the number of instances.

You can see the patterns which are:
- copy and paste
- introduce different bugs
- add more abuse

That's what I'm really concerned about.

> Yes, ARM SoC maintainers have to make up some ground.  But compare this
> to just a couple years ago where the common complaint was "why aren't
> embedded SoC people contributing code to mainline", and you'll see we
> have come a long way.

Well, code comes in, which is progress. But we need to figure out how
to deal with the increasingly growing flood before we drown in it.

Thanks,

tglx

--
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

2011-03-31 Thread Bill Gatliff
Russell:


On Thu, Mar 31, 2011 at 8:01 AM, Russell King - ARM Linux
 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 think the defconfigs are as important as the code itself! Sure there
is a lot of churn in them--- just let git deal with it and move on.

The defconfigs and board code provide critical reference models for
new platform developers.  If these models aren't right, then you end
up providing bad references that get replicated over and over again.
It multiplies the problem we're trying to solve.

> Just look at the removal of AAEC2000, LH7A40x and 2000 lines from the
> mach-types file removed 6000 lines, which in itself is about the number
> of lines of change submitted during the last merge window for any one
> non-ARM architecture.  At this point in time with this complaint, I've
> absolutely no idea why I bothered to do that.  I should've left it well
> alone and then the diffstat percentage would've been smaller.  After
> all, it's "pointless churn".

I think you did it because it was the Right Thing To Do.  Even
positive change can be painful at times.

The majority is exceedingly grateful for the effort you make.


b.g.

-- 
Bill Gatliff
b...@billgatliff.com
--
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

2011-03-31 Thread Kevin Hilman
Thomas Gleixner  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. 

zero incentive?  that's a bit strong, IMO.

That may be true for some SoCs, it's not really fair as a sweeping
statement.

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.

There are several examples of SoC maintainers looking at the overall
picture and contributing to better abstractions and common
infrastructure code.

One is USB as Felipe already pointed out where the same USB OTG IP block
(with vendor tweaks of course) is used across several completely
different SoCs with common infrastructure code.

Another example that I'm more familiar with is power management.  In
OMAP land, we have been been very supportive and active in generic
infrastructure improvements (like runtime PM.)  In fact runtime PM was
born partially because one of the other ARM SoC maintainers (Magnus
Damm, SH-mobile) proposed the idea as he was implementing PM for that
SoC family.  We have been actively contributing to the runtime PM
infrastructure with both code, testing, converting our drivers over to
using runtime PM. and contributing back fixes and enhancements as we
find problems or limitations.  In addition, personally, I have spent the
last year evangelizing the importance of using common frameworks like
runtime PM to the embedded community via talks at the Embedded Linux
Conference (ELC, US and Europe.)  Especially as IP blocks are reused
across SoC families, abstractions like runtime PM are the only way to
keep the SoC specifics of PM out of the common driver.

Yes, ARM SoC maintainers have to make up some ground.  But compare this
to just a couple years ago where the common complaint was "why aren't
embedded SoC people contributing code to mainline", and you'll see we
have come a long way.

Kevin

Maintainer of parts of the ARM kernel:
- TI Davinci SoC family
- TI OMAP Power Management infrastructure
--
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

2011-03-31 Thread Thomas Gleixner
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 of queueing patches until something gets resolved one way
> or the other.  I'm not even going to review any patches because I currently
> see it as a total waste of time - I've no idea whether they'll stand any
> chance what so ever of making it into mainline.
> 
> What's the way out of this?  I've no idea.  Can ARM continue being part
> of the mainline kernel?  I've no idea.  Will we be ripping out all the
> ARM platform code from the mainline kernel?  I've no idea.

Moving arm out of mainline would be a complete disaster.
 
> I am now completely demotivated.

I can understand that, but I have to say again, that you do a pretty
damned good job on keeping the ARM core code clean and I always enjoy
working with you when infrastructure I'm working on needs to deal with
ARM requirements. We disagree from time to time, but I don't remember
a single incident where we could not resolve that on a technical base.

It's not your fault, that you can't clone yourself 10 times to deal
with the subarch flood. It's also not your fault that the subarch
maintainers tend not to look over the brim of their SoC sandbox and
figure out how to solve the big picture.

So no, ARM needs to stay and the ARM crowd needs to find competent
people who babysit the SoC crowd and work with you to get the big
picture straight. Something like this should have been done _before_
the wave of ARM spilling out of every other silicon shop became
tsunami sized. But not doing it at all will not solve anything.

Thanks,

tglx
--
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

2011-03-31 Thread Arnd Bergmann
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 to pay a large enough
> > compensation for pain and suffering. 
> 
> If I understand correctly, this is exactly what Linaro would need to do.

Absolutely. Getting the work done that each of the SoC vendors needs but
none of them would do on their own is the main reason why Linaro is there,
so if we can agree what needs to be done, I'm sure we can find someone
to do it.

Arnd
--
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

2011-03-31 Thread Thomas Gleixner
On Wed, 30 Mar 2011, Linus Torvalds wrote:

> On Wed, Mar 30, 2011 at 6:15 PM, Bill Gatliff  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.

Well, ARM is not the only one there, it's the top one, but mips and
power are not less crazy. Here are the top five architectures counted
in number of irq_chip implementations.

  arch/arm 139
  arch/mips75
  arch/powerpc 44
  arch/alpha   21
  arch/x86 15

Thanks,

tglx

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-03-31 Thread Russell King - ARM Linux
On Thu, Mar 31, 2011 at 12:41:52PM +0200, Ingo Molnar wrote:
> * 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 you realize and appreciate that you really have 
> > > not 
> > > understood the problem i think.
> > 
> > No, I think it is the other way around.  Folk like me and Nicolas over the 
> > last ten years have put considerable amounts of effort into trying to keep 
> > the ARM support code as clean and maintainable as possible.
> 
> Absolutely no argument about that, whenever i have read core ARM code it was 
> always a pleasure. You guys are doing a fine job there.

Thanks for your vote of confidence.  It's really appreciated.
--
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

2011-03-31 Thread Russell King - ARM Linux
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.
> 
> I don't think the criticism was directed at the core ARM code that you
> maintain (Ingo and others even praised it). I also don't think that you
> stopping maintaining it would help in any way with this situation.
> 
> We probably shouldn't take criticism personally. Linus has some points
> which the ARM community is aware of already since there is ongoing work
> for consolidating the platform code (recent v2p patches, SMP-on-UP, FDT
> and probably more will come) only that this won't happen overnight. If
> you stop merging any of these, there's definitely no way out (other than
> doing the work separately for the next two years and replacing the
> arch/arm in a single pull request).

But are we going to be allowed to continue this effort without being
constantly blamed for "pointless churn" all the time?  I don't think
so, so it may well be better to give up with pushing stuff into mainline
for two years, and then do a massive re-merge as a single major "replace
everything".

I don't like the idea, but I don't see much alternative.

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'm sure
they'll make Linus explode about it again in the near future.  That's
why this time around, I kept them in a separate branch in case Linus
refused to pull them.

And again, as a result of this thread I've given up for the time being
on the idea of continuing to consolidate the ARM Integrator/Versatile/
Realview/Versatile Express code.  I just don't see the point of wasting
time trying to consolidate stuff if it's just going to be used against
us in terms of diffstat percentages and churn complaints.

Just look at the removal of AAEC2000, LH7A40x and 2000 lines from the
mach-types file removed 6000 lines, which in itself is about the number
of lines of change submitted during the last merge window for any one
non-ARM architecture.  At this point in time with this complaint, I've
absolutely no idea why I bothered to do that.  I should've left it well
alone and then the diffstat percentage would've been smaller.  After
all, it's "pointless churn".

Yes, I'm severely hacked off and fed up with this.   Whatever we do will
ultimately be used against us in one way or another.
--
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

2011-03-31 Thread Catalin Marinas
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
maintain (Ingo and others even praised it). I also don't think that you
stopping maintaining it would help in any way with this situation.

We probably shouldn't take criticism personally. Linus has some points
which the ARM community is aware of already since there is ongoing work
for consolidating the platform code (recent v2p patches, SMP-on-UP, FDT
and probably more will come) only that this won't happen overnight. If
you stop merging any of these, there's definitely no way out (other than
doing the work separately for the next two years and replacing the
arch/arm in a single pull request).

-- 
Catalin


--
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

2011-03-31 Thread Jean-Christophe PLAGNIOL-VILLARD
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 Express, an IOMMU, NCQ SATA, ACPI, graphics
> > running in shared host memory able to give/take pages from the host,
> > extra instructions, etc etc
> > 
> > And the same kernel boots just fine on both just fine.
> 
> We've been there for a long time with ARM.  Right from the start I had
> a single kernel image which booted over a range of ARM CPUs and
> platforms.
> 
> As far as ARM CPU architectures go, today we can have a single kernel
> image which covers ARMv3 to ARMv5, and a separate kernel image which
> covers ARMv6 to ARMv7 including SMP and UP variants.  The thing which
> currently stops ARMv3 to ARMv7 all together is the different page table
> layouts, the ASID tagging, the exclusive load/store support for cmpxchg
> and other atomic operations, etc.
As we can see a lots of people work on this, to now do not add thousand of
boards but try to have only a few

Personnaly I do it on at91 as example and will continue to try to have one 
board in
the kernel with board information pass via Barebox, when it's possible.
I think it's a common effort doen by the ARM Community and this will imply
a lots of changesets.

The work done by Linaro with the device tree will help a lot to simplify the
pass of the information from the boot loader to the kernel. But we can already
do it today.

Best Regards,
J.
--
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

2011-03-31 Thread Thomas Gleixner
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 you realize and appreciate that you really have 
> > not 
> > understood the problem i think.
> 
> No, I think it is the other way around.  Folk like me and Nicolas over
> the last ten years have put considerable amounts of effort into trying
> to keep the ARM support code as clean and maintainable as possible.
> 
> That is true of the common ARM stuff, but there's no way we can do this
> for all SoC support - there aren't the hours in the day to provide such

That's what I said. You and Nicholas wont scale.

> a wide oversight.  That's why we have SoC maintainers, and the SoC
> maintainers have the responsibility to sort out their own sub-trees.

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. 

Therefor you need a team of experienced kernel developers which are
NOT associated with a particular vendor who are able to tame that SoC
crowd and work closely with you and Nicholas to keep stuff in sync.

Thanks,

tglx
--
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

2011-03-31 Thread Felipe Balbi
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 are remanescent from times when we didn't have
gpiolib. It's not long ago (about 2 years) that David Brownell (rip, my
friend) introduced it to the kernel. So those should be converted to
gpiolib and moved to drivers/gpio/ but it doesn't mean we don't need
that piece of code.

With different register layout, register offsets, register sizes, etc,
it would be way uglier to combine all those into one big hacky driver.

-- 
balbi
--
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

2011-03-31 Thread Artem Bityutskiy
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 suffering. 

If I understand correctly, this is exactly what Linaro would need to do.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
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

2011-03-31 Thread Russell King - ARM Linux
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 memory able to give/take pages from the host,
> extra instructions, etc etc
> 
> And the same kernel boots just fine on both just fine.

We've been there for a long time with ARM.  Right from the start I had
a single kernel image which booted over a range of ARM CPUs and
platforms.

As far as ARM CPU architectures go, today we can have a single kernel
image which covers ARMv3 to ARMv5, and a separate kernel image which
covers ARMv6 to ARMv7 including SMP and UP variants.  The thing which
currently stops ARMv3 to ARMv7 all together is the different page table
layouts, the ASID tagging, the exclusive load/store support for cmpxchg
and other atomic operations, etc.

I wouldn't want to try to patch out the exclusive load/store operations
with some kind of function call to one of the generic implementations in
asm-generic as that gets you into ABI problems with GCC - it'd mean having
to tell GCC that various registers are clobbered all over the place.

With page tables, we can use the old format for ARMv5 with ARMv6 and
later, but that means we lose stuff like NX support to prevent instruction
prefetches hitting devices, which is of course a problem if you have
read-sensitive registers such as FIFOs there.

Can an x86 kernel with PAE support run on an x86 without PAE support?
The differences between ARMv5 and ARMv6 are much like PAE.


Outside of the CPU architecture, things become a lot more complicated.
The biggest one up until this merge window was that there is no fixed
address for system RAM, which makes stuff like virt_to_phys() rather
horrible to deal with - which in turn makes setting up and walking page
tables a nightmare.  We've just solved that issue with run-time patching
of the kernel code to replace the add/sub instructions with ones with
the appropriate offset, so we're a step closer to unifying everything
into one single kernel image.  This work alone produced this diffstat:

 87 files changed, 450 insertions(+), 190 deletions(-)

so it actually resulted in a net increase in the amount of code to be
maintained rather than reducing it.  That's hardly surprising as what
that replaced was just a bunch of #define's for PHYS_OFFSET with some
complex assembly code to do run-time patching of instructions.

The barriers against a single kernel image are being worked on, and it's
actually one of the things which Linaro is actively tasked to achieve.

One thing which I've been working on over the last six months is to
unify some of the ARM platforms which I use for testing the kernel on,
and I'd like to see one kernel image booting on all of those.

 65 files changed, 1168 insertions(+), 1752 deletions(-)

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.

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 of queueing patches until something gets resolved one way
or the other.  I'm not even going to review any patches because I currently
see it as a total waste of time - I've no idea whether they'll stand any
chance what so ever of making it into mainline.

What's the way out of this?  I've no idea.  Can ARM continue being part
of the mainline kernel?  I've no idea.  Will we be ripping out all the
ARM platform code from the mainline kernel?  I've no idea.

I am now completely demotivated.
--
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


  1   2   >