[v2] of: Documentation: change overlay example to use current syntax
diff mbox series

Message ID 1580171838-1770-1-git-send-email-frowand.list@gmail.com
State Accepted
Commit 9ae8578b517a50905adf1d6a00bc02c676710e74
Headers show
Series
  • [v2] of: Documentation: change overlay example to use current syntax
Related show

Commit Message

Frank Rowand Jan. 28, 2020, 12:37 a.m. UTC
From: Frank Rowand <frank.rowand@sony.com>

The overlay implementation details in the compiled (DTB) file are
now properly implemented by the dtc compiler and should no longer
be hard coded in the source file.

Signed-off-by: Frank Rowand <frank.rowand@sony.com>
---

changes since v1:
  - fixed typo in patch comment (implementation)

 Documentation/devicetree/overlay-notes.txt | 85 ++++++++++++------------------
 1 file changed, 35 insertions(+), 50 deletions(-)

Comments

Geert Uytterhoeven Jan. 28, 2020, 8:37 a.m. UTC | #1
On Tue, Jan 28, 2020 at 1:38 AM <frowand.list@gmail.com> wrote:
> From: Frank Rowand <frank.rowand@sony.com>
>
> The overlay implementation details in the compiled (DTB) file are
> now properly implemented by the dtc compiler and should no longer
> be hard coded in the source file.
>
> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
> ---
>
> changes since v1:
>   - fixed typo in patch comment (implementation)

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert
Frank Rowand May 4, 2020, 8:16 p.m. UTC | #2
Hi Rob,

Ping.

There is a conflict between this and Mauro's v3 patch at:

  https://lore.kernel.org/r/cover.1586961793.git.mchehab+huawei@kernel.org

I pointed out the conflict to Mauro in his v2 patch, and he said he would
rebase on a new -next to resolve the conflict.  Unfortunately my patch
was not in -next, so the conflict remains.

If Mauro's patches should go in first, I can redo my patches on top of
his, after his go in.

-Frank

