Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
On Tue, Jan 24, 2012 at 11:59:40PM +0100, Colin Cross wrote: On Tue, Jan 24, 2012 at 2:43 PM, Stephen Warren swar...@nvidia.com wrote: Colin Cross wrote at Tuesday, January 24, 2012 3:33 PM: On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren swar...@nvidia.com wrote: Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM: What about the peripheral resets which are also handled by CAR? Peripheral clock nodes also offer assert and deassert methods for the reset signal associated with them. Those methods are used when powergating domains for example. Should we model this in the same binding? In most cases, I think the resets are handled purely within clock enable and disable, so there's no need to explicitly manage them or represent them in the device tree. Do you agree here? clk_enable could force a deasserted reset, but clk_disable cannot imply asserting reset. The clocks need to be turned off for power management without resetting the registers. Yes, I just spoke to someone off-list, and he said the same thing. He went on to say that therefore even the reset removal with clk_enable was questionable, and that drivers should explicitly manage reset removal themselves. Does that seem a reasonable stance? It'd certainly take away the somewhat asymmetric nature of reset removal just magically working when you first enable the clocks. We'd presumably then want a common reset infra-structure and binding to match that change? In 99% of drivers reset is irrelevant, as long as the block is out of reset by the time the driver starts writing to registers. clk_enable is a decent place to ensure that - it always has to be done before writing to the registers, and it maps nicely to the reset bits on Tegra. It would be nice if those driver didn't need to deassert reset explicitly, especially if that requires a Tegra-specific API. I think this could be solved by moving the drivers to runtime PM and handle the clock and reset bits in tegra platform device specific code. iirc that's the way it's handled in OMAP? Cheers, Peter. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
What about the peripheral resets which are also handled by CAR? Peripheral clock nodes also offer assert and deassert methods for the reset signal associated with them. Those methods are used when powergating domains for example. Should we model this in the same binding? Thanks, Peter. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:
What about the peripheral resets which are also handled by CAR? Peripheral
clock nodes also offer assert and deassert methods for the reset signal
associated with them. Those methods are used when powergating domains for
example. Should we model this in the same binding?
In most cases, I think the resets are handled purely within clock enable
and disable, so there's no need to explicitly manage them or represent
them in the device tree. Do you agree here?
I recall that you mentioned some power-management code might need to
manage reset separately though. Can you explain why a module would be
reset separately from disabling the clocks though?
If we do need this, I think we can just add a property to the node of
each device that needs such explicit management. Something like:
tegra_car: clock@60006000 {
compatible = nvidia,tegra20-car;
};
foo@70007000 {
compatible = nvidia,tegra20-foo;
regs = ...;
nvidia,car-reset-id = tegra_car 30;
};
And the driver for foo can ignore cell 0, and extract the cell 1 and
pass the value to tegra_periph_reset_assert().
I'd expect to put the CAR phandle into the property in case we ever get
a more generalized reset subsystem, and need more general code to
interpret the property. I did the same for the Tegra APB DMA controller
client binding where clients need to know the DMA select value.
Does that all seem reasonable?
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren swar...@nvidia.com wrote:
Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:
What about the peripheral resets which are also handled by CAR? Peripheral
clock nodes also offer assert and deassert methods for the reset signal
associated with them. Those methods are used when powergating domains for
example. Should we model this in the same binding?
In most cases, I think the resets are handled purely within clock enable
and disable, so there's no need to explicitly manage them or represent
them in the device tree. Do you agree here?
clk_enable could force a deasserted reset, but clk_disable cannot
imply asserting reset. The clocks need to be turned off for power
management without resetting the registers.
I recall that you mentioned some power-management code might need to
manage reset separately though. Can you explain why a module would be
reset separately from disabling the clocks though?
The TRM lists a very specific sequence of clocks, resets, clamps, and
power for power domain gating. Other than that, I think the only use
for directly calling reset that ended up in the Android Tegra2 tree
was for error recovery on HW blocks that could get locked up, probably
I2C.
If we do need this, I think we can just add a property to the node of
each device that needs such explicit management. Something like:
tegra_car: clock@60006000 {
compatible = nvidia,tegra20-car;
};
foo@70007000 {
compatible = nvidia,tegra20-foo;
regs = ...;
nvidia,car-reset-id = tegra_car 30;
};
And the driver for foo can ignore cell 0, and extract the cell 1 and
pass the value to tegra_periph_reset_assert().
I'd expect to put the CAR phandle into the property in case we ever get
a more generalized reset subsystem, and need more general code to
interpret the property. I did the same for the Tegra APB DMA controller
client binding where clients need to know the DMA select value.
Does that all seem reasonable?
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
Colin Cross wrote at Tuesday, January 24, 2012 3:33 PM: On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren swar...@nvidia.com wrote: Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM: What about the peripheral resets which are also handled by CAR? Peripheral clock nodes also offer assert and deassert methods for the reset signal associated with them. Those methods are used when powergating domains for example. Should we model this in the same binding? In most cases, I think the resets are handled purely within clock enable and disable, so there's no need to explicitly manage them or represent them in the device tree. Do you agree here? clk_enable could force a deasserted reset, but clk_disable cannot imply asserting reset. The clocks need to be turned off for power management without resetting the registers. Yes, I just spoke to someone off-list, and he said the same thing. He went on to say that therefore even the reset removal with clk_enable was questionable, and that drivers should explicitly manage reset removal themselves. Does that seem a reasonable stance? It'd certainly take away the somewhat asymmetric nature of reset removal just magically working when you first enable the clocks. We'd presumably then want a common reset infra-structure and binding to match that change? (I know that'd make Simon happy, since then we'd be able to represent the reset IDs directly everywhere, unrelated to the clock IDs, and hence he could just use the reset IDs directly in the U-Boot code he's writing and ignore the non 1:1 mapping between clock and reset IDs) I recall that you mentioned some power-management code might need to manage reset separately though. Can you explain why a module would be reset separately from disabling the clocks though? The TRM lists a very specific sequence of clocks, resets, clamps, and power for power domain gating. Other than that, I think the only use for directly calling reset that ended up in the Android Tegra2 tree was for error recovery on HW blocks that could get locked up, probably I2C. OK, those reasons make sense. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
On Tue, Jan 24, 2012 at 2:43 PM, Stephen Warren swar...@nvidia.com wrote: Colin Cross wrote at Tuesday, January 24, 2012 3:33 PM: On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren swar...@nvidia.com wrote: Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM: What about the peripheral resets which are also handled by CAR? Peripheral clock nodes also offer assert and deassert methods for the reset signal associated with them. Those methods are used when powergating domains for example. Should we model this in the same binding? In most cases, I think the resets are handled purely within clock enable and disable, so there's no need to explicitly manage them or represent them in the device tree. Do you agree here? clk_enable could force a deasserted reset, but clk_disable cannot imply asserting reset. The clocks need to be turned off for power management without resetting the registers. Yes, I just spoke to someone off-list, and he said the same thing. He went on to say that therefore even the reset removal with clk_enable was questionable, and that drivers should explicitly manage reset removal themselves. Does that seem a reasonable stance? It'd certainly take away the somewhat asymmetric nature of reset removal just magically working when you first enable the clocks. We'd presumably then want a common reset infra-structure and binding to match that change? In 99% of drivers reset is irrelevant, as long as the block is out of reset by the time the driver starts writing to registers. clk_enable is a decent place to ensure that - it always has to be done before writing to the registers, and it maps nicely to the reset bits on Tegra. It would be nice if those driver didn't need to deassert reset explicitly, especially if that requires a Tegra-specific API. (I know that'd make Simon happy, since then we'd be able to represent the reset IDs directly everywhere, unrelated to the clock IDs, and hence he could just use the reset IDs directly in the U-Boot code he's writing and ignore the non 1:1 mapping between clock and reset IDs) I recall that you mentioned some power-management code might need to manage reset separately though. Can you explain why a module would be reset separately from disabling the clocks though? The TRM lists a very specific sequence of clocks, resets, clamps, and power for power domain gating. Other than that, I think the only use for directly calling reset that ended up in the Android Tegra2 tree was for error recovery on HW blocks that could get locked up, probably I2C. OK, those reasons make sense. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
Olof Johansson wrote at Saturday, January 21, 2012 12:32 AM:
On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warren swar...@nvidia.com wrote:
Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
diff --git
a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module
responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be nvidia,chip-car
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz 32k_in, and the board-specific oscillator osc.
+- clock-names : Should contain a list of strings, with values 32k_in,
+ and osc.
...
+Example:
+
+clocks {
+ clk_32k: oscillator@0 {
If it has a unit addres (@x) it needs a reg property with the same base
address.
I thought everything needed a unit address period? Is the rule more like
the unit address is optional, but if present must match reg, so I can
simply remove @0 and @1 here? I guess that makes a lot more sense.
Nope, you only need a unit address to make a node unique, i.e. if you
have more than one with the same name. It's not something that's been
followed very well on ARM dts files, I have even seen review comments
asking for explicit unit IDs when none are needed.
So you can't remove @0 and @1 here, since there are two oscillator subnodes.
If I keep the unit address, then I need to add a reg property per Mitch's
response. But, then I need #address-cells and #size-cells in the clock
node too. Yuck, since this isn't an addressable bus.
Instead, is it acceptable to simply rename the nodes to e.g.:
clk_32k: clock {...};
osc: crystal {...};
In the long term, I believe that osc/crystal is going to continue to
be a top-level object, but clk_32k is actually an output from the PMU
chip, and hence there won't be any naming conflict here anyway...
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
Simon Glass wrote at Sunday, January 22, 2012 11:03 AM: On Wed, Jan 18, 2012 at 4:16 PM, Stephen Warren swar...@nvidia.com wrote: Document a binding for the Tegra20 CAR (Clock And Reset) Controller, add it to tegra20.dtsi, and configure it for the board in tegra- seaboard.dts. ... A comment on the shared enable issue: When enabling/disabling clocks, Tegra requires you to reset the HW module that the clock is routed to. Both reset and clock enable registers are part of the CAR. U-Boot currently has an API to do the reset based on a peripheral ID, which simply means a bit number in a set of 3 reset registers. The bits in those registers share the same numbering as the clock enable registers. Hence, to make life easy for U-Boot, I've defined the clock IDs in this binding to be equal to these bit numbers. However, this breaks down where there isn't a 1:1 mapping between reset and clock enable bits, and clocks. For example, there's a single reset and clock enable bit for the SPDIF controller, yet this applies to two clocks; spdif_in and spdif_out. Hence, this simplification for U-Boot breaks down. I think the correct solution is to fix U-Boot not to require this simplification, renumber the clocks in the CAR binding in a completely arbitrary fashion, and require U-Boot to contain a mapping table between CAR's DT clock IDs and any other information related to those clocks. Do you see any alternative? We really need the two SPDIF clocks to be different clock IDs in the binding, since each has a completely independant mux for the clock source/parent, and the two clocks obviously can't share the same clock ID (well, hmm, perhaps they could if we used 2 cells for the specifier, 1 for the bit number, and one more to differentiate clocks that use the same bit...). I'm still inclined to simply push back on U-Boot to do it right. Are SPDIF and VI the only examples of this? I think so. I should double-check to be sure though before committing to a final binding. If so, perhaps just having a special extra clock ID for those two and mapping in a special way would be more efficient. So two IDs would map to one clock/reset bit but different clocks. I thought about that initially, but it doesn't make semantic sense; there isn't a 1:1 mapping between clock ID and reset bit, so I don't think we should pretend there is for some clocks, and special-case others. Also I note that one is an input and one is an output clock. So we could name them this way, and use the separate ID for the input clocks perhaps. I don't think that solves the problem; HW modules and drivers use both clocks, so special-casing the input clocks doesn't make the problem less relevant. If you do add an arbitrary mapping, what would it be? It might as well follow along with the registers so far as it can, since the device tree should describe the hardware. Then the mapping becomes a few lines of code in the driver instead of YAT (yet another table). The mapping would be that the clock IDs are unrelated to the bit numbers in the CAR's reset/clock-enable registers. In practice, this means that to find the reset bit number, you need a table indexed by the .dts's clock number, with the bit number being retrieved from that table. So instead of bit = of_get_u32(1), we'd have bit = table[of_get_u32(1)]. In practice, I believe we'll need such a table anyway, since each clock has many more parameters than just the reset bit ID; some clocks have no reset bit at all, some clocks have a mux but some don't, the inputs to the mux are different for each clock, some have a divider but some don't, where there's a divider or mux, you need to know the register address to configure them, each clock has a different max rate, etc. Having thought a little more about this, I'm definitely leaning towards this way; making the clock ID and register bit completely unrelated just to make it really obvious that you can't use the clock ID as a register bit. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
On Fri, Jan 20, 2012 at 11:32:04PM -0800, Olof Johansson wrote: Hi, On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warren swar...@nvidia.com wrote: Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM: On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote: diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt +* NVIDIA Tegra20 Clock And Reset Controller + +This binding uses the common clock binding: +Documentation/devicetree/bindings/clock/clock-bindings.txt + +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible +for muxing and gating Tegra's clocks, and setting their rates. + +Required properties : +- compatible : Should be nvidia,chip-car +- reg : Should contain CAR registers location and length +- clocks : Should contain phandle and clock specifiers for two clocks: + the 32 KHz 32k_in, and the board-specific oscillator osc. +- clock-names : Should contain a list of strings, with values 32k_in, + and osc. Hmm. I'd prefer to just ditch the notion of clock-names in the cases where it isn't strictly necessary. Just because some vendors don't want to define an order between their clocks doesn't mean it's a good idea for everybody to use that model. In this case, just declaring that the two clocks refs have to be to those two clocks in that order should be sufficient. OK, that seems reasonable. I'm happy using of_clk_get() rather than of_clk_get_by_name(). I guess that means we should just avoid any discussion of clock-output-names too. Sounds good to me. Let's make sure Grant is OK with it too though. Yes, I agree. g. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
On 1/23/2012 6:18 AM, Stephen Warren wrote:
Olof Johansson wrote at Saturday, January 21, 2012 12:32 AM:
On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warrenswar...@nvidia.com wrote:
Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be nvidia,chip-car
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz 32k_in, and the board-specific oscillator osc.
+- clock-names : Should contain a list of strings, with values 32k_in,
+ and osc.
...
+Example:
+
+clocks {
+ clk_32k: oscillator@0 {
If it has a unit addres (@x) it needs a reg property with the same base
address.
I thought everything needed a unit address period? Is the rule more like
the unit address is optional, but if present must match reg, so I can
simply remove @0 and @1 here? I guess that makes a lot more sense.
Nope, you only need a unit address to make a node unique, i.e. if you
have more than one with the same name. It's not something that's been
followed very well on ARM dts files, I have even seen review comments
asking for explicit unit IDs when none are needed.
So you can't remove @0 and @1 here, since there are two oscillator subnodes.
If I keep the unit address, then I need to add a reg property per Mitch's
response. But, then I need #address-cells and #size-cells in the clock
node too. Yuck, since this isn't an addressable bus.
Instead, is it acceptable to simply rename the nodes to e.g.:
clk_32k: clock {...};
osc: crystal {...};
One consideration: These nodes are children of a parent, so that parent
is implicitly a bus node, even though there is no physical hardware
bus. The path resolution rules say that, in the absence of a
#address-cells property in a bus node, the default value is 2. So any
code that implements that rule will think these nodes are missing a
reg property, thus triggering the wildcard node rule, which says
that you can match the node with any unit address.
Whether or not that would cause problems in practice is hard to say. I
think that my Open Firmware implementation would handle it okay, but I
can't speak to the Linux device tree code.
I'm not sure why you thing yuck about synthesizing an address space
for the subnodes. It doesn't seem that bad to me.
In the long term, I believe that osc/crystal is going to continue to
be a top-level object, but clk_32k is actually an output from the PMU
chip, and hence there won't be any naming conflict here anyway...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
Hi Stephen, On Wed, Jan 18, 2012 at 4:16 PM, Stephen Warren swar...@nvidia.com wrote: Document a binding for the Tegra20 CAR (Clock And Reset) Controller, add it to tegra20.dtsi, and configure it for the board in tegra- seaboard.dts. Signed-off-by: Stephen Warren swar...@nvidia.com --- All, Simon Glass is attempting to upstream Tegra USB support in U-Boot. The driver is only instantiated from device tree, and needs to configure clocks for the USB module. Hence, he proposed a clock binding for Tegra. I've read through Grant's proposed common clock bindings and reworked Simon's proposal a little, ending up with the patch below for the kernel. I'd appreciate any comments you have. Grant, can you confirm that it's reasonable to start making use of your proposed common clock bindings in U-Boot, even though they're only an RFC? Grant, there are a couple of FIXMEs in the binding documentation below. Can you give any insight on these? A comment on the shared enable issue: When enabling/disabling clocks, Tegra requires you to reset the HW module that the clock is routed to. Both reset and clock enable registers are part of the CAR. U-Boot currently has an API to do the reset based on a peripheral ID, which simply means a bit number in a set of 3 reset registers. The bits in those registers share the same numbering as the clock enable registers. Hence, to make life easy for U-Boot, I've defined the clock IDs in this binding to be equal to these bit numbers. However, this breaks down where there isn't a 1:1 mapping between reset and clock enable bits, and clocks. For example, there's a single reset and clock enable bit for the SPDIF controller, yet this applies to two clocks; spdif_in and spdif_out. Hence, this simplification for U-Boot breaks down. I think the correct solution is to fix U-Boot not to require this simplification, renumber the clocks in the CAR binding in a completely arbitrary fashion, and require U-Boot to contain a mapping table between CAR's DT clock IDs and any other information related to those clocks. Do you see any alternative? We really need the two SPDIF clocks to be different clock IDs in the binding, since each has a completely independant mux for the clock source/parent, and the two clocks obviously can't share the same clock ID (well, hmm, perhaps they could if we used 2 cells for the specifier, 1 for the bit number, and one more to differentiate clocks that use the same bit...). I'm still inclined to simply push back on U-Boot to do it right. Are SPDIF and VI the only examples of this? If so, perhaps just having a special extra clock ID for those two and mapping in a special way would be more efficient. So two IDs would map to one clock/reset bit but different clocks. Also I note that one is an input and one is an output clock. So we could name them this way, and use the separate ID for the input clocks perhaps. If you do add an arbitrary mapping, what would it be? It might as well follow along with the registers so far as it can, since the device tree should describe the hardware. Then the mapping becomes a few lines of code in the driver instead of YAT (yet another table). Poor U-Boot doesn't even use the SPDIF or vi controllers. .../bindings/clock/nvidia,tegra20-car.txt | 156 arch/arm/boot/dts/tegra-seaboard.dts | 18 +++ arch/arm/boot/dts/tegra20.dtsi | 7 + 3 files changed, 181 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file mode 100644 index 000..71cfdd2 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt @@ -0,0 +1,156 @@ +* NVIDIA Tegra20 Clock And Reset Controller + +This binding uses the common clock binding: +Documentation/devicetree/bindings/clock/clock-bindings.txt + +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible +for muxing and gating Tegra's clocks, and setting their rates. + +Required properties : +- compatible : Should be nvidia,chip-car +- reg : Should contain CAR registers location and length +- clocks : Should contain phandle and clock specifiers for two clocks: + the 32 KHz 32k_in, and the board-specific oscillator osc. +- clock-names : Should contain a list of strings, with values 32k_in, + and osc. +- #clock-cells : Should be 1. + In clock consumers, this cell represents the clock ID exposed by the CAR. + For a list of valid values, see the clock-output-names property. + +Optional properties : +- clock-output-names : Should contain a list of strings defining the clocks + that the CAR provides. The list of names and clock IDs is below. The IDs + may be used in clock specifiers. The names should be listed in this clock- +
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
On 1/20/2012 9:32 PM, Olof Johansson wrote:
Hi,
On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warrenswar...@nvidia.com wrote:
Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be nvidia,chip-car
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz 32k_in, and the board-specific oscillator osc.
+- clock-names : Should contain a list of strings, with values 32k_in,
+ and osc.
Hmm. I'd prefer to just ditch the notion of clock-names in the cases
where it isn't strictly necessary. Just because some vendors don't want
to define an order between their clocks doesn't mean it's a good idea
for everybody to use that model. In this case, just declaring that the
two clocks refs have to be to those two clocks in that order should
be sufficient.
OK, that seems reasonable. I'm happy using of_clk_get() rather than
of_clk_get_by_name(). I guess that means we should just avoid any
discussion of clock-output-names too.
Sounds good to me. Let's make sure Grant is OK with it too though.
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the CAR.
+ For a list of valid values, see the clock-output-names property.
+
+Optional properties :
+- clock-output-names : Should contain a list of strings defining the clocks
+ that the CAR provides. The list of names and clock IDs is below. The IDs
+ may be used in clock specifiers. The names should be listed in this clock-
+ output-names property, sorted in ID order, if this property is present.
+
+ The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+ registers. Later, subsequent IDs will be assigned to all other clocks the
+ CAR controls.
Aren't these names hardcoded per SoC? If so, they can be derived from the
compatible field + output number without having a table in the device tree.
If anything, you might want to enumerate the allowed/expected values, but
actually putting them in a property seems overkill.
Yes, the set of clocks is hard-coded per SoC, and the clock is uniquely
identified by compatible+id.
clock-output-names doesn't actually serve any functional purpose in
Grant's common clock bindings patches; it's more of a documentation
thing. As such, yes, I can remove the suggestion to actually put the
table into the device tree, and rework the binding to simply define
what the mapping is independently.
Again, sounds good to me.
+Example:
+
+clocks {
+ clk_32k: oscillator@0 {
If it has a unit addres (@x) it needs a reg property with the same base
address.
I thought everything needed a unit address period? Is the rule more like
the unit address is optional, but if present must match reg, so I can
simply remove @0 and @1 here? I guess that makes a lot more sense.
Nope, you only need a unit address to make a node unique, i.e. if you
have more than one with the same name. It's not something that's been
followed very well on ARM dts files, I have even seen review comments
asking for explicit unit IDs when none are needed.
So you can't remove @0 and @1 here, since there are two oscillator subnodes.
I'm not 100% sure if you have to have the unit address represented as
reg or not, but it should probably be represented by _something_ in
the properties of the node. Mitch? Segher? :)
unit-address is, by definition, the first address component of reg
+ compatible = fixed-clock;
+ #clock-cells =0;
+ clock-frequency =32768;
+ };
+
+ osc: oscillator@1 {
+ compatible = fixed-clock;
+ #clock-cells =0;
+ clock-frequency =1200;
+ };
+};
-Olof
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
Hi,
On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warren swar...@nvidia.com wrote:
Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be nvidia,chip-car
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz 32k_in, and the board-specific oscillator osc.
+- clock-names : Should contain a list of strings, with values 32k_in,
+ and osc.
Hmm. I'd prefer to just ditch the notion of clock-names in the cases
where it isn't strictly necessary. Just because some vendors don't want
to define an order between their clocks doesn't mean it's a good idea
for everybody to use that model. In this case, just declaring that the
two clocks refs have to be to those two clocks in that order should
be sufficient.
OK, that seems reasonable. I'm happy using of_clk_get() rather than
of_clk_get_by_name(). I guess that means we should just avoid any
discussion of clock-output-names too.
Sounds good to me. Let's make sure Grant is OK with it too though.
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the
CAR.
+ For a list of valid values, see the clock-output-names property.
+
+Optional properties :
+- clock-output-names : Should contain a list of strings defining the
clocks
+ that the CAR provides. The list of names and clock IDs is below. The IDs
+ may be used in clock specifiers. The names should be listed in this
clock-
+ output-names property, sorted in ID order, if this property is present.
+
+ The first 96 clocks are numbered to match the bits in the CAR's
CLK_OUT_ENB
+ registers. Later, subsequent IDs will be assigned to all other clocks
the
+ CAR controls.
Aren't these names hardcoded per SoC? If so, they can be derived from the
compatible field + output number without having a table in the device tree.
If anything, you might want to enumerate the allowed/expected values, but
actually putting them in a property seems overkill.
Yes, the set of clocks is hard-coded per SoC, and the clock is uniquely
identified by compatible+id.
clock-output-names doesn't actually serve any functional purpose in
Grant's common clock bindings patches; it's more of a documentation
thing. As such, yes, I can remove the suggestion to actually put the
table into the device tree, and rework the binding to simply define
what the mapping is independently.
Again, sounds good to me.
+Example:
+
+clocks {
+ clk_32k: oscillator@0 {
If it has a unit addres (@x) it needs a reg property with the same base
address.
I thought everything needed a unit address period? Is the rule more like
the unit address is optional, but if present must match reg, so I can
simply remove @0 and @1 here? I guess that makes a lot more sense.
Nope, you only need a unit address to make a node unique, i.e. if you
have more than one with the same name. It's not something that's been
followed very well on ARM dts files, I have even seen review comments
asking for explicit unit IDs when none are needed.
So you can't remove @0 and @1 here, since there are two oscillator subnodes.
I'm not 100% sure if you have to have the unit address represented as
reg or not, but it should probably be represented by _something_ in
the properties of the node. Mitch? Segher? :)
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 32768;
+ };
+
+ osc: oscillator@1 {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 1200;
+ };
+};
-Olof
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be nvidia,chip-car
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz 32k_in, and the board-specific oscillator osc.
+- clock-names : Should contain a list of strings, with values 32k_in,
+ and osc.
Hmm. I'd prefer to just ditch the notion of clock-names in the cases
where it isn't strictly necessary. Just because some vendors don't want
to define an order between their clocks doesn't mean it's a good idea
for everybody to use that model. In this case, just declaring that the
two clocks refs have to be to those two clocks in that order should
be sufficient.
OK, that seems reasonable. I'm happy using of_clk_get() rather than
of_clk_get_by_name(). I guess that means we should just avoid any
discussion of clock-output-names too.
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the CAR.
+ For a list of valid values, see the clock-output-names property.
+
+Optional properties :
+- clock-output-names : Should contain a list of strings defining the clocks
+ that the CAR provides. The list of names and clock IDs is below. The IDs
+ may be used in clock specifiers. The names should be listed in this
clock-
+ output-names property, sorted in ID order, if this property is present.
+
+ The first 96 clocks are numbered to match the bits in the CAR's
CLK_OUT_ENB
+ registers. Later, subsequent IDs will be assigned to all other clocks the
+ CAR controls.
Aren't these names hardcoded per SoC? If so, they can be derived from the
compatible field + output number without having a table in the device tree.
If anything, you might want to enumerate the allowed/expected values, but
actually putting them in a property seems overkill.
Yes, the set of clocks is hard-coded per SoC, and the clock is uniquely
identified by compatible+id.
clock-output-names doesn't actually serve any functional purpose in
Grant's common clock bindings patches; it's more of a documentation
thing. As such, yes, I can remove the suggestion to actually put the
table into the device tree, and rework the binding to simply define
what the mapping is independently.
...
+Example:
+
+clocks {
+ clk_32k: oscillator@0 {
If it has a unit addres (@x) it needs a reg property with the same base
address.
I thought everything needed a unit address period? Is the rule more like
the unit address is optional, but if present must match reg, so I can
simply remove @0 and @1 here? I guess that makes a lot more sense.
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 32768;
+ };
+
+ osc: oscillator@1 {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 1200;
+ };
+};
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
Hi,
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
.../bindings/clock/nvidia,tegra20-car.txt | 156
arch/arm/boot/dts/tegra-seaboard.dts | 18 +++
arch/arm/boot/dts/tegra20.dtsi |7 +
3 files changed, 181 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
new file mode 100644
index 000..71cfdd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -0,0 +1,156 @@
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be nvidia,chip-car
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz 32k_in, and the board-specific oscillator osc.
+- clock-names : Should contain a list of strings, with values 32k_in,
+ and osc.
Hmm. I'd prefer to just ditch the notion of clock-names in the cases
where it isn't strictly necessary. Just because some vendors don't want
to define an order between their clocks doesn't mean it's a good idea
for everybody to use that model. In this case, just declaring that the
two clocks refs have to be to those two clocks in that order should
be sufficient.
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the CAR.
+ For a list of valid values, see the clock-output-names property.
+
+Optional properties :
+- clock-output-names : Should contain a list of strings defining the clocks
+ that the CAR provides. The list of names and clock IDs is below. The IDs
+ may be used in clock specifiers. The names should be listed in this clock-
+ output-names property, sorted in ID order, if this property is present.
+
+ The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+ registers. Later, subsequent IDs will be assigned to all other clocks the
+ CAR controls.
Aren't these names hardcoded per SoC? If so, they can be derived from the
compatible field + output number without having a table in the device tree.
If anything, you might want to enumerate the allowed/expected values, but
actually putting them in a property seems overkill.
[...]
+Example:
+
+clocks {
+ clk_32k: oscillator@0 {
If it has a unit addres (@x) it needs a reg property with the same base
address.
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 32768;
+ };
+
+ osc: oscillator@1 {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 1200;
+ };
+};
+
+tegar_car: clock@60006000 {
typo? tegra_car?
+ compatible = tegra,periphclk;
+ reg = 0x60006000 1000;
+ clocks = clk_32k osc;
+ clock-names = 32k_in, osc;
+ #clock-cells = 1;
+};
+
+usb@c5004000 {
+ ...
+ clocks = tegra_car 58; /* usb2 */
+};
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
