On 10/08/2013 08:40 AM, Mike Turquette wrote:
Quoting Tero Kristo (2013-09-25 01:48:06)
Hi all,
Version 7 contains following high level changes:
- Dropped support for basic bindings from Mike Turquette, instead using
vendor specific bindings for all clocks
- Mux clock + divider clock vendor specific bindings get rid of use
of the bit-masks, instead these are generated runtime based on parent
clock / divider min/max info, see individual patches for details
- Added support for dummy_ck nodes, was missing from previous version
- Fixed support for omap3630
- Added support for new clock node type: ti,mux-gate-clock (using composite
clock type)
- OMAP4 / OMAP5 only build fixes (compiler flag checks added to some files)
- most of the of_omap_* calls renamed to of_ti_*
- Rebased on top of v3.12-rc2
Hi Tero,
I had one really minor request for one of the patches, otherwise I'm
pretty happy with this series and I can take in the clock parts for
3.13. A few general comments:
Yea, I'll add the is_enabled check to the APLL and repost.
1) I think I mentioned some time back that it would be
wise to put a disclaimer at the top of each DT binding description
stating something to the effect: "Binding status: Unstable - ABI
compatibility may be broken in the future". Are you OK merging these
bindings as-is without that kind of a disclaimer?
Well, personally I don't mind, but if you think this would be good, I'll
add this to next rev.
2) I hope to see the clockdomain stuff go away in the future. I'm OK to
take it for now to aid in this DT transition but I would like some
commitment that it will not stay in drivers/clk/omap forever. I guess
for clockdomain you'll need to figure out how to handle those in a
generic driver way.
I think the clockdomain stuff should be possible to move to wherever CM
driver is going to move. drivers/power/omap/... or something maybe. I
have been starting some initial work on the CM driver cleanup for this
purpose.
3) Same concern as above but for the DT clkdev alias stuff. I guess
you'll need to make all of the dependent drivers play nice with DT. Do
you plan to remove it within a reasonable timeframe? It would be a nice
reduction in LoC and more importantly it would mean that drivers were
using clkdev in a more-correct fashion.
This is probably harder, I think Tony is better to comment here, but my
idea is that in the worst case we can just break non-conforming drivers
by dropping the clkdev tables if nothing else helps. :) Most of the
tables are currently needed by hwmod, and there are already patches
around for adding DT clock support for hwmods, so once these go in, we
can at least reduce the table sizes considerably already.
-Tero
Regards,
Mike
Some detailed comments about patch level changes (if no mention, no major
changes):
- Patch #1:
* removed use of reg-names property, instead registers mapped using
compatible string
* removed ti,modes property, instead uses DPLL mode flags now
* separated AM33XX DPLLs under their own compatible strings
- Patch #4 & #5: new patches
- Patch #6: merged basic gate support from Mike to this patch as vendor
specific gate clock support
- Patch #9 & #10: new patches
- Patch #11: dummy clocks added, USB / ABE DPLL setup ordering changed
- Patch #14: dummy clocks added
- Patch #20: dropped usage of reg-names property
- Patch #21: dummy clocks added
- Patch #22 & #23: new patches
- Patch #30: AM35XX clock data added to this patch
- Patch #31:
* dummy clocks added
* added missing 3630 clocks
Test branch available here:
https://github.com/t-kristo/linux-pm.git
branch: mainline-3.12-rc2-ti-dt-clks-v7
Testing done:
- am335x-bone : boot only
- omap5-sevm : boot only
- dra7-evm : boot only
- omap3-beagle : boot + suspend/resume (ret + off)
- omap4-panda-es : boot + suspend/resume
Nishanth has also been doing some tests with omap3-beagle-xm with some WIP
versions of this branch, but not with this latest one. Nishanth, maybe you
can provide test results to this one also?
-Tero
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
