Messages in this thread | | | Date | Mon, 13 May 2013 11:31:03 +0300 | From | Peter De Schrijver <> | Subject | Re: [PATCH RFC] clk: Introduce userspace clock driver |
| |
> >>> > >>> For debugging purposes, being able to change parents would be nice too. > >> This is difficult and I don't have a good solution for it, hence it's > >> missing. A clock consumer like a device driver or this driver, just > >> knows about it's input clock, but not about the topology further up. > >> Therefore it is pretty much impossible to implement reparent operations > >> in a clock consumer, IMHO. > >> IOW: For a given input clock, how do you figure out it's possible > >> parents? > > > > The parent is just a number > > > > int (*set_parent)(struct clk_hw *hw, u8 index); > > u8 (*get_parent)(struct clk_hw *hw); > > > > If you are debugging, you know what the possible parents are, and you > > can reparent with that information. > > > > After checking the clk code however, I didn't find any exposed way to > > reparent with just the parent indexes. Maybe an interface that takes a n > > arbitrary string representing the parent name, and gets that clock and > > then sets the parent would fit. > > > >> > >>> Maybe this belongs to debugfs instead of sysfs though. > >> Well, the more generic use-case probably. My Zynq use-case rather not, > >> IMHO. > > > > The framework already exposes some information on debugfs, maybe > > expanding that instead of implementing it as a consumer on sysfs would > > be best for the debugging use case. @Mike, what's your thoughts on this? > > > > In the previous thread on this topic we discussed a generic approach > to exposing clock controls via debugfs. > > One way to do it is to introduce a new config option, > CONFIG_COMMON_CLK_DEBUG_CONTROL that would expose the controls for > every clock in the existing debugfs infrastructure. The downside to > this approach is that it would get abused and ship in millions of > Android products using horrible userspace hacks to control clocks. > Maybe that's not our problem to solve, maybe it is. >
We are doing the same. I don't think we can prevent people from abusing this. If we don't provide it, they will just implement it themselves :)
> If CONFIG_COMMON_CLK_DEBUG_CONTROL existed it might be a good idea to > intentionally break the abi compatibility with every new release. > That would certainly reinforce that this is not a condoned or stable > api (which is true for all debugfs). >
:) I would rather not have to change our automated tests for every new release though...
Cheers,
Peter.
| |