On Tue, 2014-02-11 at 19:28 +0000, Arnd Bergmann wrote: > On Tuesday 11 February 2014 17:10:24 Pawel Moll wrote: > > This series is a set of updates following the infrastructure > > rework and depends on it. It will be finally posted once > > the main series is merged. For the time being I would really > > appreciate feedback and/or (n)acks... > > I haven't read the patches yet, but on a general level, do > you think this code can be (or should) be shared with > mach-versatile and mach-realview? Haven't worked with the old ones too much, I just had a look at a couple of TRMs... The sysregs look similar, don't they? Deceitfully similar... ;-) Let me start from the VE side and classify the registers into functional groups, looking at them from a MFD cells point of view: - general ID registers like SYS_ID, SYS_MISC, SYS_PROCIDx - either not really useful for drivers or different bitmasks if needed (eg. the MASTERSITE bit in SYS_MISC); in other words - good candidates for syscon if at all interesting - de-facto GPIO registers like SYS_LED, SYS_MCI, SYS_FLASH - easily covered via "basic-mmio-gpio" driver; can be simply exposed in the tree as subnodes - flags (SYS_*FLAGS*) - used pretty much only for SMP booting; that's where, I believe, we could unify and move the DT-based operations into plat_versatile; it is too early for the device model though, so out of the sysreg driver scope, really (even if the code lives here for now) - counters (SYS_100HZ, SYS_24MHZ) - the 24MHz one is used on some of the platforms as a sched clock source; in the fourth patch of the second series I moved it out into drivers/clocksource - it could be easily generalised and used across more platforms, but again - it's early code, so out of sysreg driver scope - system configuration (SYS_CFG*) - that's the main difference between VE and its predecessors; the older seem to provide separate system registers to control infrastructure like clocks etc. (eg. SYS_OSC* on the realview boards), while here we have the (whatever you call it ;-) config bus - other registers that are currently not used at all, but most of them differ either in naming (and location) or in offset. All this leads, I believe, to conclusion that they definitely deserve different compatible values. Therefore they would also require different mfdcells definitions. Of course we could have more than one in a single file and pick one via matching table but: 1. There is always that little "extra" (like the master site configuration on VE, which doesn't happen on the previous ones) 2. I'd rather not to have the non-VE stuff in arm64 kernel. So, to summarize, I think we need separate files for at least main families of the sysreg drivers (I didn't spent enough time on this to be able to find commonalities and differences inside realview and versatile families), but try to share as much as possible of the "functional" drivers (with the sched clock and the smp operations being the most obvious candidates). > One of the things on my (mid-term) to-do list is to completely > convert those two platforms over to being entirely DT based > and having no board specific code so we can actually delete > the directories along with mach-vexpress And I sympathise with this goal :-) (interestingly Olof in the past expressed strong and opposite opinion in the subject ;-) If you have a look at the last patch of the second series, you'll find that what's left in the VEXPRESS_DT machine are smp operations and l2x0_of_init. Then, assuming that we finally get some answer to the CLCD problem (latest in this subject happened here: http://thread.gmane.org/gmane.linux.ports.arm.kernel/268037 - I really lost all hopes for CDF getting anywhere...) removal of the non-DT code is a matter of a single patch (and a massive negative stat :-). From there there's only a bunch of PM-related files in arch/arm/mach-vexpress that I guess could be moved somewhere else (that's what Olof didn't really like). Pawel _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
