Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper <jason@lakedaemon.net>]

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.