On 1/27/20 6:37 PM, frowand.list@gmail.com wrote:
> From: Frank Rowand <frank.rowand@sony.com>
> 
> The overlay implementation details in the compiled (DTB) file are
> now properly implemented by the dtc compiler and should no longer
> be hard coded in the source file.
> 
> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
> ---
> 
> changes since v1:
>   - fixed typo in patch comment (implementation)
> 
>  Documentation/devicetree/overlay-notes.txt | 85 ++++++++++++------------------
>  1 file changed, 35 insertions(+), 50 deletions(-)
> 
> diff --git a/Documentation/devicetree/overlay-notes.txt b/Documentation/devicetree/overlay-notes.txt
> index 725fb8d255c1..fddc63da7dba 100644
> --- a/Documentation/devicetree/overlay-notes.txt
> +++ b/Documentation/devicetree/overlay-notes.txt
> @@ -19,6 +19,7 @@ Lets take an example where we have a foo board with the following base tree:
>  
>  ---- foo.dts -----------------------------------------------------------------
>  	/* FOO platform */
> +	/dts-v1/;
>  	/ {
>  		compatible = "corp,foo";
>  
> @@ -30,30 +31,25 @@ Lets take an example where we have a foo board with the following base tree:
>  		ocp: ocp {
>  			/* peripherals that are always instantiated */
>  			peripheral1 { ... };
> -		}
> +		};
>  	};
>  ---- foo.dts -----------------------------------------------------------------
>  
> -The overlay bar.dts, when loaded (and resolved as described in [1]) should
> +The overlay bar.dts,
>  
> ----- bar.dts -----------------------------------------------------------------
> -/plugin/;	/* allow undefined label references and record them */
> -/ {
> -	....	/* various properties for loader use; i.e. part id etc. */
> -	fragment@0 {
> -		target = <&ocp>;
> -		__overlay__ {
> -			/* bar peripheral */
> -			bar {
> -				compatible = "corp,bar";
> -				... /* various properties and child nodes */
> -			}
> +---- bar.dts - overlay target location by label ------------------------------
> +	/dts-v1/;
> +	/plugin/;
> +	&ocp {
> +		/* bar peripheral */
> +		bar {
> +			compatible = "corp,bar";
> +			... /* various properties and child nodes */
>  		};
>  	};
> -};
>  ---- bar.dts -----------------------------------------------------------------
>  
> -result in foo+bar.dts
> +when loaded (and resolved as described in [1]) should result in foo+bar.dts
>  
>  ---- foo+bar.dts -------------------------------------------------------------
>  	/* FOO platform + bar peripheral */
> @@ -73,8 +69,8 @@ result in foo+bar.dts
>  			bar {
>  				compatible = "corp,bar";
>  				... /* various properties and child nodes */
> -			}
> -		}
> +			};
> +		};
>  	};
>  ---- foo+bar.dts -------------------------------------------------------------
>  
> @@ -82,6 +78,27 @@ As a result of the overlay, a new device node (bar) has been created
>  so a bar platform device will be registered and if a matching device driver
>  is loaded the device will be created as expected.
>  
> +If the base DT was not compiled with the -@ option then the "&ocp" label
> +will not be available to resolve the overlay node(s) to the proper location
> +in the base DT. In this case, the target path can be provided. The target
> +location by label syntax is preferred because the overlay can be applied to
> +any base DT containing the label, no matter where the label occurs in the DT.
> +
> +The above bar.dts example modified to use target path syntax is:
> +
> +---- bar.dts - overlay target location by explicit path ----------------------
> +	/dts-v1/;
> +	/plugin/;
> +	&{/ocp} {
> +		/* bar peripheral */
> +		bar {
> +			compatible = "corp,bar";
> +			... /* various properties and child nodes */
> +		}
> +	};
> +---- bar.dts -----------------------------------------------------------------
> +
> +
>  Overlay in-kernel API
>  --------------------------------
>  
> @@ -105,35 +122,3 @@ enum of_overlay_notify_action for details.
>  Note that a notifier callback is not supposed to store pointers to a device
>  tree node or its content beyond OF_OVERLAY_POST_REMOVE corresponding to the
>  respective node it received.
> -
> -Overlay DTS Format
> -------------------
> -
> -The DTS of an overlay should have the following format:
> -
> -{
> -	/* ignored properties by the overlay */
> -
> -	fragment@0 {	/* first child node */
> -
> -		target=<phandle>;	/* phandle target of the overlay */
> -	or
> -		target-path="/path";	/* target path of the overlay */
> -
> -		__overlay__ {
> -			property-a;	/* add property-a to the target */
> -			node-a {	/* add to an existing, or create a node-a */
> -				...
> -			};
> -		};
> -	}
> -	fragment@1 {	/* second child node */
> -		...
> -	};
> -	/* more fragments follow */
> -}
> -
> -Using the non-phandle based target method allows one to use a base DT which does
> -not contain a __symbols__ node, i.e. it was not compiled with the -@ option.
> -The __symbols__ node is only required for the target=<phandle> method, since it
> -contains the information required to map from a phandle to a tree location.
>
Rob Herring May 4, 2020, 8:56 p.m. UTC | #3
On Mon, Jan 27, 2020 at 06:37:18PM -0600, frowand.list@gmail.com wrote:
> From: Frank Rowand <frank.rowand@sony.com>
> 
> The overlay implementation details in the compiled (DTB) file are
> now properly implemented by the dtc compiler and should no longer
> be hard coded in the source file.
> 
> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
> ---
> 
> changes since v1:
>   - fixed typo in patch comment (implementation)
> 
>  Documentation/devicetree/overlay-notes.txt | 85 ++++++++++++------------------
>  1 file changed, 35 insertions(+), 50 deletions(-)

Applied. Sorry this slipped thru the cracks.

Rob

Patch
diff mbox series

