Clock DT bindings

You asked for specific topics. So, here's one:

Clock DT bindings discussion on:
* Allowing producers to export clocks by names.
* Allowing consumers to list clocks by "producer phandle, clock name".
* Should we allow for -clock magic similar to regulators?
* Should the entire clock tree be represented in DT.

I would like to attend the ARM summit to represent the needs of SoCs with complicated clocking HW. I have worked on clocks for about 5 years (since MSM started running Linux) and would like to throw in my opinion on what clock DT bindings would work well, why and help come up with a solution that works well for everyone.

Thanks,
Saravana

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Quoting Saravana Kannan (2013-08-15 20:07:52)

+1

Would be nice to have you in attendance Saravana. Some of these issues also cross over into the "kernel data bloat" topic that was posted to the list earlier.

Regards,
Mike

I'd also be interested in attending discussions about Clocks and DT (among other things - I'm the Meta architecture (arch/metag) maintainer, and will find myself increasingly working on MIPS and KVM).

I've worked on supporting the Meta based TZ1090 SoC, which has clock layout entirely represented in DT, but hit difficulties with where to put clock configuration/policy data that doesn't describe the hardware itself.

This is a general problem that I think needs discussion. Basically some other data is sometimes required that:
* doesn't describe the hardware - therefore it cannot live in device tree.
* is platform specific - so doesn't really live in the clock drivers themselves (and there's resistance to having any platform setup code in new arches like Meta).
* is application specific, perhaps depending on what has been started on other non-Linux processor cores in the SoC, or on what the bootloader has configured, or perhaps some arbitrary constraint to workaround a hardware bug - so doesn't really live in platform setup code anyway.

A couple of more concrete examples:
* Prevent a clock from being remuxed or changed (or force it to use a specific parent). For whatever reason it is sometimes desired that a particular clock uses a particular parent or cannot be remuxed. E.g. firmware on a non-Linux core might be driving a peripheral which shares the clock and doesn't want the clock rate to change under it's feet, or perhaps the use of a particular clock causes instability in certain devices, or perhaps it's a critical clock (that the core CPU or DDR clock is derived from).
* Disable certain devices. If firmware on other non-Linux cores are driving certain devices (e.g. one of the SPI or I2C buses that a radio tuner is connected to), then you want status="disabled" on that device to prevent Linux trying to drive it at the same time, but technically there's nothing preventing Linux from driving it if it wasn't already in use.

The automatic clock reparenting patchset I wrote helps with some cases where the best/correct clock to use can be determined dynamically, but that doesn't cover all cases.

I've heard Mike refer to a hypothetical configtree (which I think is the idea of passing a tree of config data similar to device tree, either in addition to or somehow merged with the device tree), but at the moment in our kernel tree we work around these by putting that data directly in device tree.

Have others hit similar difficulties?

Is some kind of configtree the right solution or are there other preferred solutions?

I'm attending ELCE so should be able to be around.

Cheers
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130816/fd733f17/attachment.sig>