[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140304141823.GM1872@titan.lakedaemon.net>
Date: Tue, 4 Mar 2014 09:18:23 -0500
From: Jason Cooper <jason@...edaemon.net>
To: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Cc: Russell King - ARM Linux <linux@....linux.org.uk>,
Andrew Lunn <andrew@...n.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@...glemail.com>,
linux-kernel@...r.kernel.org,
Gregory CLEMENT <gregory.clement@...e-electrons.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists