Re: [PATCHv3] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




* Stephen Boyd <sboyd@xxxxxxxxxxxxxx> [170419 09:58]:
> On 02/13, Tero Kristo wrote:
> > On 24/01/17 00:17, Tony Lindgren wrote:
> > >Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> > >clock controller instance for each interconnect target module. The clkctrl
> > >controls functional and interface clocks for the module.
> > >
> > >The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> > >With this binding and a related clock device driver we can start moving the
> > >clkctrl clock handling to live in drivers/clk/ti.
> > >
> > >Note that this binding allows keeping the clockdomain related parts out of
> > >drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> > >a separate driver in drivers/soc/ti and genpd. If the clockdomain driver
> > >needs to know it's clocks, we can just set the the clkctrl device
> > >instances to be children of the related clockdomain device.
> > >
> > >Each clkctrl clock can have multiple optional gate clocks, and multiple
> > >optional mux clocks. To represent this in device tree, it seems that
> > >it is best done using four clock cells #clock-cells = <2> property.
> > >
> > >The reasons for using #clock-cells = <2> are:
> > >
> > >1. We need to specify the clkctrl offset from the instance base. Otherwise
> > >   we end up with a large number of device tree nodes that need to be
> > >   patched when new clocks are discovered in a clkctrl clock with minor
> > >   hardware revision changes for example
> > >
> > >2. On omap5 CM_L3INIT_USB_HOST_HS_CLKCTRL has ten OPTFCLKEN bits. So we
> > >   need to use a separate cell for optional gate clocks to avoid address
> > >   space conflicts
> > >
> > >There is probably no need to list input clocks for each clkctrl clock
> > >instance in the binding. If we want to add them, the standard clocks
> > >binding can be used for that.
> > >
> > >For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> > >Mapping Summary" for example. It shows one instance of a clkctrl clock
> > >controller with multiple clkctrl registers.
> > >
> > >Cc: Paul Walmsley <paul@xxxxxxxxx>
> > >Acked-by: Rob Herring <robh@xxxxxxxxxx>
> > >Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
> > 
> > This binding works for me, so:
> > 
> > Acked-by: Tero Kristo <t-kristo@xxxxxx>
> > 
> 
> This wasn't in the TI clk PR. Shall I merge this to clk-next?

Tero has this included in his clkctrl series and there's one typo
fix needed where the doc still says #clock-cells = <4> instead of <2>.

I suggest let's wait a bit on this and let's try to get the clkctrl
driver parts into next early after v4.12-rc1 if no issues.

It seems the clkctrl series clock driver part is pretty much
ready to go, the remaining issues seem to be in the hwmod code.

Regards,

Tony
--
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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux