From mboxrd@z Thu Jan  1 00:00:00 1970
From: tony@atomide.com (Tony Lindgren)
Date: Fri, 2 Aug 2013 00:22:21 -0700
Subject: [PATCHv4 05/33] CLK: omap: add DT duplicate clock registration
 mechanism
In-Reply-To: <51FA7F12.6010407@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-6-git-send-email-t-kristo@ti.com>
 <51F808A8.6000503@ti.com> <51F8E1F5.20706@ti.com>
 <51FA6FCA.3050900@ti.com> <51FA7C39.8090100@ti.com>
 <51FA7DB6.3060002@ti.com> <51FA7F12.6010407@ti.com>
Message-ID: <20130802072220.GV7656@atomide.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

* Tero Kristo <t-kristo@ti.com> [130801 08:37]:
> On 08/01/2013 06:24 PM, Nishanth Menon wrote:
> >On 08/01/2013 10:18 AM, Tero Kristo wrote:
> >>On 08/01/2013 05:25 PM, Nishanth Menon wrote:
> >>>On 07/31/2013 05:07 AM, Tero Kristo wrote:
> >>>>On 07/30/2013 09:40 PM, Nishanth Menon wrote:
> >>>>>On 07/23/2013 02:20 AM, Tero Kristo wrote:
> >[..]
> >>>if we can get rid of usage of omap_hwmod_get_main_clk by catching them
> >>>with [1], then we can force the drivers to pick up based on device node
> >>>clocks= property.
> >>>
> >>>It might be easier to fix 1 driver - timer, rather than introduce am33x,
> >>>omap4, omap5 dra7 specific "SoC clk driver".
> >>>
> >>>with that this entire patch becomes redundant.
> >>
> >>It is not that simple. Looking at the architectures this set supports, I
> >>see clock alias nodes at least for following drivers:
> >>
> >>- GPT timer
> >>- USB
> >>- DCAN
> >>- EMAC
> >>- VPFE
> >>- UART
> >>- SSI
> >>- DSS
> >>- security
> >>- MMC
> >>- MCBSP
> >>- MCSPI
> >>
> >>I am _not_ going to fix all of these during the initial phase. :P
> >>
> >>But yes, eventually these should go away.
> >
> >How many of these are needed to boot? what functionality do we expect
> >with the series -> we can constraint saying that remaining drivers
> >should fix themselves the right way, else dont have the feature -
> >example cpufreq- fix it the right way, or wont see the feature enabled.
> >
> >introducing a "way out" for all of these just invites more guys to screw
> >around claiming "it was done before - see here"..
> >
> >lets just fix the darned basic ones, refuse to provide "way out" and let
> >the others fix themselves.
> >
> 
> Yea, that would be one way. I guess someone like Tony should comment
> on this.

Well how about add some dev_warns so we can keep things working and
know which ones to fix? Otherwise it seems that things will not work
properly for many devices.

Regards,

Tony