Hello. On 09/11/2013 12:07 AM, Stephen Warren wrote:
Do you need any clocks properties, IP block reset signals, power domains?
Currently not.
What does "currently" mean? Does that mean that the Linux driver simply doesn't touch those entities at present?
There's Ether clock but the driver doesn't manipulate it directly, assumingly it does this thru the runtime PM interface. As for the others, I simply don't know.
If there's a clock, it should be represented in DT, even if the kernel somehow gets access to the clock through some means other than parsing DT.
Frankly speaking, I don't see the point.
If so, that's not enough to say that those entities should not be described in the DT binding. We should strive to make the binding completely describe all aspects of the HW, irrespective of whether a particular driver happens to use that information at present.
There's no DT representation for the clocks in SH-Mobile subarch yet. The same applies to the other entities you mentioned.
You can still write the binding to say that the appropriate clock property must be present; the overall format of this property won't be affected by the representation chosen for the SH-Mobile clocks.
Where can I find an example of such property, independent of the parent clock node? All I could find with quick search refers with a phandle to a clock node (we don't have now).
It seems like it'd be best to get the basic resources (like clocks) represented in DT before trying to build blocks that use them.
We don't use them directly. And we need the Ether device tree support *now*, while clock-related work will probably take months (there are plans to switch Sh-Mobile to CCF in like 6 months).
WBR, Sergei -- 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
