On 10/30/2013 07:38 PM, Matt Sealey wrote:
On Wed, Oct 30, 2013 at 3:29 AM, Tero Kristo <t-kristo@xxxxxx> wrote:
On 10/29/2013 07:50 PM, Matt Sealey wrote:
I have one question here, what makes this part of the patch
TI-specific at all except the definition of the structure ti_dt_clk?
Mapping DT clocks to generic clkdev legacy namings seems like it would
be a necessary evil across *all* SoC platforms.
I would say there is a good case for this being generic
An earlier implementation of this patch (or at least a patch that tries to
accomplish the same as this does, add support for legacy devices) did try to
add generic solution. There was some discussion on it and I decided to drop
it due to bad feedback.
See: http://www.spinics.net/lists/linux-omap/msg95147.html
I don't see anything that says this should not be generic, just that
it was implemented relatively poorly at the time...
I agree with Tomasz, find_by_name in device trees is basically evil
(it's only supposed to be used if you already know the name because
something else passed it to you, and just want it's phandle, but names
CAN be ambiguous. The real fix is always pass phandles and not strings
of the name property), but that's not to say this thing needs to be
TI-specific..
Ah well. If it ends up getting used elsewhere, it can be quickly
patched into a generic version anyway, so.. yay!
Yeah, this can be converted to generic version easily if need be. The
thing with this patch is also that it is kind of temporary solution, it
should not be needed anymore once all the drivers are converted to DT.
I'm really interested in this all going in - but I would love to see
where this is just all patched into a tree already. Pulling things out
against a bunch of trees gave me more merge failures and weird
happenings than I care to deal with. Is there a TI clock development
tree with all this in somewhere publically accessible? I'd like to get
a feel for how the DT looks and what's going on, I can't "see" it from
the patches. Once it's there.. I'll spend a week or 5 doing all of the
i.MX chips and you'll have a second test case for any problems :)
Did you try the fully integrated test tree I mentioned in the cover letter?
tree: https://github.com/t-kristo/linux-pm.git
branch: 3.12-rc6-dt-clks-v9
This has everything in it, and compiles cleanly.
-Tero
--
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