diff --git a/Documentation/devicetree/overlay-notes.txt b/Documentation/devicetree/overlay-notes.txt
index 725fb8d255c1..fddc63da7dba 100644
--- a/Documentation/devicetree/overlay-notes.txt
+++ b/Documentation/devicetree/overlay-notes.txt
@@ -19,6 +19,7 @@  Lets take an example where we have a foo board with the following base tree:
 
 ---- foo.dts -----------------------------------------------------------------
 	/* FOO platform */
+	/dts-v1/;
 	/ {
 		compatible = "corp,foo";
 
@@ -30,30 +31,25 @@  Lets take an example where we have a foo board with the following base tree:
 		ocp: ocp {
 			/* peripherals that are always instantiated */
 			peripheral1 { ... };
-		}
+		};
 	};
 ---- foo.dts -----------------------------------------------------------------
 
-The overlay bar.dts, when loaded (and resolved as described in [1]) should
+The overlay bar.dts,
 
----- bar.dts -----------------------------------------------------------------
-/plugin/;	/* allow undefined label references and record them */
-/ {
-	....	/* various properties for loader use; i.e. part id etc. */
-	fragment@0 {
-		target = <&ocp>;
-		__overlay__ {
-			/* bar peripheral */
-			bar {
-				compatible = "corp,bar";
-				... /* various properties and child nodes */
-			}
+---- bar.dts - overlay target location by label ------------------------------
+	/dts-v1/;
+	/plugin/;
+	&ocp {
+		/* bar peripheral */
+		bar {
+			compatible = "corp,bar";
+			... /* various properties and child nodes */
 		};
 	};
-};
 ---- bar.dts -----------------------------------------------------------------
 
-result in foo+bar.dts
+when loaded (and resolved as described in [1]) should result in foo+bar.dts
 
 ---- foo+bar.dts -------------------------------------------------------------
 	/* FOO platform + bar peripheral */
@@ -73,8 +69,8 @@  result in foo+bar.dts
 			bar {
 				compatible = "corp,bar";
 				... /* various properties and child nodes */
-			}
-		}
+			};
+		};
 	};
 ---- foo+bar.dts -------------------------------------------------------------
 
@@ -82,6 +78,27 @@  As a result of the overlay, a new device node (bar) has been created
 so a bar platform device will be registered and if a matching device driver
 is loaded the device will be created as expected.
 
+If the base DT was not compiled with the -@ option then the "&ocp" label
+will not be available to resolve the overlay node(s) to the proper location
+in the base DT. In this case, the target path can be provided. The target
+location by label syntax is preferred because the overlay can be applied to
+any base DT containing the label, no matter where the label occurs in the DT.
+
+The above bar.dts example modified to use target path syntax is:
+
+---- bar.dts - overlay target location by explicit path ----------------------
+	/dts-v1/;
+	/plugin/;
+	&{/ocp} {
+		/* bar peripheral */
+		bar {
+			compatible = "corp,bar";
+			... /* various properties and child nodes */
+		}
+	};
+---- bar.dts -----------------------------------------------------------------
+
+
 Overlay in-kernel API
 --------------------------------
 
@@ -105,35 +122,3 @@  enum of_overlay_notify_action for details.
 Note that a notifier callback is not supposed to store pointers to a device
 tree node or its content beyond OF_OVERLAY_POST_REMOVE corresponding to the
 respective node it received.
-
-Overlay DTS Format
-------------------
-
-The DTS of an overlay should have the following format:
-
-{
-	/* ignored properties by the overlay */
-
-	fragment@0 {	/* first child node */
-
-		target=<phandle>;	/* phandle target of the overlay */
-	or
-		target-path="/path";	/* target path of the overlay */
-
-		__overlay__ {
-			property-a;	/* add property-a to the target */
-			node-a {	/* add to an existing, or create a node-a */
-				...
-			};
-		};
-	}
-	fragment@1 {	/* second child node */
-		...
-	};
-	/* more fragments follow */
-}
-
-Using the non-phandle based target method allows one to use a base DT which does
-not contain a __symbols__ node, i.e. it was not compiled with the -@ option.
-The __symbols__ node is only required for the target=<phandle> method, since it
-contains the information required to map from a phandle to a tree location.