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

[Nicolas Pitre]

On Wed, 30 Mar 2011, david@xxxxxxx wrote:

> On Wed, 30 Mar 2011, Nicolas Pitre wrote:
> 
> > As long as SOC vendors keep producing wildly different architectures
> > besides the core CPU we'll have this problem.  Denying the reality won't
> > make that problem go away either.  And device tree won't stop those
> > vendor from still trying to do things differently (better?) because they
> > are not constrained by having to ensure this single proprietary software
> > stack still boot.
> 
> the thing that you are not convincing us of is that all these different SoCs
> are so wildly different architectures.

You can have a look at the code.  It is all there.  And the different 
GPIO controllers are just the tip of the iceberg.  But by all means if 
you actually find a way to abstract most differences between those SOCs 
then please say so.  Many people tried already.  Maybe they weren't 
smart enough.

> back in the early days of the PCs, different systems from different vendors
> had different bus types, peripherals at different addresses, etc. that didn't
> make all of those vendors systems different architectures, instead those
> things were varients of the x86 architecture.

Most of them didn't survive.  That really helps.

> with ARM you do have a couple different architectures (arm5 vs arm7 for
> example),

That's the easy part.  Well not necessarily that easy, but RMK did a 
damn good job of it and looking at the result you may think that was 
easy.

> but what you are hearing people say is that
> 
> arm7+IPblock1+IPblock2
> arm7+IPblock1+IPblock3>
> arm7+IPblock2+IPblock3>
> 
> are not three different architectures, they are one architecture with
> different devices attached.
> 
> what's more, you seem to be saying that
> 
> arm7+IPblock1
> 
> and
> 
> arm7+IPblock1
> 
> are different architectures if the wiring between the arm core and IPblock1
> are different (they are different 'boards' or different chip models, possibly
> from different manufacturers)

That's again the easy part.  If that was all that simple we would be all 
happy campers.

> I see the variations here as a good thing, just like having a huge number of
> pluggable cards in a PC was a good thing (even though it made it hard to have
> an OS that supports every card out there)

What we have here is more like a large number of PCs, each one with a 
different set of cards.  The different SOCs are like PCs, and the cards 
are those set of peripherals to be found in those SOCs.

But it is not just about peripherals, and system level things like 
timers and interrupt controllers.  It is also about the huge complexity 
put into the hardware for power management.  you will find different 
clocks/PLLs, power domains and regulators, and that has to be intermixed 
with various sleep states, wake sources and conditions, etc.  And no 
ressemblance is to be found between different vendors for those pm 
features unfortunately.  Even with a common high level abstraction 
(which abstraction is still being worked on) you will still need the 
backend code to interface with the hardware.

Maybe someday the optimal (or even just good enough) power management 
hardware infrastructure will be found and everybody will standardize on 
that.  But we're apparently not there yet.

> in the case of the PC, systems that were too different died off, systems that
> could have their differences abstracted into different drivers prospered.

Maybe that will happen eventually.  In the mean time they are rather all 
successful despite the major hardware discrepancies because the kernel 
is Open Source and it is relatively easy for each vendor to hack the 
kernel until it works on their own hardware.  User space is largely 
unaffected so the kernel becomes the actual abstraction.

> I am _not_ saying that all arm systems need to standardize on one interrupt
> controller,

I wish they had.

> I am saying that the kernel support for ARM needs to be able to
> _easily_ be told that this chip has interrupt chip type 24 connected this way,
> and interrupt chip type 87 connected that way, without needing to create a new
> architecture.

But then we have the next SOC coming up with yet another IRQ controller 
built into it.  So yet more code is required to deal with it.
Amongst the 15 ARM vendors or so, no IRQ controller is the same.

> If the kernel is compiled with the appropriate drivers, it
> should even be able to be done without needing to recompile the kernel.

Obviously.  And that's not a problem.  The problem is to actually 
support all the different hardware blocks.  Hence the volume of code 
out there.

If you do configure your kernel for one specific target which has a 
specific SOC implying a specific IRQ, timer, GPIO, clock, power, memory 
and peripheral bus, then you'll end up using relatively few lines of 
code from the arch/arm/ directory.  If instead you want support for a 
SOC from another vendor, then you'll need a different set of source code 
similar to the differences between an ARM SOC and a MIPS SOC.

