ARM MSM updates for 2.6.35-rc1
in [Kernel]
|
Prev: [PATCH] checkkconfigsymbols.sh: Kconfig symbols sometimes have lowercase letters
Next: failed command FLUSH CACHE EXT (was: Re: via 8237 sata errors)
From: Ben Dooks on 3 Jun 2010 01:40 [sorry if this message gets unthreaded, my mbox for linux-kernel got corrupted so i've had to hand edit the headers] > - x86 has its drivers elsewhere, and they are _discoverable_ and not > hardcoded to some platform. They have often also been useful (to say > the least) to other architecture platforms. That's not always truefor > all of them (we do have drivers/platform/x86, but at least that's > maintained separately and is nowhere near the mess that is ARM) There are some common drivers for ARM specific hardware under arch/arm/common but there's not a lot of that. I have been trying to ensure that new support re-uses common driver code. I was one of the people who worked with Piere to break the SDHCI reliance on PCI so that it could be re-used on platform device based systems such as the new Samsung SoC. I have also been trying to ensure that new support is carefully considered. Unfortunately we often run into the following problems; - The "Our hacked driver has been customer-tested and patched so often that it must be the one that gets submitted" argument... trying to get them to realised that firstly, it isn't of the necessary quality or has been already done elsewhere is very difficult. - Often the hardware teams don't tell you where the blocks that have been included come from some common source. This makes the task of identifying a common driver difficult (they just make their own driver from the 'documentation' that the hardware guys hack). I've been subject to this on at-least one occasion and currently considering renaming the s3c-hsotg driver to dw-hsotg (it turns out to be a block that was bought in from Synopsys' DesignWare) - There is also a problem that as soon as the hardware that has even a small divergence from the common case that they need a special driver for it (against, see the SDHCI case where there's a couple of extra configuration register to control clocks, etc.) When Harald Welte and I looked into some of these development practices we started to try and educate the developers about this. As an example we looked the clock structure we used to modle the clock trees in the SoCs, and found that in certain of their branches there where 4 copies of the same code, each with its own subtle bugs... I have been trying very hard to make sure that these things are kept under control, but unfortunately it can be a hard task and until it hits these big companies in the pocket it very difficult to get them to actually pay for this. As for the churn under arch/arm, then there are a few reasons for this and the size of the code involved. - Firstly the implemetations of the ARM architecture can vary wildly depending on the implementor (and there can be several different implementing teams within one company). There is very little direct recommendation or specification from ARM on how the system around the core is layed out. This means that there are a variety of different interupt controlers involved, and even when a standard one is used (ARM VIC) then the interrupt routing and base addresses of the control registers change between SoCs. There is also a huge variety of memory layouts, the base of SDRAM and peripheral layout can change between individual SoCs, let alone families of them. - Secondly there has been an rush to get as many header files in defining as many registers as possible for all the hardware, even if it turns out later to be a common block or not used. I have been trying to remove as many #defines in headers where the result is only used once in the code to try and help the spiraling size of the project. - Thirdly the core of these devices is also widly different, there is often far more complexity in how the SoC's bus and clock layouts are put together. It is not like PCI where each device has a xMHZ clock and integrated PLL if needed. There are complex heirarchies of PLLs and clocks, which then need to be exported to the drivers to use, and often the clock gating is also integrated into the centralised clock control units instead of in the device. Also, since there is often very little support for any dynamic bus discovery, a lot of the device information is dependant on knowing which SoC you are running on (unlike PCI where there's a specific configuration header). Note, there are moves to try and get device trees supported on ARM to try and solve the previous paragraph, but we have an awfully big history to sort out, and it only really pushes that part of the problem out of the kernel onto the device manfactueres (who can barely get a bootloader to pass in a couple of registers). So apart from that, another source for the churn is that when we do identify common parts, thigns need to get move and older systems updated to use them. These devices seem to evolve at such a rate it is difficult to predict what we'll see 6 months down the line. The next problem is that if we don't get some support in each merge window, then the size of the task for the next one keeps growing and growing. It is already a problem just for the Samsung range of SoCs where we only really have core functionality for most of the SoCs; There are still drivers needed for some of the Security, Multimedia and connectivity subsystems to be sorted out. I have been trying my best to keep control of these issues, but it is very difficult and it isn't my daytime job :( -- Ben (ben(a)fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Lindgren on 3 Jun 2010 12:20 * Linus Torvalds <torvalds(a)linux-foundation.org> [100603 07:25]: > > > On Thu, 3 Jun 2010, Michael Ellerman wrote: > > > > You can sort of do that today, by just storing a delta, but oldconfig > > will silently turn off things you have enabled if prereqs change, so > > that doesn't really work I think. > > I think you can do it today with various hacks. Up to and including > basically doing something that just selects the options you want. > > IOW, you could likely have a human-written Kconfig.<platform> file that > just does > > define_bool MYPLATFORM y > select .. everything I need .. > > include Kconfig.main > > or a number of other tricks. I agree all the defconfigs are a pain just for the omaps alone. If this is of any help we could now just keep omap3_defconfig for arch/arm/mach-omap2 and get rid of 23 config files: $ egrep "CONFIG_ARCH_OMAP[2|3|4]=y" arch/arm/configs/* | grep -v omap3_defconfig | wc -l 23 It needs some more work for omap2 though to boot to userspace as there are still some known issues with ARMv6 vs ARMv7 support and VFP2 vs 3 support. Will try to look at fixing those again when I have a chance. Then making the multi-omap thing work on all omap1 boards would cut down another 15 defconfigs, that should be also doable. To be able to compile in multiple arm architectures we would have to get rid of the Makefile.boot files and NR_IRQS and then have some kind of common clock framework at least. I did some experiments compiling in both mach-omap1 and mach-omap2 a few years back using ARMv5 flags, there were probably other issues too like some conflicting defines. Cheers, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric Miao on 4 Jun 2010 01:40 On 06/03/2010 12:26 PM, Linus Torvalds wrote: > > > On Thu, 3 Jun 2010, Michael Ellerman wrote: >> >> You can sort of do that today, by just storing a delta, but oldconfig >> will silently turn off things you have enabled if prereqs change, so >> that doesn't really work I think. > > I think you can do it today with various hacks. Up to and including > basically doing something that just selects the options you want. > > IOW, you could likely have a human-written Kconfig.<platform> file that > just does > > define_bool MYPLATFORM y > select .. everything I need .. > > include Kconfig.main > > or a number of other tricks. > > Ingo and the x86 folks (who I really think have done a very good job, and > there really aren't any crazy defconfig files there) have this "make > randconfig" together with scripted requirements so that you can actually > _boot_ the random config, just because the requirements make sure that the > things needed for booting on the test setup are selected. > > I forget exactly what the build setup there is (Ingo described it to me > long time ago, but since I don't even want to have a build farm in my > home, I didn't care much). > > But we certainly _can_ do a better job than the 'defconfig' thing that was > really never meant for the kind of use it sees in ARM/POWERPC/SH/MIPS, and > that really isn't appropriate for any manual editing (so people just run > "make oldconfig" with tweaking or something, and then use the newly > generated file). > It certainly looks a better way to handle this. However, considering the facts that there are so many platforms out there, and doing a transition without breaking any of them is a lot work, it's actually easier to just reduce the number of defconfig at this moment, provided that most ARM platforms with the same SoC are able to be built into a single kernel. There are some exceptions though, I'd suggest not to introduce any other defconfig for these platforms until their problem is solved. Russell has setup a thread for this issue in linux-arm-kernel ML, so hopefully there will be a lot patches around to address it. There are some specific problems with ARM, e.g. some platforms are really not maintained for a long time, and even no way to find someone or some machine to test. And even with one defconfig per SoC, there could still be about > 60 defconfigs there (compared with 178 at this moment). > And I suspect that it really is best to just remove the existing defconfig > files. People can see them in the history to pick up what the heck they > did, but no way will any sane model ever look even _remotely_ like them, > so they really aren't a useful basis for going forward. > > But don't worry. It didn't happen this merge window, obviously. > > Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Vincent Sanders on 4 Jun 2010 05:30
On Wed, Jun 02, 2010 at 06:20:09PM -0700, Linus Torvalds wrote: > > snip > > - TWO HUNDRED THOUSAND lines of arch/arm is just pure garbage, namely the > defconfig files. Quite frankly, anybody who calls that anything but > pure "noise" is just misguided and being stupid. > For some hard data which might be useful in arguments on this you might want to reference http://armlinux.simtec.co.uk/reports/kautobuild-5year-report.pdf http://armlinux.simtec.co.uk/reports/kautobuild-5year-stats.ods The written report is not complete as I had hoped to have an announcement about the autobuilder fifth aniverasry soon. Perhaps this will be useful in keeping some default configurations which give us maximal coverage. I provide this purely for information, I do not intend to upset you futher on this subject, pretty please do not shoot the messenger ;-) -- Regards Vincent |