* Dan Murphy <dmur...@ti.com> [140505 13:10]:
> +
> +Required parent properties:
> +- compatible : Should be one of,
> + "ti,omap4-prm" for OMAP4 PRM instances
> + "ti,omap5-prm" for OMAP5 PRM instances
> + "ti,dra7-prm" for DRA7xx PRM instances
> + "ti,am4-prcm" for AM43xx PRCM instances
> + "ti,am3-prcm" for AM33xx PRCM instances
> +
> +Required child reset property:
> +- compatible : Should be
> + "resets" for All TI SoCs
> +
> +example:
> + prm: prm@4ae06000 {
> + compatible = "ti,omap5-prm";
> + reg = <0x4ae06000 0x3000>;
> +
> + prm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #reset-cells = <1>;
> + };
> + };
The reg entries you have in the example below has different format
compared to this?
> +Reset node declaration
> +==============================================
> +The reset node is declared in a parent child relationship. The main parent
> +is the PRCM module which contains the base address. The first child within
> +the reset parent declares the target modules reset name. This is followed by
> +the control and status offsets.
> +
> +Within the first reset child node is a secondary child node which declares
> the
> +reset signal of interest. Under this node the control and status bits
> +are declared. These bits declare the bit mask for the target reset.
> +
> +
> +Required properties:
> +reg - This is the register offset from the PRCM parent.
> + This must be declared as:
> +
> + reg = <control register offset>,
> + <status register offset>;
> +
> +control-bit - This is the bit within the register which controls the reset
> + of the target module. This is declared as a bit mask for the register.
> +status-bit - This is the bit within the register which contains the status of
> + the reset of the target module.
> + This is declared as a bit mask for the register.
> +
> +example:
> +&prm_resets {
> + dsp_rstctrl {
> + reg = <0x1c00>,
> + <0x1c04>;
Shouldn't this be start and size instead of start and end here?
> + dsp_reset: dsp_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +};
Are the control-bit and status-bit always the same? If so, you can
keep that knowlede private to the the driver.
And maybe you can have the bit offset in a reg property here to
avoid adding any custom properties? Something like:
dsp_reset: reset@1 {
reg = 1;
};
If reg is not suitable for that, it seems that some generic property
to describe the bit offset is needed by quite a few drivers
anyways, for things like clocks and regulators.
> +Client Node Declaration
> +==============================================
> +This is the consumer of the parent node to declare what resets this
> +particular module is interested in.
> +
> +example:
> + src: src@55082000 {
> + resets = <&reset_src phandle>;
> + reset-names = "<reset_name>";
> + };
> +
> +Required Properties:
> +reset_src - This is the parent DT entry for the reset controller
> +phandle - This is the phandle of the specific reset to be used by the clien
> + driver.
> +reset-names - This is the reset name of module that the device driver
> + needs to be able to reset. This value must correspond to a value within
> + the reset controller array.
> +
> +example:
> +resets = <&prm_resets &dsp_mmu_reset>;
> +reset-names = "dsp_mmu_reset";
This part looks OK to me, not sure if we need the reset-names property
if we have one already why not.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