> Now I understand that this isn't how things are done today in ARM, but that's
> not how things were done 10 years ago in x86 either. back then you had kernels
> compiled specifically for each system. nowdays that is still done where space
> or performance is critical, but a huge number of systems sacrafice a few % of
> speed, and some storage and ram for the flexibility and supportability of
> using a one-size-fits-many kernel (along with a large number of loadable
> modules)

We do have that partially on ARM.  It is already possible to build a 
kernel that supports multiple different boards at once, as long as 
they're all using the same SOC family.  I invite you to have a look at 
http://armlinux.simtec.co.uk/kautobuild/2.6.39-rc1/index.html.  Notice 
the defconfig names which are mostly after SOC names, and the number of 
actual machines they do include for each of those configs.  For example, 
the omap2plus_defconfig produces a single kernel binary that can boot on 
31 different boards.  Performance is not optimal as the instruction set 
is limited to the oldest supported by all those boards.  But it works.

This last merge window, some prerequisite infrastructure changes was 
pushed upstream to eventually allow for many SOC families to be compiled 
together by performing binary patching of the kernel at boot time like 
on X86.

But that has nothing to do with the fact that those SOCs still need 
their own specific support code to work because each vendor did their 
own things around the CPU core.  And there are a _lot_ of different SOCs 
on ARM, far more than any other architecture in the kernel tree.

> look at serial port support on x86.
> 
> while serial ports are becoming rare nowdays, the kernel has support for
> _many_ different types of ports, and all of the port types support being wired
> up in different ways (to different addresses and interrupts)
> 
> the kernel could have gone the route that ARM did of having a master config
> that listed every system known and where it's serial ports were wired, but
> thanks to the fact that many of these were plug-in options, that would have
> been painful enough that it drove them to do it the right way.

No... You don't understand.  What you're talking about above is all 
about different ways to wire the same serial controller chip, or 
derrivatives of that chip, all based on the venerable 8250 from National 
Semiconductor.  While it is true that some ARM SOCs do have a compatible 
UART and rightfully use the 8250.c driver, many (most?) SOCS do have 
totally incompatible UARTs requiring separate drivers. That's what I 
mean by each vendor doing their own things differently.

> take ARM down a similar path, treat the on-chip devices in a similar way to
> off-chip devices.

But we do already.  Care to provide an example where it is not the case?

> define the different types of GPIO behavior in arch-level drivers and make the
> chip-level (or board level) definitions say "I have a type 6 GPIO device wired
> this way" instead of including an entire GPIO driver in that definition.

GPIO is too easy.  Please take the clock tree and the multiple power 
domains found on the various TI OMAP and tell me how you would change 
that code into 
such abstract data, and make that format also useful and usable for the 
Marvell Kirkwood, and/or the Freescale i.MX, and/or the ST-Ericson 
UX500, and/or ... (the list can go like this for long).

> what is happening in ARM is being driven by the short-term ease of the chip
> manufacturers, they do things any way they want, and their engineers
> cut-n-paste their way to make things work as a new architecture.

Sure that's what they do.  But that code never get merged in mainline.  
Trust me, what we have now, even if it doesn't look nice from a 10000 
feet point of view, has gone through ssome review and often complete 
rewrite from people outside of those manufacturers.

> in the long run, making things more flexible and easier for the device
> designers and the people modifying the designs down the road will grow the pie
> by making it much easier for people to drop an ARM onto a new design, add a
> smattering of random (to the chip manufacturer) chips to do various things,
> and get linux running on the result.
> 
> get it down to where a new board can be designed by a guy in his garage, with
> a linux ARM distro able to run out of the box on it (with the appropriate
> definitions of how the guy wired it), and the variations will proliferate to
> the point where the current variation in ARM will look trivial by comparison,
> and the result will be even more use (and therefor sales) of ARM chips in all
> sorts of things that nobody can imagine today.

Hey, are you trying to convince _me_?  I'm currently not into the 
semiconductor 
industry, and for the 2.5 years that I did work for a semiconductor 
vendor I had very little to say about the hardware design.  I do wish 
that the hardware platform on ARM was more uniform.  That would 
certainly make my job easier.  But reality is different, for better or 
worse.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/