On Tue, Mar 04, 2014 at 03:02:25PM +0100, Sebastian Hesselbarth wrote: > On 03/04/2014 02:53 PM, Jason Cooper wrote: > >On Tue, Mar 04, 2014 at 12:11:36PM +0000, Russell King - ARM Linux wrote: > >>On Tue, Mar 04, 2014 at 11:39:43AM +0100, Sebastian Hesselbarth wrote: > >>>On 03/04/2014 10:26 AM, Andrew Lunn wrote: > >>>>>I could have sworn this was discussed with this particular patchset, but > >>>>>I'm unable to find the conversation in my archives. Neither during the > >>>>>patch submission process, nor the (long) pull request thread. > >>>>> > >>>>>Perhaps it was an irc conversation? Andrew, Sebastian, can you find a > >>>>>link? iirc, one of the DT maintainers (Mark Rutland?) raised the same > >>>>>concern and I thought we answered that sufficiently... > >>>> > >>>>It was the cpufreq driver which caused the discussion. I looked at it > >>>>for a while, and then task swapped onto the kirkwood move into > >>>>mach-mvebu. > >>> > >>>I guess you are looking for this discussion > >>> > >>>http://comments.gmane.org/gmane.linux.power-management.general/41053 > >>> > >>>and specifically Mark's remarks on PMU and DT in here > >>> > >>>http://permalink.gmane.org/gmane.linux.ports.arm.kernel/285384 > >>> > >>>BTW, +1 for a single PMU node that either serves an mfd (or type > >>>of) driver or that subsystem drivers derive their resources from. > >>>Looking at Dove FS, that would also include clock gating, which > >>>could be a mess to sort out.. anyway, let's get it on. > >> > >>So we have cpufreq, pm domains and an irq controller. What's the plan > >>for this, who's going to look at sorting this out? > > > >Andrew, Sebastian? I'm currently task-saturated... > > Phew, looks like I'll have to take it? > > Are you guys ok with having a single PMU node with syscon provided > regmap and make all drivers depend on it? I'd like to get a go from > Russell here, as he has clearly something in mind. > > We can consolidate drivers later if required. If we start that now, > we definitely risk running out of time for v3.15.
Honestly, mvebu has enough going on atm. I would target v3.16 and take our time. At least with the binding. If the driver comes together easily, we could always do like we did for mbus. Do a legacy init from the board (soc) file, then switch to the dt binding once everyone is happy with it. v3.14-rc6 is less than a week away, so I'll be sending final mvebu pull requests late Wednesday/Thursday... v3.14-rcX has been awful quiet, there might not be an -rc7. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
