Hi Paul, I understood both points you explained below, while I still think that standardizing clock names may be a little bit rigid. Thank you for your review and comments. Hiroshi DOYU From: "ext Paul Walmsley" <paul@xxxxxxxxx> Subject: Re: [PATCH 1/3] [RFC] clk: introduce clk_associate Date: Tue, 14 Oct 2008 10:33:42 -0600 (MDT) > > Hi, > > between omap_clk_associate() and vclk, my preference is for the > omap_clk_associate() approach. > > The core problem is that the vclk patches create clocks with multiple > parents in a way that is hidden from the clock framework. This causes > both semantic and practical problems. > > Semantically, the patches cause the meaning of set_rate() and set_parent() > to be confused, and any driver that wants to call set_parent() or > set_rate() on those clocks will need to have their own custom functions > for those operations. I'd like to keep the amount of that custom code > minimized. > > In practical terms, the vclk code will cause spinlock recursion bugs like > the ones that currently exist with the McBSP driver: > > http://marc.info/?l=linux-omap&m=122310205615940&w=2 > > since vclks will call clk_enable()/disable()/set_rate()/etc. inside the > clockfw_lock spinlock. Using the vclk patches also means that the number > of custom clocks will explode, as each driver is likely to define at > least one custom clock. > > [ eventually, we'll need to deal with the multiple parent issue, if for no > other reason than to fix usecounting for clocks like dss_ick. But it will > need to be handled by the clock framework code itself. And this problem > is pretty low on the priority list... ] > > So between the two, I'd like to see omap_clk_associate() integrated. I > have some comments to post on Felipe's code; once those are > addressed, hopefully we can merge it. > > > - Paul > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
