On 11.03.2016 19:24, Sergei Shtylyov wrote:
On 03/11/2016 07:21 PM, Petr Kulhavy wrote:
I am having 2nd thought on parsing the clock prop, Sergei's comment
might be better. I will look more on this over this weekend. (DT is not
in my expertise...)
Regards,
-Bin.
I like Sergei's comment as well, but cannot see (yet) how the clock
input
selection would be done.
The same way as now, of course. Only getting the clock frequency
would be different, via clk_get_rate()...
I mean, it makes sense to do the clock abstraction only if it can be
done
properly and the clock input selection can be covered as well.
No, this item has never been covered by the clk layer IIRC. That's
what the device node props are for.
The DA8xx platform is missing the real clock framework and therefore the
different clocks cannot be referenced in DT.
You mean more than one clock per device?
There is a fake clock framework in arch/arm/mach-davinci/clock.c - I've
already been through that and then gave up.
I'm not sure why you call it "fake". It's a normal clk
implementation, just not converted to the common clk framework.
Hi Sergei,
what I mean is that the DA8xx platform does not use the common clock
framework. It uses its own clock implementation instead which is
incompatible with the common clock framework, since it uses the same
function names. So the common clock framework cannot be even compiled
with this architecture.
With common clock framework the USB 2.0 clock would be modelled as a
multiplexer between AUXCLK and USB_REFCLKIN.
The AUXCLK would be a phandle to the respective internal clock.
USB_REFCLKIN then a phandle to either fixed clock or another clock source.
Providing the right parent phandle, internally calling set_parent()
would do the job and no extra property would be needed.
Or did I miss something?
If the common clock framework is not available for this platform then
the only option I see is what I did in my patch - to set the frequency
via an integer property and control the multiplexer with another
property. We cannot even do what you suggested as the fixed clock simply
does not exist due to the lack of the common clock framework.
Or do you see another way?
Regards
Petr
--
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
