[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50CED412.7060407@ti.com>
Date: Mon, 17 Dec 2012 09:13:06 +0100
From: Benoit Cousson <b-cousson@...com>
To: Paul Walmsley <paul@...an.com>
CC: Tony Lindgren <tony@...mide.com>, Roger Quadros <rogerq@...com>,
<balbi@...com>, <sameo@...ux.intel.com>, <keshava_mgowda@...com>,
<sshtylyov@...sta.com>, <bjorn@...k.no>,
<linux-usb@...r.kernel.org>, <linux-omap@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, Rajendra Nayak <rnayak@...com>,
Mike Turquette <mturquette@...il.com>
Subject: Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk
into usb_host_hs_utmi_px_clk
Hi,
On 12/14/2012 07:44 PM, Paul Walmsley wrote:
> Hi
>
> On Fri, 14 Dec 2012, Tony Lindgren wrote:
>
>> Paul, what about this patch? Looks like you've acked the other clock
>> patches in this series but not this one?
>
> I commented on it briefly here:
>
> https://patchwork.kernel.org/patch/1838111/
>
> Maybe BenoƮt could comment here, but it looks to me (based on a
> superficial look at the hardware clock tree data) that these clock nodes
> should exist. In an ideal world, we'd be able to get back to the
> autogeneration of this clock data.
I'm not sure to understand either the rational for that patch. What the
point of merging the two nodes?
I mean, we can do it, but AFAIR, we have always decided to use atomic
node instead of big nodes that handle everything.
Regards,
Benoit
--
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