Re: [PATCH 1/2] of: Sort reserved_mem related code

2021-11-29 Thread Rob Herring
On Fri, Nov 19, 2021 at 03:58:18PM +0800, Calvin Zhang wrote:
> Move code about parsing /reserved-memory and initializing of
> reserved_mems array to of_reserved_mem.c for better modularity.
> 
> Rename array name from reserved_mem to reserved_mems to distinguish
> from type definition.
> 
> Signed-off-by: Calvin Zhang 
> ---
>  drivers/of/fdt.c| 108 +
>  drivers/of/of_private.h |  12 ++-
>  drivers/of/of_reserved_mem.c| 163 ++--
>  include/linux/of_reserved_mem.h |   4 +
>  4 files changed, 149 insertions(+), 138 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index bdca35284ceb..445af4e69300 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -80,7 +80,7 @@ void __init of_fdt_limit_memory(int limit)
>   }
>  }
>  
> -static bool of_fdt_device_is_available(const void *blob, unsigned long node)
> +bool of_fdt_device_is_available(const void *blob, unsigned long node)
>  {
>   const char *status = fdt_getprop(blob, node, "status", NULL);
>  
> @@ -476,7 +476,7 @@ void *initial_boot_params __ro_after_init;
>  
>  static u32 of_fdt_crc32;
>  
> -static int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
> +int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
>   phys_addr_t size, bool nomap)

I think you can move this function too if you change the nomap==false 
callers to just call memblock_reserve directly.


>  {
>   if (nomap) {
> @@ -492,108 +492,6 @@ static int __init 
> early_init_dt_reserve_memory_arch(phys_addr_t base,
>   return memblock_reserve(base, size);
>  }
>  
> -/*
> - * __reserved_mem_reserve_reg() - reserve all memory described in 'reg' 
> property
> - */
> -static int __init __reserved_mem_reserve_reg(unsigned long node,
> -  const char *uname)
> -{
> - int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
> - phys_addr_t base, size;
> - int len;
> - const __be32 *prop;
> - int first = 1;
> - bool nomap;
> -
> - prop = of_get_flat_dt_prop(node, "reg", );
> - if (!prop)
> - return -ENOENT;
> -
> - if (len && len % t_len != 0) {
> - pr_err("Reserved memory: invalid reg property in '%s', skipping 
> node.\n",
> -uname);
> - return -EINVAL;
> - }
> -
> - nomap = of_get_flat_dt_prop(node, "no-map", NULL) != NULL;
> -
> - while (len >= t_len) {
> - base = dt_mem_next_cell(dt_root_addr_cells, );
> - size = dt_mem_next_cell(dt_root_size_cells, );
> -
> - if (size &&
> - early_init_dt_reserve_memory_arch(base, size, nomap) == 0)
> - pr_debug("Reserved memory: reserved region for node 
> '%s': base %pa, size %lu MiB\n",
> - uname, , (unsigned long)(size / SZ_1M));
> - else
> - pr_info("Reserved memory: failed to reserve memory for 
> node '%s': base %pa, size %lu MiB\n",
> - uname, , (unsigned long)(size / SZ_1M));
> -
> - len -= t_len;
> - if (first) {
> - fdt_reserved_mem_save_node(node, uname, base, size);
> - first = 0;
> - }
> - }
> - return 0;
> -}
> -
> -/*
> - * __reserved_mem_check_root() - check if #size-cells, #address-cells 
> provided
> - * in /reserved-memory matches the values supported by the current 
> implementation,
> - * also check if ranges property has been provided
> - */
> -static int __init __reserved_mem_check_root(unsigned long node)
> -{
> - const __be32 *prop;
> -
> - prop = of_get_flat_dt_prop(node, "#size-cells", NULL);
> - if (!prop || be32_to_cpup(prop) != dt_root_size_cells)
> - return -EINVAL;
> -
> - prop = of_get_flat_dt_prop(node, "#address-cells", NULL);
> - if (!prop || be32_to_cpup(prop) != dt_root_addr_cells)
> - return -EINVAL;
> -
> - prop = of_get_flat_dt_prop(node, "ranges", NULL);
> - if (!prop)
> - return -EINVAL;
> - return 0;
> -}
> -
> -/*
> - * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory
> - */
> -static int __init fdt_scan_reserved_mem(void)
> -{
> - int node, child;
> - const void *fdt = initial_boot_params;
> -
> - node = fdt_path_offset(fdt, "/reserved-memory");
> - if (node < 0)
> - return -ENODEV;
> -
> - if (__reserved_mem_check_root(node) != 0) {
> - pr_err("Reserved memory: unsupported node format, ignoring\n");
> - return -EINVAL;
> - }
> -
> - fdt_for_each_subnode(child, fdt, node) {
> - const char *uname;
> - int err;
> -
> - if (!of_fdt_device_is_available(fdt, child))
> - continue;
> -
> - uname = fdt_get_name(fdt, child, NULL);
> -
> -   

Re: [PATCH v5 12/19] dt-bindings: usb: dwc3: Add synopsys, dwc3 compatible string

2020-12-09 Thread Rob Herring
On Sat, 05 Dec 2020 18:24:19 +0300, Serge Semin wrote:
> The DWC USB3 driver and some DTS files like Exynos 5250, Keystone k2e, etc
> expects the DWC USB3 DT node to have the compatible string with the
> "synopsys" vendor prefix. Let's add the corresponding compatible string to
> the controller DT schema, but mark it as deprecated seeing the Synopsys,
> Inc. is presented with just "snps" vendor prefix.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Drop quotes from around the compat string constant.
> 
> Changelog v4:
> - Get the patch back, since we can't discard the deprecated prefix from the
>   driver.
> ---
>  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v5 01/19] dt-bindings: usb: usb-hcd: Detach generic USB controller properties

2020-12-09 Thread Rob Herring
On Sat, 05 Dec 2020 18:24:08 +0300, Serge Semin wrote:
> There can be three distinctive types of the USB controllers: USB hosts,
> USB peripherals/gadgets and USB OTG, which can switch from one role to
> another. In order to have that hierarchy handled in the DT binding files,
> we need to collect common properties in a common DT schema and specific
> properties in dedicated schemas. Seeing the usb-hcd.yaml DT schema is
> dedicated for the USB host controllers only, let's move some common
> properties from there into the usb.yaml schema. So the later would be
> available to evaluate all currently supported types of the USB
> controllers.
> 
> While at it add an explicit "additionalProperties: true" into the
> usb-hcd.yaml as setting the additionalProperties/unevaluateProperties
> properties is going to be get mandatory soon.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v4:
> - This is a new patch created as a result of the comment left
>   by Chunfeng Yun in v3
> 
> Changelog v5:
> - Discard duplicated additionalProperties property definition.
> ---
>  .../devicetree/bindings/usb/usb-hcd.yaml  | 14 ++---
>  .../devicetree/bindings/usb/usb.yaml  | 29 +++
>  2 files changed, 31 insertions(+), 12 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb.yaml
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v5 10/19] dt-bindings: usb: Convert DWC USB3 bindings to DT schema

2020-12-08 Thread Rob Herring
On Sat, 05 Dec 2020 18:24:17 +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available legacy text-based DWC USB3 bindings to the DT schema
> and make sure the DWC USB3 nodes are also validated against the
> usb-xhci.yaml schema.
> 
> Note 1. we have to discard the nodename restriction of being prefixed with
> "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
> are supposed to be named as "^usb(@.*)".
> 
> Note 2. The clock-related properties are marked as optional to match the
> DWC USB3 driver expectation and to improve the bindings mainainability
> so in case if there is a glue-node it would the responsible for the
> clocks initialization.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Discard '|' from the descriptions, since we don't need to preserve
>   the text formatting in any of them.
> - Drop quotes from around the string constants.
> - Fix the "clock-names" prop description to be referring the enumerated
>   clock-names instead of the ones from the Databook.
> 
> Changelog v3:
> - Apply usb-xhci.yaml# schema only if the controller is supposed to work
>   as either host or otg.
> 
> Changelog v4:
> - Apply usb-drd.yaml schema first. If the controller is configured
>   to work in a gadget mode only, then apply the usb.yaml schema too,
>   otherwise apply the usb-xhci.yaml schema.
> - Discard the Rob'es Reviewed-by tag. Please review the patch one more
>   time.
> 
> Changelog v5:
> - Add "snps,dis-split-quirk" property to the DWC USB3 DT schema.
> - Add a commit log text about the clock-related property changes.
> - Make sure dr_mode exist to apply the USB-gadget-only schema.
> ---
>  .../devicetree/bindings/usb/dwc3.txt  | 128 ---
>  .../devicetree/bindings/usb/snps,dwc3.yaml| 312 ++
>  2 files changed, 312 insertions(+), 128 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
>  create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v5 19/19] dt-bindings: usb: intel, keembay-dwc3: Validate DWC3 sub-node

2020-12-07 Thread Rob Herring
On Sat, 05 Dec 2020 18:24:26 +0300, Serge Semin wrote:
> Intel Keem Bay DWC3 compatible DT nodes are supposed to have a DWC USB3
> compatible sub-node to describe a fully functioning USB interface. Let's
> use the available DWC USB3 DT schema to validate the Qualcomm DWC3
> sub-nodes.
> 
> Note since the generic DWC USB3 DT node is supposed to be named as generic
> USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
> regexp and fix the DT node example.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v5:
> - This is a new patch created for the new Intel Keem Bay bindings file,
>   which has been added just recently.
> ---
>  .../devicetree/bindings/usb/intel,keembay-dwc3.yaml  | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v5 01/19] dt-bindings: usb: usb-hcd: Detach generic USB controller properties

2020-12-07 Thread Rob Herring
On Sat, 05 Dec 2020 18:24:08 +0300, Serge Semin wrote:
> There can be three distinctive types of the USB controllers: USB hosts,
> USB peripherals/gadgets and USB OTG, which can switch from one role to
> another. In order to have that hierarchy handled in the DT binding files,
> we need to collect common properties in a common DT schema and specific
> properties in dedicated schemas. Seeing the usb-hcd.yaml DT schema is
> dedicated for the USB host controllers only, let's move some common
> properties from there into the usb.yaml schema. So the later would be
> available to evaluate all currently supported types of the USB
> controllers.
> 
> While at it add an explicit "additionalProperties: true" into the
> usb-hcd.yaml as setting the additionalProperties/unevaluateProperties
> properties is going to be get mandatory soon.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v4:
> - This is a new patch created as a result of the comment left
>   by Chunfeng Yun in v3
> 
> Changelog v5:
> - Discard duplicated additionalProperties property definition.
> ---
>  .../devicetree/bindings/usb/usb-hcd.yaml  | 14 ++---
>  .../devicetree/bindings/usb/usb.yaml  | 29 +++
>  2 files changed, 31 insertions(+), 12 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
schemas/usb/usb-hcd.yaml: ignoring, error in schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/usb-hcd.yaml:
 'anyOf' conditional failed, one must be fixed:
'properties' is a required property
'patternProperties' is a required property
schemas/usb/usb-hcd.yaml: ignoring, error in schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/usb-hcd.yaml:
 ignoring, error in schema: 
warning: no schema found in file: 
./Documentation/devicetree/bindings/usb/usb-hcd.yaml
schemas/usb/usb-hcd.yaml: ignoring, error in schema: 
dt-validate: recursion error: Check for prior errors in a referenced schema
schemas/usb/usb-hcd.yaml: ignoring, error in schema: 
dt-validate: recursion error: Check for prior errors in a referenced schema
schemas/usb/usb-hcd.yaml: ignoring, error in schema: 
dt-validate: recursion error: Check for prior errors in a referenced schema
schemas/usb/usb-hcd.yaml: ignoring, error in schema: 
dt-validate: recursion error: Check for prior errors in a referenced schema
schemas/usb/usb-hcd.yaml: ignoring, error in schema: 
dt-validate: recursion error: Check for prior errors in a referenced schema
dt-validate: recursion error: Check for prior errors in a referenced schema


See https://patchwork.ozlabs.org/patch/1411574

The base for the patch is generally the last rc1. Any dependencies
should be noted.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v5 10/19] dt-bindings: usb: Convert DWC USB3 bindings to DT schema

2020-12-07 Thread Rob Herring
On Sat, 05 Dec 2020 18:24:17 +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available legacy text-based DWC USB3 bindings to the DT schema
> and make sure the DWC USB3 nodes are also validated against the
> usb-xhci.yaml schema.
> 
> Note 1. we have to discard the nodename restriction of being prefixed with
> "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
> are supposed to be named as "^usb(@.*)".
> 
> Note 2. The clock-related properties are marked as optional to match the
> DWC USB3 driver expectation and to improve the bindings mainainability
> so in case if there is a glue-node it would the responsible for the
> clocks initialization.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Discard '|' from the descriptions, since we don't need to preserve
>   the text formatting in any of them.
> - Drop quotes from around the string constants.
> - Fix the "clock-names" prop description to be referring the enumerated
>   clock-names instead of the ones from the Databook.
> 
> Changelog v3:
> - Apply usb-xhci.yaml# schema only if the controller is supposed to work
>   as either host or otg.
> 
> Changelog v4:
> - Apply usb-drd.yaml schema first. If the controller is configured
>   to work in a gadget mode only, then apply the usb.yaml schema too,
>   otherwise apply the usb-xhci.yaml schema.
> - Discard the Rob'es Reviewed-by tag. Please review the patch one more
>   time.
> 
> Changelog v5:
> - Add "snps,dis-split-quirk" property to the DWC USB3 DT schema.
> - Add a commit log text about the clock-related property changes.
> - Make sure dr_mode exist to apply the USB-gadget-only schema.
> ---
>  .../devicetree/bindings/usb/dwc3.txt  | 128 ---
>  .../devicetree/bindings/usb/snps,dwc3.yaml| 312 ++
>  2 files changed, 312 insertions(+), 128 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
>  create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/usb/snps,dwc3.yaml:55:4: [warning] wrong 
indentation: expected 4 but found 3 (indentation)

dtschema/dtc warnings/errors:
Unknown file referenced: [Errno 2] No such file or directory: 
'/usr/local/lib/python3.8/dist-packages/dtschema/schemas/usb/usb-drd.yaml'
xargs: dt-doc-validate: exited with status 255; aborting
make[1]: *** [Documentation/devicetree/bindings/Makefile:59: 
Documentation/devicetree/bindings/processed-schema-examples.json] Error 124
make: *** [Makefile:1364: dt_binding_check] Error 2


See https://patchwork.ozlabs.org/patch/1411582

The base for the patch is generally the last rc1. Any dependencies
should be noted.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v4 10/18] dt-bindings: usb: Convert DWC USB3 bindings to DT schema

2020-11-30 Thread Rob Herring
On Wed, Nov 25, 2020 at 1:32 AM Serge Semin
 wrote:
>
> On Sat, Nov 21, 2020 at 06:42:28AM -0600, Rob Herring wrote:
> > On Thu, Nov 12, 2020 at 01:29:46PM +0300, Serge Semin wrote:
> > > On Wed, Nov 11, 2020 at 02:14:23PM -0600, Rob Herring wrote:
> > > > On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote:
> > > > > DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> > > > > Controller schema, but with additional vendor-specific properties, the
> > > > > controller-specific reference clocks and PHYs. So let's convert the
> > > > > currently available legacy text-based DWC USB3 bindings to the DT 
> > > > > schema
> > > > > and make sure the DWC USB3 nodes are also validated against the
> > > > > usb-xhci.yaml schema.
> > > > >
> > > > > Note we have to discard the nodename restriction of being prefixed 
> > > > > with
> > > > > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB 
> > > > > nodes
> > > > > are supposed to be named as "^usb(@.*)".
> > > > >
> > > > > Signed-off-by: Serge Semin 
> > > > >
> > > > > ---
> > > > >
> > > > > Changelog v2:
> > > > > - Discard '|' from the descriptions, since we don't need to preserve
> > > > >   the text formatting in any of them.
> > > > > - Drop quotes from around the string constants.
> > > > > - Fix the "clock-names" prop description to be referring the 
> > > > > enumerated
> > > > >   clock-names instead of the ones from the Databook.
> > > > >
> > > > > Changelog v3:
> > > > > - Apply usb-xhci.yaml# schema only if the controller is supposed to 
> > > > > work
> > > > >   as either host or otg.
> > > > >
> > > > > Changelog v4:
> > > > > - Apply usb-drd.yaml schema first. If the controller is configured
> > > > >   to work in a gadget mode only, then apply the usb.yaml schema too,
> > > > >   otherwise apply the usb-xhci.yaml schema.
> > > > > - Discard the Rob'es Reviewed-by tag. Please review the patch one more
> > > > >   time.
> > > > > ---
> > > > >  .../devicetree/bindings/usb/dwc3.txt  | 125 
> > > > >  .../devicetree/bindings/usb/snps,dwc3.yaml| 303 
> > > > > ++
> > > > >  2 files changed, 303 insertions(+), 125 deletions(-)
> > > > >  delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
> > > > >  create mode 100644 
> > > > > Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> >
> >
> > > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml 
> > > > > b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > new file mode 100644
> > > > > index ..079617891da6
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > @@ -0,0 +1,303 @@
> > > > > +# SPDX-License-Identifier: GPL-2.0
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/usb/snps,dwc3.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Synopsys DesignWare USB3 Controller
> > > > > +
> > > > > +maintainers:
> > > > > +  - Felipe Balbi 
> > > > > +
> > > > > +description:
> > > > > +  This is usually a subnode to DWC3 glue to which it is connected, 
> > > > > but can also
> > > > > +  be presented as a standalone DT node with an optional 
> > > > > vendor-specific
> > > > > +  compatible string.
> > > > > +
> > >
> > > > > +allOf:
> > > > > +  - $ref: usb-drd.yaml#
> > > > > +  - if:
> > > > > +  properties:
> > > > > +dr_mode:
> > > > > +  const: peripheral
> >
>
> > Another thing, this evaluates to true if dr_mode is not present. You
> > need to add 'required'?
>
> Right. Will something like this do that?

Yes.

>
> + allOf:
> +  - $ref: usb-drd.yaml#
> +  - if:
> +  properties:
> +dr_mode:
> +  const: peripheral
> +
> +  required:
> +- dr_mode
> +then:
> +  $ref: usb.yaml#
> +else
> +  $ref: usb-xhci.yaml#
>
> > If dr_mode is otg, then don't you need to apply
> > both usb.yaml and usb-xhci.yaml?
>
> No I don't. Since there is no peripheral-specific DT schema, then the
> only schema any USB-gadget node needs to pass is usb.yaml, which
> is already included into the usb-xhci.yaml schema. So for pure OTG devices
> with xHCI host and gadget capabilities it's enough to evaluate: allOf:
> [$ref: usb-drd.yaml#, $ref: usb-xhci.yaml#].  Please see the
> sketch/ASCII-figure below and the following text for details.

Okay.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v4 10/18] dt-bindings: usb: Convert DWC USB3 bindings to DT schema

2020-11-21 Thread Rob Herring
On Thu, Nov 12, 2020 at 01:29:46PM +0300, Serge Semin wrote:
> On Wed, Nov 11, 2020 at 02:14:23PM -0600, Rob Herring wrote:
> > On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote:
> > > DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> > > Controller schema, but with additional vendor-specific properties, the
> > > controller-specific reference clocks and PHYs. So let's convert the
> > > currently available legacy text-based DWC USB3 bindings to the DT schema
> > > and make sure the DWC USB3 nodes are also validated against the
> > > usb-xhci.yaml schema.
> > > 
> > > Note we have to discard the nodename restriction of being prefixed with
> > > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
> > > are supposed to be named as "^usb(@.*)".
> > > 
> > > Signed-off-by: Serge Semin 
> > > 
> > > ---
> > > 
> > > Changelog v2:
> > > - Discard '|' from the descriptions, since we don't need to preserve
> > >   the text formatting in any of them.
> > > - Drop quotes from around the string constants.
> > > - Fix the "clock-names" prop description to be referring the enumerated
> > >   clock-names instead of the ones from the Databook.
> > > 
> > > Changelog v3:
> > > - Apply usb-xhci.yaml# schema only if the controller is supposed to work
> > >   as either host or otg.
> > > 
> > > Changelog v4:
> > > - Apply usb-drd.yaml schema first. If the controller is configured
> > >   to work in a gadget mode only, then apply the usb.yaml schema too,
> > >   otherwise apply the usb-xhci.yaml schema.
> > > - Discard the Rob'es Reviewed-by tag. Please review the patch one more
> > >   time.
> > > ---
> > >  .../devicetree/bindings/usb/dwc3.txt  | 125 
> > >  .../devicetree/bindings/usb/snps,dwc3.yaml| 303 ++
> > >  2 files changed, 303 insertions(+), 125 deletions(-)
> > >  delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
> > >  create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml


> > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml 
> > > b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > new file mode 100644
> > > index ..079617891da6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > @@ -0,0 +1,303 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/usb/snps,dwc3.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Synopsys DesignWare USB3 Controller
> > > +
> > > +maintainers:
> > > +  - Felipe Balbi 
> > > +
> > > +description:
> > > +  This is usually a subnode to DWC3 glue to which it is connected, but 
> > > can also
> > > +  be presented as a standalone DT node with an optional vendor-specific
> > > +  compatible string.
> > > +
> 
> > > +allOf:
> > > +  - $ref: usb-drd.yaml#
> > > +  - if:
> > > +  properties:
> > > +dr_mode:
> > > +  const: peripheral

Another thing, this evaluates to true if dr_mode is not present. You 
need to add 'required'? If dr_mode is otg, then don't you need to apply 
both usb.yaml and usb-xhci.yaml?

> > > +then:
> > > +  $ref: usb.yaml#
> > 
> > This part could be done in usb-drd.yaml?
> 
> Originally I was thinking about that, but then in order to minimize
> the properties validation I've decided to split the properties in
> accordance with the USB controllers functionality:
> 
> +- USB Gadget/Peripheral Controller. There is no
> |  specific schema for the gadgets since there is no
> |  common gadget properties (at least I failed to find
> |  ones). So the pure gadget controllers need to be
> |  validated just against usb.yaml schema.
> |
> usb.yaml <--+-- usb-hcd.yaml - Generic USB Host Controller. The schema
> ^  turns out to include the OHCI/UHCI/EHCI
> |  properties, which AFAICS are also
> |  applicable for the other host controllers.
> |  So any USB host controller node needs to
> |  be validated ag

Re: [PATCH v4 02/18] dt-bindings: usb: Convert generic USB properties to DT schemas

2020-11-21 Thread Rob Herring
On Wed, 11 Nov 2020 12:08:37 +0300, Serge Semin wrote:
> The generic USB properties have been described in the legacy bindings
> text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> convert its content into the generic USB, USB HCD and USB DRD DT
> schemas. So the Generic USB schema will be applicable to all USB
> controllers, USB HCD - for the generic USB Host controllers and the USB
> DRD - for the USB Dual-role controllers.
> 
> Note the USB DRD schema is supposed to work in conjunction with
> the USB peripheral/gadget and USB host controllers DT schemas.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Discard '|' in all the new properties, since we don't need to preserve
>   the text formatting.
> - Convert abbreviated form of the "maximum-speed" enum restriction into
>   the multi-lined version of the list.
> - Drop quotes from around the string constants.
> 
> Changelog v4:
> - Redistribute the properties between generic ones, USB HCD-specific and
>   USB DRD-specific.
> - Discard the Rob'es Reviewed-by tag. Please review the patch one more time.
> ---
>  .../devicetree/bindings/usb/generic.txt   | 57 --
>  .../devicetree/bindings/usb/usb-drd.yaml  | 77 +++
>  .../devicetree/bindings/usb/usb-hcd.yaml  |  5 ++
>  .../devicetree/bindings/usb/usb.yaml  | 22 ++
>  4 files changed, 104 insertions(+), 57 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
>  create mode 100644 Documentation/devicetree/bindings/usb/usb-drd.yaml
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v4 10/18] dt-bindings: usb: Convert DWC USB3 bindings to DT schema

2020-11-11 Thread Rob Herring
On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available legacy text-based DWC USB3 bindings to the DT schema
> and make sure the DWC USB3 nodes are also validated against the
> usb-xhci.yaml schema.
> 
> Note we have to discard the nodename restriction of being prefixed with
> "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
> are supposed to be named as "^usb(@.*)".
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Discard '|' from the descriptions, since we don't need to preserve
>   the text formatting in any of them.
> - Drop quotes from around the string constants.
> - Fix the "clock-names" prop description to be referring the enumerated
>   clock-names instead of the ones from the Databook.
> 
> Changelog v3:
> - Apply usb-xhci.yaml# schema only if the controller is supposed to work
>   as either host or otg.
> 
> Changelog v4:
> - Apply usb-drd.yaml schema first. If the controller is configured
>   to work in a gadget mode only, then apply the usb.yaml schema too,
>   otherwise apply the usb-xhci.yaml schema.
> - Discard the Rob'es Reviewed-by tag. Please review the patch one more
>   time.
> ---
>  .../devicetree/bindings/usb/dwc3.txt  | 125 
>  .../devicetree/bindings/usb/snps,dwc3.yaml| 303 ++
>  2 files changed, 303 insertions(+), 125 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
>  create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
> b/Documentation/devicetree/bindings/usb/dwc3.txt
> deleted file mode 100644
> index d03edf9d3935..
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ /dev/null
> @@ -1,125 +0,0 @@
> -synopsys DWC3 CORE
> -
> -DWC3- USB3 CONTROLLER. Complies to the generic USB binding properties
> -  as described in 'usb/generic.txt'
> -
> -Required properties:
> - - compatible: must be "snps,dwc3"
> - - reg : Address and length of the register set for the device
> - - interrupts: Interrupts used by the dwc3 controller.
> - - clock-names: list of clock names. Ideally should be "ref",
> -"bus_early", "suspend" but may be less or more.
> - - clocks: list of phandle and clock specifier pairs corresponding to
> -   entries in the clock-names property.
> -
> -Exception for clocks:
> -  clocks are optional if the parent node (i.e. glue-layer) is compatible to
> -  one of the following:
> -"cavium,octeon-7130-usb-uctl"
> -"qcom,dwc3"
> -"samsung,exynos5250-dwusb3"
> -"samsung,exynos5433-dwusb3"
> -"samsung,exynos7-dwusb3"
> -"sprd,sc9860-dwc3"
> -"st,stih407-dwc3"
> -"ti,am437x-dwc3"
> -"ti,dwc3"
> -"ti,keystone-dwc3"
> -"rockchip,rk3399-dwc3"
> -"xlnx,zynqmp-dwc3"
> -
> -Optional properties:
> - - usb-phy : array of phandle for the PHY device.  The first element
> -   in the array is expected to be a handle to the USB2/HS PHY and
> -   the second element is expected to be a handle to the USB3/SS PHY
> - - phys: from the *Generic PHY* bindings
> - - phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy"
> - or "usb3-phy".
> - - resets: set of phandle and reset specifier pairs
> - - snps,usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
> - - snps,usb3_lpm_capable: determines if platform is USB3 LPM capable
> - - snps,dis-start-transfer-quirk: when set, disable isoc START TRANSFER 
> command
> - failure SW work-around for DWC_usb31 version 1.70a-ea06
> - and prior.
> - - snps,disable_scramble_quirk: true when SW should disable data scrambling.
> - Only really useful for FPGA builds.
> - - snps,has-lpm-erratum: true when DWC3 was configured with LPM Erratum 
> enabled
> - - snps,lpm-nyet-threshold: LPM NYET threshold
> - - snps,u2exit_lfps_quirk: set if we want to enable u2exit lfps quirk
> - - snps,u2ss_inp3_quirk: set if we enable P3 OK for U2/SS Inactive quirk
> - - snps,req_p1p2p3_quirk: when set, the core will always request for
> - P1/P2/P3 transition sequence.
> - - snps,del_p1p2p3_quirk: when set core will delay P1/P2/P3 until a certain
> - amount of 8B10B errors occur.
> - - snps,del_phy_power_chg_quirk: when set core will delay PHY power change
> - from P0 to P1/P2/P3.
> - - snps,lfps_filter_quirk: when set core will filter LFPS reception.
> - - snps,rx_detect_poll_quirk: when set core will disable a 400us delay to 
> start
> - Polling LFPS after RX.Detect.
> - - snps,tx_de_emphasis_quirk: when set core will set Tx de-emphasis value.
> - - snps,tx_de_emphasis: the value driven to the PHY is 

Re: [PATCH v4 01/18] dt-bindings: usb: usb-hcd: Detach generic USB controller properties

2020-11-11 Thread Rob Herring
On Wed, 11 Nov 2020 12:08:36 +0300, Serge Semin wrote:
> There can be three distinctive types of the USB controllers: USB hosts,
> USB peripherals/gadgets and USB OTG, which can switch from one role to
> another. In order to have that hierarchy handled in the DT binding files,
> we need to collect common properties in a common DT schema and specific
> properties in dedicated schemas. Seeing the usb-hcd.yaml DT schema is
> dedicated for the USB host controllers only, let's move some common
> properties from there into the usb.yaml schema. So the later would be
> available to evaluate all currently supported types of the USB
> controllers.
> 
> While at it add an explicit "additionalProperties: true" into the
> usb-hcd.yaml as setting the additionalProperties/unevaluateProperties
> properties is going to be get mandatory soon.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v4:
> - This is a new patch created as a result of the comment left
>   by Chunfeng Yun in v3
> ---
>  .../devicetree/bindings/usb/usb-hcd.yaml  | 14 ++---
>  .../devicetree/bindings/usb/usb.yaml  | 29 +++
>  2 files changed, 32 insertions(+), 11 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/usb/usb-hcd.yaml:17:1: [error] duplication 
of key "additionalProperties" in mapping (key-duplicates)

dtschema/dtc warnings/errors:
Traceback (most recent call last):
  File "/usr/local/bin/dt-extract-example", line 45, in 
binding = yaml.load(open(args.yamlfile, encoding='utf-8').read())
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line 343, 
in load
return constructor.get_single_data()
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", 
line 113, in get_single_data
return self.construct_document(node)
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", 
line 123, in construct_document
for _dummy in generator:
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", 
line 723, in construct_yaml_map
value = self.construct_mapping(node)
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", 
line 440, in construct_mapping
return BaseConstructor.construct_mapping(self, node, deep=deep)
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", 
line 257, in construct_mapping
if self.check_mapping_key(node, key_node, mapping, key, value):
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", 
line 295, in check_mapping_key
raise DuplicateKeyError(*args)
ruamel.yaml.constructor.DuplicateKeyError: while constructing a mapping
  in "", line 4, column 1
found duplicate key "additionalProperties" with value "True" (original value: 
"True")
  in "", line 17, column 1

To suppress this check see:
http://yaml.readthedocs.io/en/latest/api.html#duplicate-keys

Duplicate keys will become an error in future releases, and are errors
by default when using the new API.

make[1]: *** [Documentation/devicetree/bindings/Makefile:20: 
Documentation/devicetree/bindings/usb/usb-hcd.example.dts] Error 1
make[1]: *** Deleting file 
'Documentation/devicetree/bindings/usb/usb-hcd.example.dts'
make[1]: *** Waiting for unfinished jobs
make[1]: *** [Documentation/devicetree/bindings/Makefile:59: 
Documentation/devicetree/bindings/processed-schema-examples.json] Error 123
make: *** [Makefile:1364: dt_binding_check] Error 2


See https://patchwork.ozlabs.org/patch/1398034

The base for the patch is generally the last rc1. Any dependencies
should be noted.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v3 09/16] dt-bindings: usb: Convert DWC USB3 bindings to DT schema

2020-10-20 Thread Rob Herring
On Tue, 20 Oct 2020 14:20:54 +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available legacy text-based DWC USB3 bindings to the DT schema
> and make sure the DWC USB3 nodes are also validated against the
> usb-xhci.yaml schema.
> 
> Note we have to discard the nodename restriction of being prefixed with
> "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
> are supposed to be named as "^usb(@.*)".
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Discard '|' from the descriptions, since we don't need to preserve
>   the text formatting in any of them.
> - Drop quotes from around the string constants.
> - Fix the "clock-names" prop description to be referring the enumerated
>   clock-names instead of the ones from the Databook.
> 
> Changelog v3:
> - Apply usb-xhci.yaml# schema only if the controller is supposed to work
>   as either host or otg.
> ---
>  .../devicetree/bindings/usb/dwc3.txt  | 125 
>  .../devicetree/bindings/usb/snps,dwc3.yaml| 302 ++
>  2 files changed, 302 insertions(+), 125 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
>  create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 15/20] dt-bindings: usb: meson-g12a-usb: Validate DWC2/DWC3 sub-nodes

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:57 +0300, Serge Semin wrote:
> Amlogic G12A USB DT sub-nodes are supposed to be compatible with the
> generic DWC USB2 and USB3 devices. Since now we've got DT schemas for
> both of the later IP cores let's make sure that the Amlogic G12A USB
> DT nodes are fully evaluated including the DWC sub-nodes.
> 
> Signed-off-by: Serge Semin 
> Reviewed-by: Neil Armstrong 
> 
> ---
> 
> Changelog v2:
> - Use "oneOf: [dwc2.yaml#, snps,dwc3.yaml#]" instead of the bulky "if:
>   properties: compatibe: ..." statement.
> ---
>  .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml  | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 17/20] dt-bindings: usb: qcom, dwc3: Validate DWC3 sub-node

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:59 +0300, Serge Semin wrote:
> Qualcomm msm8996/sc7180/sdm845 DWC3 compatible DT nodes are supposed to
> have a DWC USB3 compatible sub-node to describe a fully functioning USB
> interface. Let's use the available DWC USB3 DT schema to validate the
> Qualcomm DWC3 sub-nodes.
> 
> Note since the generic DWC USB3 DT node is supposed to be named as generic
> USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
> regexp and fix the DT node example.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Discard the "^dwc3@[0-9a-f]+$" nodes from being acceptable as sub-nodes.
> ---
>  Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 16/20] dt-bindings: usb: keystone-dwc3: Validate DWC3 sub-node

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:58 +0300, Serge Semin wrote:
> TI Keystone DWC3 compatible DT node is supposed to have a DWC USB3
> compatible sub-node to describe a fully functioning USB interface.
> Since DWC USB3 has now got a DT schema describing its DT node, let's make
> sure the TI Keystone DWC3 sub-node passes validation against it.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Grammar fix: "s/it'/its"
> ---
>  Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 14/20] dt-bindings: usb: meson-g12a-usb: Fix FL-adj property value

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:56 +0300, Serge Semin wrote:
> An empty snps,quirk-frame-length-adjustment won't cause any change
> performed by the driver. Moreover the DT schema validation will fail,
> since it expects the property being assigned with some value. So set
> fix the example by setting a valid FL-adj value in accordance with
> Neil Armstrong comment.
> 
> Link: 
> https://lore.kernel.org/linux-usb/20201010224121.12672-16-sergey.se...@baikalelectronics.ru/
> Signed-off-by: Serge Semin 
> Acked-by: Neil Armstrong 
> 
> ---
> 
> Note the same problem is in the DT source file
> arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi .
> ---
>  .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml| 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 13/20] dt-bindings: usb: dwc3: Add Frame Length Adj restrictions

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:55 +0300, Serge Semin wrote:
> In accordance with the IP core databook the
> snps,quirk-frame-length-adjustment property can be set within [0, 0x3F].
> Let's make sure the DT schema applies a correct restriction on the
> property.
> 
> Signed-off-by: Serge Semin 
> ---
>  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 12/20] dt-bindings: usb: dwc3: Add Tx De-emphasis restrictions

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:54 +0300, Serge Semin wrote:
> In accordance with the driver comments the PIPE3 de-emphasis can be tuned
> to be either -6dB, -2.5dB or disabled. Let's add the de-emphasis
> property restriction so the DT schema would make sure the controller DT
> node is equipped with correct value.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Grammar fix: "s/tunned/tuned"
> - Grammar fix: remove redundant "or" conjunction.
> ---
>  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 4 
>  1 file changed, 4 insertions(+)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 11/20] dt-bindings: usb: dwc3: Add synopsys,dwc3 compatible string

2020-10-16 Thread Rob Herring
On Thu, Oct 15, 2020 at 12:35:54AM +0300, Serge Semin wrote:
> On Wed, Oct 14, 2020 at 10:18:18PM +0200, Krzysztof Kozlowski wrote:
> > On Wed, Oct 14, 2020 at 01:13:53PM +0300, Serge Semin wrote:
> > > The DWC USB3 driver and some DTS files like Exynos 5250, Keystone k2e, etc
> > > expects the DWC USB3 DT node to have the compatible string with the
> > > "synopsys" vendor prefix. Let's add the corresponding compatible string to
> > > the controller DT schema, but mark it as deprecated seeing the Synopsys,
> > > Inc. is presented with just "snps" vendor prefix.
> > 
> 
> > Instead of adding deprecated schema just correct the DTSes to use snps.
> > The "synopsys" is not even in vendor prefixes.
> 
> Yeah, it's not, but the driver and some dts'es use it this way. I am not sure
> that the solution suggested by you is much better than mine. So let's hear the
> Rob'es opinion out in this matter. @Rob, what do you think?

I think we should fix the dts files given there's only 5.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 10/20] dt-bindings: usb: dwc3: Add interrupt-names property support

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:52 +0300, Serge Semin wrote:
> The controller driver supports two types of DWC USB3 devices: with a
> common interrupt lane and with individual interrupts for each mode. Add
> support for both these cases to the DWC USB3 DT schema.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Grammar fix: "s/both of these cases support/support for both these cases"
> - Drop quotes from around the string constants.
> ---
>  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 11 +++
>  1 file changed, 11 insertions(+)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 08/20] dt-bindings: usb: renesas-xhci: Refer to the usb-xhci.yaml file

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:50 +0300, Serge Semin wrote:
> With minor peculiarities (like uploading some vendor-specific firmware)
> these are just Generic xHCI controllers fully compatible with its
> properties. Make sure the Renesas USB xHCI DT nodes are also validated
> against the Generic xHCI DT schema.
> 
> Signed-off-by: Serge Semin 
> ---
>  Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 06/20] dt-bindings: usb: Convert xHCI bindings to DT schema

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:48 +0300, Serge Semin wrote:
> Currently the DT bindings of Generic xHCI Controllers are described by means
> of the legacy text file. Since such format is deprecated in favor of the
> DT schema, let's convert the Generic xHCI Controllers bindings file to the
> corresponding yaml files. There will be two of them: a DT schema for the
> xHCI controllers on a generic platform and a DT schema validating a generic
> xHCI controllers properties. The later will be used to validate the xHCI
> controllers, which aside from some vendor-specific features support the
> basic xHCI functionality.
> 
> An xHCI-compatible DT node shall support the standard USB HCD properties
> and custom ones like: usb2-lpm-disable, usb3-lpm-capable,
> quirk-broken-port-ped and imod-interval-ns. In addition if a generic xHCI
> controller is being validated against the DT schema it is also supposed to
> be equipped with mandatory compatible string, single registers range,
> single interrupts source, and is supposed to optionally contain up to two
> reference clocks for the controller core and CSRs.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Add explicit "additionalProperties: true" to the usb-xhci.yaml schema,
>   since additionalProperties/unevaluatedProperties are going to be mandary
>   for each binding.
> ---
>  .../devicetree/bindings/usb/generic-xhci.yaml | 63 +++
>  .../devicetree/bindings/usb/usb-xhci.txt  | 41 
>  .../devicetree/bindings/usb/usb-xhci.yaml | 42 +
>  3 files changed, 105 insertions(+), 41 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/generic-xhci.yaml
>  delete mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.txt
>  create mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.yaml
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 07/20] dt-bindings: usb: xhci: Add Broadcom STB v2 compatible device

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:49 +0300, Serge Semin wrote:
> For some reason the "brcm,xhci-brcm-v2" compatible string has been missing
> in the original bindings file. Add it to the Generic xHCI Controllers DT
> schema since the controller driver expects it to be supported.
> 
> Signed-off-by: Serge Semin 
> ---
>  Documentation/devicetree/bindings/usb/generic-xhci.yaml | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 04/20] dt-bindings: usb: usb-hcd: Add "tpl-support" property

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:46 +0300, Serge Semin wrote:
> The host controller device might be designed to work for the particular
> products or applications. In that case its DT node is supposed to be
> equipped with the tpl-support property.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Grammar fix: "s/it'/its"
> - Discard '|' from the property description, since we don't need to preserve
>   the text formatting.
> ---
>  Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++
>  1 file changed, 6 insertions(+)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 05/20] dt-bindings: usb: usb-hcd: Add generic "usb-phy" property

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:47 +0300, Serge Semin wrote:
> Even though the Generic PHY framework is the more preferable way of
> setting the USB PHY up, there are still many dts-files and DT bindings
> which rely on having the legacy "usb-phy" specified to attach particular
> USB PHYs to USB cores. Let's have the "usb-phy" property described in
> the generic USB HCD binding file so it would be validated against the
> nodes in which it's specified. Mark the property as deprecated to
> discourage the developers from using it.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Discard '|' from the property description, since we don't need to preserve
>   the text formatting.
> ---
>  Documentation/devicetree/bindings/usb/usb-hcd.yaml | 7 +++
>  1 file changed, 7 insertions(+)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 03/20] dt-bindings: usb: usb-hcd: Add "ulpi/serial/hsic" PHY types

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:45 +0300, Serge Semin wrote:
> Aside from the UTMI+ there are also ULPI, Serial and HSIC PHY types
> that can be specified in the phy_type HCD property. Add them to the
> enumeration of the acceptable values.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Grammar fix: "s/PHY types can be/PHY types that can be"
> - Drop quotes from around the string constants.
> ---
>  Documentation/devicetree/bindings/usb/usb-hcd.yaml | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 02/20] dt-bindings: usb: usb-hcd: Add "otg-rev" property restriction

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:44 +0300, Serge Semin wrote:
> There are only four OTG revisions are currently supported by the kernel:
> 0x0100, 0x0120, 0x0130, 0x0200. Any another value is considered as
> invalid.
> 
> Signed-off-by: Serge Semin 
> ---
>  Documentation/devicetree/bindings/usb/usb-hcd.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 01/20] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema

2020-10-16 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:43 +0300, Serge Semin wrote:
> The generic USB HCD properties have been described in the legacy bindings
> text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> convert it' content into the USB HCD DT schema properties so all USB DT
> nodes would be validated to have them properly utilized.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Discard '|' in all the new properties, since we don't need to preserve
>   the text formatting.
> - Convert abbreviated form of the "maximum-speed" enum restriction into
>   the multi-lined version of the list.
> - Drop quotes from around the string constants.
> ---
>  .../devicetree/bindings/usb/generic.txt   | 57 
>  .../devicetree/bindings/usb/usb-hcd.yaml  | 88 +++
>  2 files changed, 88 insertions(+), 57 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 04/20] dt-bindings: usb: usb-hcd: Add "tpl-support" property

2020-10-16 Thread Rob Herring
On Wed, Oct 14, 2020 at 08:27:10PM +0300, Serge Semin wrote:
> On Wed, Oct 14, 2020 at 08:27:56AM -0500, Rob Herring wrote:
> > On Wed, 14 Oct 2020 13:13:46 +0300, Serge Semin wrote:
> > > The host controller device might be designed to work for the particular
> > > products or applications. In that case its DT node is supposed to be
> > > equipped with the tpl-support property.
> > > 
> > > Signed-off-by: Serge Semin 
> > > 
> > > ---
> > > 
> > > Changelog v2:
> > > - Grammar fix: "s/it'/its"
> > > - Discard '|' from the property description, since we don't need to 
> > > preserve
> > >   the text formatting.
> > > ---
> > >  Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > 
> > 
> > My bot found errors running 'make dt_binding_check' on your patch:
> > 
> > Traceback (most recent call last):
> >   File "/usr/local/bin/dt-extract-example", line 45, in 
> > binding = yaml.load(open(args.yamlfile, encoding='utf-8').read())
> >   File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line 
> > 343, in load
> > return constructor.get_single_data()
> >   File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", 
> > line 111, in get_single_data
> > node = self.composer.get_single_node()
> >   File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node
> >   File "_ruamel_yaml.pyx", line 724, in 
> > _ruamel_yaml.CParser._compose_document
> >   File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node
> >   File "_ruamel_yaml.pyx", line 891, in 
> > _ruamel_yaml.CParser._compose_mapping_node
> >   File "_ruamel_yaml.pyx", line 904, in 
> > _ruamel_yaml.CParser._parse_next_event
> > ruamel.yaml.scanner.ScannerError: mapping values are not allowed in this 
> > context
> >   in "", line 27, column 14
> > make[1]: *** [Documentation/devicetree/bindings/Makefile:20: 
> > Documentation/devicetree/bindings/usb/usb-hcd.example.dts] Error 1
> > make[1]: *** Deleting file 
> > 'Documentation/devicetree/bindings/usb/usb-hcd.example.dts'
> > make[1]: *** Waiting for unfinished jobs
> > ./Documentation/devicetree/bindings/usb/usb-hcd.yaml:27:14: [error] syntax 
> > error: mapping values are not allowed here (syntax)
> > make[1]: *** [Documentation/devicetree/bindings/Makefile:59: 
> > Documentation/devicetree/bindings/processed-schema-examples.json] Error 123
> > make: *** [Makefile:1366: dt_binding_check] Error 2
> > 
> > 
> > See https://patchwork.ozlabs.org/patch/1382001
> > 
> > If you already ran 'make dt_binding_check' and didn't see the above
> > error(s), then make sure dt-schema is up to date:
> > 
> > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
> > --upgrade
> > 
> > Please check and re-submit.
> 
> Hm, that's weird. Of course I did the dt_binding_check before submission, but
> even after the dt-schema repo update I failed to see the error:
> 
> $ make -j8 ARCH=mips CROSS_COMPILE=mipsel-baikal-linux- dt_binding_check 
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/usb/usb-hcd.yaml
>   CHKDT   Documentation/devicetree/bindings/usb/usb-hcd.yaml
>   SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.yaml
>   DTC Documentation/devicetree/bindings/usb/usb-hcd.example.dt.yaml
>   CHECK   Documentation/devicetree/bindings/usb/usb-hcd.example.dt.yaml
> 
> Rob, any idea why has the bot got mad at me?

Humm, I'm not sure. We'll see if it happens again when you send v2.

Note that yamllint is also run now and that's the line with '[error]'. 
So neither yamllint nor ruamel are happy (could be the same parser code 
ultimately).

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 20/20] arch: dts: Fix DWC USB3 DT nodes name

2020-10-14 Thread Rob Herring
On Wed, Oct 14, 2020 at 9:37 AM Serge Semin
 wrote:
>
> On Wed, Oct 14, 2020 at 05:09:37PM +0300, Felipe Balbi wrote:
> >
> > Hi Serge,
> >
> > Serge Semin  writes:
> > > In accordance with the DWC USB3 bindings the corresponding node name is
> > > suppose to comply with Generic USB HCD DT schema, which requires the USB
> >
>
> > DWC3 is not a simple HDC, though.
>
> Yeah, strictly speaking it is equipped with a lot of vendor-specific stuff,
> which are tuned by the DWC USB3 driver in the kernel. But after that the
> controller is registered as xhci-hcd device so it's serviced by the xHCI 
> driver,
> which then registers the HCD device so the corresponding DT node is supposed
> to be compatible with the next bindings: usb/usb-hcd.yaml, usb/usb-xhci.yaml
> and usb/snps,dwc3,yaml. I've created the later one so to validate the denoted
> compatibility.
>
> >
> > > nodes to have the name acceptable by the regexp: "^usb(@.*)?" . But a lot
> > > of the DWC USB3-compatible nodes defined in the ARM/ARM64 DTS files have
> > > name as "^dwc3@.*" or "^usb[1-3]@.*" or even "^dwusb@.*", which will cause
> > > the dtbs_check procedure failure. Let's fix the nodes naming to be
> > > compatible with the DWC USB3 DT schema to make dtbs_check happy.
> > >
> > > Note we don't change the DWC USB3-compatible nodes names of
> > > arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} since the
> > > in-source comment says that the nodes name need to be preserved as
> > > "^dwusb@.*" for some backward compatibility.
> >
>
> > interesting, compatibility with what? Some debugfs files, perhaps? :-)
>
> Don't really know.) In my experience the worst type of such compatibility is
> connected with some bootloader magic, which may add/remove/modify properties
> to nodes with pre-defined names.

I seriously doubt anyone is using the APM machines with DT (even ACPI
is somewhat doubtful). I say change them. Or remove the dts files and
see what happens. Either way it can always be reverted.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 09/20] dt-bindings: usb: Convert DWC USB3 bindings to DT schema

2020-10-14 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:51 +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available legacy text-based DWC USB3 bindings to the DT schema
> and make sure the DWC USB3 nodes are also validated against the
> usb-xhci.yaml schema.
> 
> Note we have to discard the nodename restriction of being prefixed with
> "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
> are supposed to be named as "^usb(@.*)".
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Discard '|' from the descriptions, since we don't need to preserve
>   the text formatting in any of them.
> - Drop quotes from around the string constants.
> - Fix the "clock-names" prop description to be referring the enumerated
>   clock-names instead of the ones from the Databook.
> ---
>  .../devicetree/bindings/usb/dwc3.txt  | 125 
>  .../devicetree/bindings/usb/snps,dwc3.yaml| 295 ++
>  2 files changed, 295 insertions(+), 125 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
>  create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

./Documentation/devicetree/bindings/usb/snps,dwc3.yaml:44:4: [warning] wrong 
indentation: expected 4 but found 3 (indentation)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/qcom,dwc3.example.dt.yaml:
 dwc3@a60: $nodename:0: 'dwc3@a60' does not match '^usb(@.*)?'
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.example.dt.yaml:
 usb@ff50: snps,quirk-frame-length-adjustment: True is not of type 'array'
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/snps,dwc3.yaml


See https://patchwork.ozlabs.org/patch/1382003

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 04/20] dt-bindings: usb: usb-hcd: Add "tpl-support" property

2020-10-14 Thread Rob Herring
On Wed, 14 Oct 2020 13:13:46 +0300, Serge Semin wrote:
> The host controller device might be designed to work for the particular
> products or applications. In that case its DT node is supposed to be
> equipped with the tpl-support property.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Changelog v2:
> - Grammar fix: "s/it'/its"
> - Discard '|' from the property description, since we don't need to preserve
>   the text formatting.
> ---
>  Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++
>  1 file changed, 6 insertions(+)
> 


My bot found errors running 'make dt_binding_check' on your patch:

Traceback (most recent call last):
  File "/usr/local/bin/dt-extract-example", line 45, in 
binding = yaml.load(open(args.yamlfile, encoding='utf-8').read())
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line 343, 
in load
return constructor.get_single_data()
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", 
line 111, in get_single_data
node = self.composer.get_single_node()
  File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node
  File "_ruamel_yaml.pyx", line 724, in _ruamel_yaml.CParser._compose_document
  File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 891, in 
_ruamel_yaml.CParser._compose_mapping_node
  File "_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event
ruamel.yaml.scanner.ScannerError: mapping values are not allowed in this context
  in "", line 27, column 14
make[1]: *** [Documentation/devicetree/bindings/Makefile:20: 
Documentation/devicetree/bindings/usb/usb-hcd.example.dts] Error 1
make[1]: *** Deleting file 
'Documentation/devicetree/bindings/usb/usb-hcd.example.dts'
make[1]: *** Waiting for unfinished jobs
./Documentation/devicetree/bindings/usb/usb-hcd.yaml:27:14: [error] syntax 
error: mapping values are not allowed here (syntax)
make[1]: *** [Documentation/devicetree/bindings/Makefile:59: 
Documentation/devicetree/bindings/processed-schema-examples.json] Error 123
make: *** [Makefile:1366: dt_binding_check] Error 2


See https://patchwork.ozlabs.org/patch/1382001

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v6 5/6] dt-bindings: dw-apb-ictl: convert to json-schema

2020-09-28 Thread Rob Herring
On Thu, Sep 24, 2020 at 03:17:53PM +0800, Zhen Lei wrote:
> Convert the Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> binding to DT schema format using json-schema.
> 
> Signed-off-by: Zhen Lei 
> ---
>  .../interrupt-controller/snps,dw-apb-ictl.txt  | 43 -
>  .../interrupt-controller/snps,dw-apb-ictl.yaml | 74 
> ++
>  2 files changed, 74 insertions(+), 43 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
>  create mode 100644 
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt 
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> deleted file mode 100644
> index 2db59df9408f4c6..000
> --- 
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> -
> -Synopsys DesignWare provides interrupt controller IP for APB known as
> -dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs 
> with
> -APB bus, e.g. Marvell Armada 1500. It can also be used as primary interrupt
> -controller in some SoCs, e.g. Hisilicon SD5203.
> -
> -Required properties:
> -- compatible: shall be "snps,dw-apb-ictl"
> -- reg: physical base address of the controller and length of memory mapped
> -  region starting with ENABLE_LOW register
> -- interrupt-controller: identifies the node as an interrupt controller
> -- #interrupt-cells: number of cells to encode an interrupt-specifier, shall 
> be 1
> -
> -Additional required property when it's used as secondary interrupt 
> controller:
> -- interrupts: interrupt reference to primary interrupt controller
> -
> -The interrupt sources map to the corresponding bits in the interrupt
> -registers, i.e.
> -- 0 maps to bit 0 of low interrupts,
> -- 1 maps to bit 1 of low interrupts,
> -- 32 maps to bit 0 of high interrupts,
> -- 33 maps to bit 1 of high interrupts,
> -- (optional) fast interrupts start at 64.
> -
> -Example:
> - /* dw_apb_ictl is used as secondary interrupt controller */
> - aic: interrupt-controller@3000 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x3000 0xc00>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - interrupt-parent = <>;
> - interrupts = ;
> - };
> -
> - /* dw_apb_ictl is used as primary interrupt controller */
> - vic: interrupt-controller@1013 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x1013 0x1000>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - };
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
>  
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> new file mode 100644
> index 000..1b05d36b5f7b943
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/interrupt-controller/snps,dw-apb-ictl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> +
> +maintainers:
> +  - Sebastian Hesselbarth 
> +
> +description: |
> +  Synopsys DesignWare provides interrupt controller IP for APB known as
> +  dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
> +  with APB bus, e.g. Marvell Armada 1500. It can also be used as primary
> +  interrupt controller in some SoCs, e.g. Hisilicon SD5203.
> +
> +  The interrupt sources map to the corresponding bits in the interrupt
> +  registers, i.e.
> +  - 0 maps to bit 0 of low interrupts,
> +  - 1 maps to bit 1 of low interrupts,
> +  - 32 maps to bit 0 of high interrupts,
> +  - 33 maps to bit 1 of high interrupts,
> +  - (optional) fast interrupts start at 64.
> +
> +allOf:
> +  - $ref: /schemas/interrupt-controller.yaml#

Don't need this. It's already selected based on node name.

> +
> +properties:
> +  compatible:
> +const: snps,dw-apb-ictl
> +
> +  interrupt-controller: true
> +
> +  reg:
> +description: |
> +  Physical base address of the controller and length of memory mapped
> +  region starting with ENABLE_LOW register.
> +maxItems: 1
> +
> +  interrupts:
> +description: Interrupt reference to primary interrupt controller.

May not be primary. Could be another level in the middle. In any case, 
it's outside the scope of this binding, so just drop description.

> +maxItems: 1
> +
> +  "#interrupt-cells":
> +description: Number of cells to encode an interrupt-specifier.

Can drop this.

> +const: 1
> +
> 

Re: [PATCH v5 4/6] dt-bindings: dw-apb-ictl: support hierarchy irq domain

2020-09-23 Thread Rob Herring
On Fri, 18 Sep 2020 19:22:00 +0800, Zhen Lei wrote:
> Add support to use dw-apb-ictl as primary interrupt controller.
> 
> Signed-off-by: Zhen Lei 
> ---
>  .../bindings/interrupt-controller/snps,dw-apb-ictl.txt | 14 
> +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v5 5/6] dt-bindings: dw-apb-ictl: convert to json-schema

2020-09-23 Thread Rob Herring
On Fri, Sep 18, 2020 at 07:22:01PM +0800, Zhen Lei wrote:
> Convert the Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> binding to DT schema format using json-schema.
> 
> Signed-off-by: Zhen Lei 
> ---
>  .../interrupt-controller/snps,dw-apb-ictl.txt  | 43 -
>  .../interrupt-controller/snps,dw-apb-ictl.yaml | 75 
> ++
>  2 files changed, 75 insertions(+), 43 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
>  create mode 100644 
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt 
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> deleted file mode 100644
> index 2db59df9408f4c6..000
> --- 
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> -
> -Synopsys DesignWare provides interrupt controller IP for APB known as
> -dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs 
> with
> -APB bus, e.g. Marvell Armada 1500. It can also be used as primary interrupt
> -controller in some SoCs, e.g. Hisilicon SD5203.
> -
> -Required properties:
> -- compatible: shall be "snps,dw-apb-ictl"
> -- reg: physical base address of the controller and length of memory mapped
> -  region starting with ENABLE_LOW register
> -- interrupt-controller: identifies the node as an interrupt controller
> -- #interrupt-cells: number of cells to encode an interrupt-specifier, shall 
> be 1
> -
> -Additional required property when it's used as secondary interrupt 
> controller:
> -- interrupts: interrupt reference to primary interrupt controller
> -
> -The interrupt sources map to the corresponding bits in the interrupt
> -registers, i.e.
> -- 0 maps to bit 0 of low interrupts,
> -- 1 maps to bit 1 of low interrupts,
> -- 32 maps to bit 0 of high interrupts,
> -- 33 maps to bit 1 of high interrupts,
> -- (optional) fast interrupts start at 64.
> -
> -Example:
> - /* dw_apb_ictl is used as secondary interrupt controller */
> - aic: interrupt-controller@3000 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x3000 0xc00>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - interrupt-parent = <>;
> - interrupts = ;
> - };
> -
> - /* dw_apb_ictl is used as primary interrupt controller */
> - vic: interrupt-controller@1013 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x1013 0x1000>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - };
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
>  
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> new file mode 100644
> index 000..70c12979c843bf0
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> @@ -0,0 +1,75 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/interrupt-controller/snps,dw-apb-ictl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> +
> +maintainers:
> +  - Marc Zyngier 

Usually this would be an owner for this IP block, not the subsystem 
maintainer.

> +
> +description:
> +  Synopsys DesignWare provides interrupt controller IP for APB known as
> +  dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
> +  with APB bus, e.g. Marvell Armada 1500. It can also be used as primary
> +  interrupt controller in some SoCs, e.g. Hisilicon SD5203.
> +
> +allOf:
> +  - $ref: /schemas/interrupt-controller.yaml#

You can drop this, it's already applied based on node name.

> +
> +properties:
> +  compatible:
> +const: snps,dw-apb-ictl
> +
> +  interrupt-controller: true
> +
> +  reg:
> +description:
> +  Physical base address of the controller and length of memory mapped
> +  region starting with ENABLE_LOW register.

Need to define how many reg regions (maxItems: 1).

> +
> +  interrupts:
> +description:
> +  Interrupt reference to primary interrupt controller.
> +
> +  The interrupt sources map to the corresponding bits in the interrupt
> +  registers, i.e.
> +  - 0 maps to bit 0 of low interrupts,
> +  - 1 maps to bit 1 of low interrupts,
> +  - 32 maps to bit 0 of high interrupts,
> +  - 33 maps to bit 1 of high interrupts,
> +  - (optional) fast interrupts start at 64.
> +minItems: 1
> +maxItems: 65

65 connections to the primary interrupt controller? I think this is for 
the child interrupts? If so, move to 

Re: [PATCH v2 3/4] ARC: [plat-hsdk-4xd] initial port for HSDK-4xD board

2020-06-04 Thread Rob Herring
On Thu, Jun 4, 2020 at 11:39 AM Eugeniy Paltsev
 wrote:
>

Need to cc the DT list.

> This initial port adds support of ARC HS4x/HS4xD Development Kit board
> with some basic features such serial port, USB, SD/MMC, SPI flash,
> Ethernet and others.
>
> The HSDK-4xD board has much in common with its predecessor - HSDK board.
> However HSDK-4xD has some differences in comparison with its predecessor:
>  * based on quad core ARC HS48/HS47D processor (instead of quad core
>ARC HS38)
>  * has ThinkSilicon GPU (instead of Vivante GPU)
>  * has ARC PGU and HDMI output
>  * has separate SDIO controller for WiFi module
>  * has additional timers with clocksource independent from CPU clocksource
>(required for DVFS)
>  * has performance counters interrupt
>  * other minor stuff
>
> NOTE:
> HSDK-4xD and HSDK may share part of DTS so we can move this common part
> to one .dtsi file (as we have done it in U-boot). However we have quite
> enough out of the tree patches for tweaking HSDK DTS (patches in out
> Linux kernel verification flow, patches for run in simulation, etc...),
> so I'd prefer to keep HSDK DTS untouched. That's why HSDK-4xD DTS is
> created as an separate file.
>
> Cc: Rob Herring 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  arch/arc/boot/dts/hsdk-4xd.dts  | 322 

Please check this using W=1 and also build 'dtbs_check' (which needs
dt-schema installed).

>  arch/arc/configs/hsdk_4xd_defconfig |  98 +
>  arch/arc/kernel/devtree.c   |   1 +
>  arch/arc/plat-hsdk/Kconfig  |   3 +-
>  arch/arc/plat-hsdk/platform.c   |   1 +
>  5 files changed, 424 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arc/boot/dts/hsdk-4xd.dts
>  create mode 100644 arch/arc/configs/hsdk_4xd_defconfig
>
> diff --git a/arch/arc/boot/dts/hsdk-4xd.dts b/arch/arc/boot/dts/hsdk-4xd.dts
> new file mode 100644
> index ..2b7f76a01e3e
> --- /dev/null
> +++ b/arch/arc/boot/dts/hsdk-4xd.dts
> @@ -0,0 +1,322 @@
> +// SPDX-License-Identifier: GPL-2.0-only

Don't care about non-GPL OS's?

> +/*
> + * Copyright (C) 2020 Synopsys, Inc. (www.synopsys.com)
> + */
> +
> +/*
> + * Device Tree for ARC HS4x/HS4xD Development Kit
> + */
> +/dts-v1/;
> +
> +#include 
> +#include 
> +
> +/ {
> +   model = "snps,hsdk-4xd";
> +   compatible = "snps,hsdk-4xd";
> +
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +
> +   chosen {
> +   bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8 
> console=ttyS0,115200n8 debug print-fatal-signals=1";

You shouldn't really put debug options here like 'earlycon'. Also, use
'stdout-path' instead for the console.

> +   };
> +
> +   aliases {
> +   ethernet = 
> +   };
> +
> +   cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   cpu@0 {
> +   device_type = "cpu";
> +   compatible = "snps,archs48";

Not documented.

> +   reg = <0>;
> +   clocks = <_clk>;
> +   };
> +
> +   cpu@1 {
> +   device_type = "cpu";
> +   compatible = "snps,archs48";
> +   reg = <1>;
> +   clocks = <_clk>;
> +   };
> +
> +   cpu@2 {
> +   device_type = "cpu";
> +   compatible = "snps,archs48";
> +   reg = <2>;
> +   clocks = <_clk>;
> +   };
> +
> +   cpu@3 {
> +   device_type = "cpu";
> +   compatible = "snps,archs48";
> +   reg = <3>;
> +   clocks = <_clk>;
> +   };
> +   };
> +
> +   input_clk: input-clk {
> +   #clock-cells = <0>;
> +   compatible = "fixed-clock";
> +   clock-frequency = <>;
> +   };
> +
> +   reg_5v0: regulator-5v0 {
> +   compatible = "regulator-fixed";
> +
> +   regulator-name = "5v0-supply";
> +   regulator-min-microvolt = <500>;
> +   regulator-max-microvolt = <500>;
> +   };
> +
> +   cpu_intc: cpu-interrupt-controller {
> +   compatible = "snps,archs-intc";
> +   inter

Re: [PATCH v3 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings

2020-04-20 Thread Rob Herring
On Wed, Apr 15, 2020 at 02:29:29AM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.

You're going to need to base this on top of Laurent's conversion of 
dw_hdmi.txt to schema.

> 
> Acked-by: Sam Ravnborg 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  .../display/bridge/snps,arc-dw-hdmi.yaml  | 136 ++
>  1 file changed, 136 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> new file mode 100644
> index ..9b2fdfecd5b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: GPL-2.0

Dual license new bindings please:

(GPL-2.0-only OR BSD-2-Clause)

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/snps,arc-dw-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare HDMI 2.0 TX encoder driver

Bindings are for h/w blocks, not drivers.

> +
> +maintainers:
> +  - Eugeniy Paltsev 
> +
> +description: |
> +  The HDMI transmitter is a Synopsys DesignWare HDMI 2.0 TX controller IP
> +  with a companion of Synopsys DesignWare HDMI 2.0 TX PHY IP.

Sounds like 2 blocks?

> +
> +  These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> +  Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
> +  with the following device-specific properties.
> +
> +properties:
> +  compatible:
> +const: snps,arc-dw-hdmi-hsdk
> +
> +  reg:
> +maxItems: 1
> +description: |
> +  Memory mapped base address and length of the DWC HDMI TX registers.

Can drop.

> +
> +  clocks:
> +items:
> +  - description: The bus clock for AHB / APB
> +  - description: The internal register configuration clock
> +
> +  clock-names:
> +items:
> +  - const: iahb
> +  - const: isfr
> +
> +  interrupts:
> +maxItems: 1
> +description: Reference to the DWC HDMI TX interrupt

Can drop.

> +
> +  reg-io-width:
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32
> +  - enum: [1, 4]
> +description: |
> +  Width of the registers specified by the reg property. The
> +  value is expressed in bytes and must be equal to 1 or 4 if 
> specified.
> +  The register width defaults to 1 if the property is not present.

default: 1

The description is pretty much a plain text version of the constraints, 
so all but the first sentence can be dropped.

> +
> +  ports:
> +type: object
> +description: |
> +  A ports node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt

Can drop. That's all 'ports'.

> +
> +properties:
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 0
> +
> +  port@0:
> +type: object
> +description: |
> +  Video input endpoints of the controller.
> +  Usually it is associated with ARC PGU.
> +
> +  port@1:
> +type: object
> +description: |
> +  Output endpoints of the controller. HDMI connector.
> +
> +required:
> +  - "#address-cells"
> +  - "#size-cells"
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - interrupts
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +hdmi@1 {
> +compatible = "snps,arc-dw-hdmi-hsdk";
> +reg = <0x1 0x1>;
> +reg-io-width = <4>;
> +interrupts = <14>;
> +clocks = <>, <_pix_clk>;
> +clock-names = "iahb", "isfr";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +hdmi_enc_input: endpoint {
> +remote-endpoint = <_output>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +hdmi_enc_out: endpoint {
> +remote-endpoint = <_con>;
> +};
> +};
> +};
> +};
> +
> +hdmi-out {
> +port {
> +hdmi_con: endpoint {
> +remote-endpoint = <_enc_out>;
> +};
> +};
> +};
> +
> +pgu {
> +port_o: port {
> +pgu_output: endpoint {
> +remote-endpoint = <_enc_input>;
> +};
> +};
> +};
> -- 
> 2.21.1
> 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings

2020-04-14 Thread Rob Herring
On Tue, 14 Apr 2020 17:44:02 +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  .../display/bridge/snps,arc-dw-hdmi.yaml  | 131 ++
>  1 file changed, 131 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.example.dt.yaml:
 example-0: 'hdmi@0x1' does not match any of the regexes: '.*-names$', 
'.*-supply$', '^#.*-cells$', '^#[a-zA-Z0-9,+\\-._]{0,63}$', 
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}$', 
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+(,[0-9a-fA-F]+)*$', '^__.*__$', 
'pinctrl-[0-9]+'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.example.dt.yaml:
 hdmi@0x1: 'interrupts' does not match any of the regexes: 'pinctrl-[0-9]+'

See https://patchwork.ozlabs.org/patch/1270389

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 4/7] dt-bindings: chosen: Add clocksource and clockevent selection

2019-09-30 Thread Rob Herring
On Wed, Sep 11, 2019 at 07:18:07AM +, claudiu.bez...@microchip.com wrote:
> 
> 
> On 11.09.2019 03:03, Linus Walleij wrote:
> > External E-Mail
> > 
> > 
> > On Tue, Sep 10, 2019 at 4:11 PM Alexandre Belloni
> >  wrote:
> >> On 10/09/2019 16:08:26+0100, Sudeep Holla wrote:
> >>> On Tue, Sep 10, 2019 at 02:51:50PM +, claudiu.bez...@microchip.com 
> >>> wrote:
> > 
> >>> In that case, why can't we identify capability that with the compatibles
> >>> for this timer IP ?
> >>>
> >>> IOW, I don't like the proposal as it's hardware limitation.
> >>
> >> To be clear, bot timers are exactly the same but can't be clocksource
> >> and clockevent at the same time. Why would we have different compatibles
> >> for the exact same IP?
> > 
> > In that case why not just pick the first one you find as clocksource
> > and the second one as clock event? As they all come to the
> > same timer of init function two simple local state variables can
> > solve that:
> > 
> > static bool registered_clocksource;
> > static bool registered_clockevent;
> > 
> > probe(timer) {
> >if (!registered_clocksource) {
> >register_clocksource(timer);
> >registrered_clocksource = true;
> >return;
> >}
> >if (!registered_clockevent) {
> >register_clockevent(timer);
> >registered_clockevent = true;
> >return;
> >}
> >pr_info("surplus timer %p\n", timer);
> > }
> > 
> 
> That was also my proposal for the driver I'm sending this series for (see
> [1]) but it has been proposed to implement a mechanism similar to this one
> in this series (see [2] and [3]).

This comes up over and over, and the answer is still no. Either each 
block is identical and doesn't matter which one is used for what or 
there is some h/w difference that you should describe. 

If you want something that would even be considered to put into DT, 
then define something BSD or other OS's could use too. (That's not a 
suggestion to respin this with generalized names.)

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 3/3] dt-bindings: IDU-intc: Add support for edge-triggered interrupts

2019-08-16 Thread Rob Herring
On Wed, 24 Jul 2019 14:04:36 +0200, Mischa Jonker wrote:
> This updates the documentation for supporting an optional extra interrupt
> cell to specify edge vs level triggered.
> 
> Signed-off-by: Mischa Jonker 
> ---
>  .../interrupt-controller/snps,archs-idu-intc.txt  | 19 
> ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
> 

Reviewed-by: Rob Herring 


Re: [PATCH v2 2/3] dt-bindings: IDU-intc: Clean up documentation

2019-08-16 Thread Rob Herring
On Wed, 24 Jul 2019 14:04:35 +0200, Mischa Jonker wrote:
> * Some lines exceeded 80 characters.
> * Clarified statement about AUX register interface
> 
> Signed-off-by: Mischa Jonker 
> ---
>  .../bindings/interrupt-controller/snps,archs-idu-intc.txt| 9 
> +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 

Reviewed-by: Rob Herring 


Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability

2019-02-13 Thread Rob Herring
On Wed, Feb 13, 2019 at 12:24 PM Christoph Hellwig  wrote:
>
> On Tue, Feb 12, 2019 at 02:40:23PM -0600, Rob Herring wrote:
> > > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> > > index 3607fd2810e4..f8c66a9472a4 100644
> > > --- a/drivers/of/Kconfig
> > > +++ b/drivers/of/Kconfig
> > > @@ -43,6 +43,7 @@ config OF_FLATTREE
> > >
> > >  config OF_EARLY_FLATTREE
> > > bool
> > > +   select DMA_DECLARE_COHERENT
> >
> > Is selecting DMA_DECLARE_COHERENT okay on UML? We run the unittests with 
> > UML.
>
> No, that will fail with undefined references to memunmap.
>
> I gues this needs to be
>
> select DMA_DECLARE_COHERENT if HAS_DMA
>
> > Maybe we should just get rid of OF_RESERVED_MEM. If we support booting
> > from DT, then it should always be enabled anyways.
>
> Fine with me.  Do you want me to respin the series to just remove
> it?

Either now or it can wait. I don't want to hold this up any.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability

2019-02-12 Thread Rob Herring
On Mon, Feb 11, 2019 at 7:37 AM Christoph Hellwig  wrote:
>
> This API is primarily used through DT entries, but two architectures
> and two drivers call it directly.  So instead of selecting the config
> symbol for random architectures pull it in implicitly for the actual
> users.  Also rename the Kconfig option to describe the feature better.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/arc/Kconfig| 1 -
>  arch/arm/Kconfig| 2 +-
>  arch/arm64/Kconfig  | 1 -
>  arch/csky/Kconfig   | 1 -
>  arch/mips/Kconfig   | 1 -
>  arch/riscv/Kconfig  | 1 -
>  arch/sh/Kconfig | 2 +-
>  arch/unicore32/Kconfig  | 1 -
>  arch/x86/Kconfig| 1 -
>  drivers/mfd/Kconfig | 2 ++
>  drivers/of/Kconfig  | 3 ++-
>  include/linux/device.h  | 2 +-
>  include/linux/dma-mapping.h | 8 
>  kernel/dma/Kconfig  | 2 +-
>  kernel/dma/Makefile | 2 +-
>  15 files changed, 13 insertions(+), 17 deletions(-)

> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 3607fd2810e4..f8c66a9472a4 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -43,6 +43,7 @@ config OF_FLATTREE
>
>  config OF_EARLY_FLATTREE
> bool
> +   select DMA_DECLARE_COHERENT

Is selecting DMA_DECLARE_COHERENT okay on UML? We run the unittests with UML.

Maybe we should just get rid of OF_RESERVED_MEM. If we support booting
from DT, then it should always be enabled anyways.

> select OF_FLATTREE
>
>  config OF_PROMTREE
> @@ -83,7 +84,7 @@ config OF_MDIO
>  config OF_RESERVED_MEM
> bool
> depends on OF_EARLY_FLATTREE
> -   default y if HAVE_GENERIC_DMA_COHERENT || DMA_CMA
> +   default y if DMA_DECLARE_COHERENT || DMA_CMA
>
>  config OF_RESOLVE
> bool

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 03/12] of: mark early_init_dt_alloc_reserved_memory_arch static

2019-02-12 Thread Rob Herring
On Mon, Feb 11, 2019 at 7:36 AM Christoph Hellwig  wrote:
>
> This function is only used in of_reserved_mem.c, and never overridden
> despite the __weak marker.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/of/of_reserved_mem.c| 2 +-
>  include/linux/of_reserved_mem.h | 7 ---
>  2 files changed, 1 insertion(+), 8 deletions(-)

Reviewed-by: Rob Herring 

Looks like this one isn't a dependency, so I can take it if you want.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 04/12] of: select OF_RESERVED_MEM automatically

2019-02-12 Thread Rob Herring
On Mon, Feb 11, 2019 at 7:37 AM Christoph Hellwig  wrote:
>
> The OF_RESERVED_MEM can be used if we have either CMA or the generic
> declare coherent code built and we support the early flattened DT.
>
> So don't bother making it a user visible options that is selected
> by most configs that fit the above category, but just select it when
> the requirements are met.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/arc/Kconfig | 1 -
>  arch/arm/Kconfig | 1 -
>  arch/arm64/Kconfig   | 1 -
>  arch/csky/Kconfig| 1 -
>  arch/powerpc/Kconfig | 1 -
>  arch/xtensa/Kconfig  | 1 -
>  drivers/of/Kconfig   | 5 ++---
>  7 files changed, 2 insertions(+), 9 deletions(-)

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2] ARC: [scripted] fix node name and address spelling

2019-01-24 Thread Rob Herring
On Thu, Jan 24, 2019 at 6:17 AM Alexey Brodkin
 wrote:
>
> From: Alexey Brodkin 
>
> 1. Remove "0x" prefix from unit-address of node names
> --->8
> sed -i 's/@0x/@/g' arch/arc/boot/dts/*.dts*
> --->8
>
> 2. Make all hex addresses lowercase:
> --->8
> sed -i 's/@\([0-9A-Za-z]*\)/@\L\1/g' arch/arc/boot/dts/*.dts*
> sed -i 's/0x\([0-9A-Za-z]*\)/0x\L\1/g' arch/arc/boot/dts/*.dts*
> --->8
>
> Inspired by [1] and the like.
>
> [1] http://kisskb.ellerman.id.au/kisskb/buildresult/13612017/
>
> Signed-off-by: Alexey Brodkin 
> Cc: Rob Herring 
> ---
>
> Changes v1 -> v2:
>
>  * Convert all hex addresses to lower-case [Rob]
>
>  arch/arc/boot/dts/abilis_tb100.dtsi| 58 
>  arch/arc/boot/dts/abilis_tb100_dvk.dts | 14 
>  arch/arc/boot/dts/abilis_tb101.dtsi| 58 
>  arch/arc/boot/dts/abilis_tb101_dvk.dts | 14 
>  arch/arc/boot/dts/abilis_tb10x.dtsi| 60 
> +-
>  arch/arc/boot/dts/axc001.dtsi  |  6 ++--
>  arch/arc/boot/dts/axc003.dtsi  | 16 -
>  arch/arc/boot/dts/axc003_idu.dtsi  | 16 -
>  arch/arc/boot/dts/axs10x_mb.dtsi   | 22 ++---
>  arch/arc/boot/dts/hsdk.dts |  4 +--
>  arch/arc/boot/dts/vdk_axc003.dtsi  |  4 +--
>  arch/arc/boot/dts/vdk_axc003_idu.dtsi  |  4 +--
>  arch/arc/boot/dts/vdk_axs10x_mb.dtsi   | 18 +-
>  13 files changed, 147 insertions(+), 147 deletions(-)

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

2019-01-21 Thread Rob Herring
On Mon, Jan 21, 2019 at 10:04:06AM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
> 
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
> 
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
> 
> Signed-off-by: Mike Rapoport 
> Reviewed-by: Guo Ren  # c-sky
> Acked-by: Paul Burton# MIPS
> Acked-by: Heiko Carstens  # s390
> Reviewed-by: Juergen Gross  # Xen
> ---
>  arch/alpha/kernel/core_cia.c  |  3 +++
>  arch/alpha/kernel/core_marvel.c   |  6 ++
>  arch/alpha/kernel/pci-noop.c  | 13 +++--
>  arch/alpha/kernel/pci.c   | 11 ++-
>  arch/alpha/kernel/pci_iommu.c | 12 
>  arch/arc/mm/highmem.c |  4 
>  arch/arm/kernel/setup.c   |  6 ++
>  arch/arm/mm/mmu.c | 14 +-
>  arch/arm64/kernel/setup.c |  8 +---
>  arch/arm64/mm/kasan_init.c| 10 ++
>  arch/c6x/mm/dma-coherent.c|  4 
>  arch/c6x/mm/init.c|  3 +++
>  arch/csky/mm/highmem.c|  5 +
>  arch/h8300/mm/init.c  |  3 +++
>  arch/m68k/atari/stram.c   |  4 
>  arch/m68k/mm/init.c   |  3 +++
>  arch/m68k/mm/mcfmmu.c |  6 ++
>  arch/m68k/mm/motorola.c   |  9 +
>  arch/m68k/mm/sun3mmu.c|  6 ++
>  arch/m68k/sun3/sun3dvma.c |  3 +++
>  arch/microblaze/mm/init.c |  8 ++--
>  arch/mips/cavium-octeon/dma-octeon.c  |  3 +++
>  arch/mips/kernel/setup.c  |  3 +++
>  arch/mips/kernel/traps.c  |  3 +++
>  arch/mips/mm/init.c   |  5 +
>  arch/nds32/mm/init.c  | 12 
>  arch/openrisc/mm/ioremap.c|  8 ++--
>  arch/powerpc/kernel/dt_cpu_ftrs.c |  5 +
>  arch/powerpc/kernel/pci_32.c  |  3 +++
>  arch/powerpc/kernel/setup-common.c|  3 +++
>  arch/powerpc/kernel/setup_64.c|  4 
>  arch/powerpc/lib/alloc.c  |  3 +++
>  arch/powerpc/mm/hash_utils_64.c   |  3 +++
>  arch/powerpc/mm/mmu_context_nohash.c  |  9 +
>  arch/powerpc/mm/pgtable-book3e.c  | 12 ++--
>  arch/powerpc/mm/pgtable-book3s64.c|  3 +++
>  arch/powerpc/mm/pgtable-radix.c   |  9 -
>  arch/powerpc/mm/ppc_mmu_32.c  |  3 +++
>  arch/powerpc/platforms/pasemi/iommu.c |  3 +++
>  arch/powerpc/platforms/powermac/nvram.c   |  3 +++
>  arch/powerpc/platforms/powernv/opal.c |  3 +++
>  arch/powerpc/platforms/powernv/pci-ioda.c |  8 
>  arch/powerpc/platforms/ps3/setup.c|  3 +++
>  arch/powerpc/sysdev/msi_bitmap.c  |  3 +++
>  arch/s390/kernel/setup.c  | 13 +
>  arch/s390/kernel/smp.c|  5 -
>  arch/s390/kernel/topology.c   |  6 ++
>  arch/s390/numa/mode_emu.c |  3 +++
>  arch/s390/numa/numa.c |  6 +-
>  arch/sh/mm/init.c |  6 ++
>  arch/sh/mm/numa.c |  4 
>  arch/um/drivers/net_kern.c|  3 +++
>  arch/um/drivers/vector_kern.c |  3 +++
>  arch/um/kernel/initrd.c   |  2 ++
>  arch/um/kernel/mem.c  | 16 
>  arch/unicore32/kernel/setup.c |  4 
>  arch/unicore32/mm/mmu.c   | 15 +--
>  arch/x86/kernel/acpi/boot.c   |  3 +++
>  arch/x86/kernel/apic/io_apic.c|  5 +
>  arch/x86/kernel/e820.c|  3 +++
>  arch/x86/platform/olpc/olpc_dt.c  |  3 +++
>  arch/x86/xen/p2m.c| 11 +--
>  arch/xtensa/mm/kasan_init.c   |  4 
>  arch/xtensa/mm/mmu.c          |  3 +++
>  drivers/clk/ti/clk.c  |  3 +++
>  drivers/macintosh/smu.c   |  3 +++
>  drivers/of/fdt.c  |  8 +++-
>  drivers/of/unittest.c |  8 +++-

Acked-by: Rob Herrin

Re: [PATCH 08/21] memblock: drop __memblock_alloc_base()

2019-01-16 Thread Rob Herring
On Wed, Jan 16, 2019 at 7:45 AM Mike Rapoport  wrote:
>
> The __memblock_alloc_base() function tries to allocate a memory up to the
> limit specified by its max_addr parameter. Depending on the value of this
> parameter, the __memblock_alloc_base() can is replaced with the appropriate
> memblock_phys_alloc*() variant.
>
> Signed-off-by: Mike Rapoport 
> ---
>  arch/sh/kernel/machine_kexec.c |  3 ++-
>  arch/x86/kernel/e820.c |  2 +-
>  arch/x86/mm/numa.c | 12 
>  drivers/of/of_reserved_mem.c   |  7 ++-
>  include/linux/memblock.h   |  2 --
>  mm/memblock.c  |  9 ++---
>  6 files changed, 11 insertions(+), 24 deletions(-)

Acked-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] ARC: Remove 0x prefix from unit-address of node names

2018-12-10 Thread Rob Herring
On Sat, Dec 8, 2018 at 1:01 AM Alexey Brodkin
 wrote:
>
> Done automatically with help of:
> --->8
> sed -i 's/@0x/@/g' arch/arc/boot/dts/*.dts*
> --->8
>
> Inspired by [1] and the like.
>
> [1] http://kisskb.ellerman.id.au/kisskb/buildresult/13612017/
>
> Signed-off-by: Alexey Brodkin 
> Cc: Rob Herring 
>
> Signed-off-by: Alexey Brodkin 
> ---
>  arch/arc/boot/dts/abilis_tb10x.dtsi   |  4 ++--
>  arch/arc/boot/dts/axc001.dtsi |  6 +++---
>  arch/arc/boot/dts/axc003.dtsi | 14 +++---
>  arch/arc/boot/dts/axc003_idu.dtsi | 14 +++---
>  arch/arc/boot/dts/axs10x_mb.dtsi  | 22 +++---
>  arch/arc/boot/dts/vdk_axc003.dtsi |  4 ++--
>  arch/arc/boot/dts/vdk_axc003_idu.dtsi |  4 ++--
>  arch/arc/boot/dts/vdk_axs10x_mb.dtsi  | 14 +++---
>  8 files changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arc/boot/dts/abilis_tb10x.dtsi 
> b/arch/arc/boot/dts/abilis_tb10x.dtsi
> index 3121536b25a3..77ac1368a65b 100644
> --- a/arch/arc/boot/dts/abilis_tb10x.dtsi
> +++ b/arch/arc/boot/dts/abilis_tb10x.dtsi
> @@ -178,7 +178,7 @@
> clocks = <_clk>;
> };
>
> -   spi0: spi@0xFE01 {
> +   spi0: spi@FE01 {

This should be lowercase too.

> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;

[...]

> @@ -119,7 +119,7 @@
>  * This node is intentionally put outside of MB above becase
>  * it maps areas outside of MB's 0xEz-0xFz.
>  */
> -   uio_ev: uio@0xD000 {
> +   uio_ev: uio@D000 {

lowercase

> compatible = "generic-uio";
> reg = <0xD000 0x2000 0xD100 0x2000 0x9000 
> 0x1000 0xC000 0x1000>;
> reg-names = "ev_gsa", "ev_ctrl", "ev_shared_mem", 
> "ev_code_mem";
> --
> 2.16.2
>

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v4 0/6] arm64: Get rid of __early_init_dt_declare_initrd()

2018-11-26 Thread Rob Herring
On Mon, Nov 12, 2018 at 06:22:16PM -0600, Rob Herring wrote:
> On Mon, Nov 12, 2018 at 12:32:50PM -0800, Florian Fainelli wrote:
> > On 11/6/18 6:06 AM, Mike Rapoport wrote:
> > > On Mon, Nov 05, 2018 at 02:54:25PM -0800, Florian Fainelli wrote:
> > >> Hi all,
> > >>
> > >> Changes in v4:
> > >>
> > >> - dropped initrd_below_start_ok assignment in ARM64, not necessary at
> > >>   all (Ard)
> > >> - replace #ifdef CONFIG_BLK_DEV_INITRD with if
> > >>   (IS_ENABLED(CONFIG_BLK_DEV_INITRD) for consistency with other parts
> > >>   of arm64_memblock_init() (Rob)
> > >>
> > >> Changes in v3:
> > >>
> > >> - use C conditionals in drivers/of/fdt.c
> > >> - added check on phys_initrd_size in arch/arm64/mm/init.c to determine
> > >>   whether initrd_start must be populated
> > >> - fixed a build warning with ARC that was just missing an (unsigned
> > >>   long) cast
> > >>
> > >> Changes in v2:
> > >>
> > >> - get rid of ARCH_HAS_PHYS_INITRD and instead define
> > >>   phys_initrd_start/phys_initrd_size in init/do_mounts_initrd.c
> > >>
> > >> - make __early_init_dt_declare_initrd() account for ARM64 specific
> > >>   behavior with __va() when having CONFIG_DEBUG_VM enabled
> > >>
> > >> - consolidate early_initrd() command line parsing into
> > >>   init/do_mounts_initrd.c
> > >>
> > >> Because phys_initrd_start/phys_initrd_size are now compiled in
> > >> ini/do_mounts_initrd.c which is only built with CONFIG_BLK_DEV_INITRD=y,
> > >> we need to be a bit careful about the uses throughout architecture
> > >> specific code.
> > >>
> > >> Previous discussions/submissions list here:
> > >>
> > >> v3:
> > >> https://www.spinics.net/lists/arm-kernel/msg683566.html
> > >> v2:
> > >> https://lkml.org/lkml/2018/10/25/4
> > >>
> > >> Florian Fainelli (6):
> > >>   nds32: Remove phys_initrd_start and phys_initrd_size
> > >>   arch: Make phys_initrd_start and phys_initrd_size global variables
> > >>   of/fdt: Populate phys_initrd_start/phys_initrd_size from FDT
> > >>   arm64: Utilize phys_initrd_start/phys_initrd_size
> > >>   of/fdt: Remove custom __early_init_dt_declare_initrd() implementation
> > >>   arch: Move initrd= parsing into do_mounts_initrd.c
> > > 
> > > For the series:
> > > 
> > > Reviewed-by: Mike Rapoport 
> > 
> > Thanks Mike, Rob, do you want to merge that series through the OF tree?
> 
> Sure, some arch maintainer acks would be nice.

I've now applied the series.

Thanks,

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v4 0/6] arm64: Get rid of __early_init_dt_declare_initrd()

2018-11-12 Thread Rob Herring
On Mon, Nov 12, 2018 at 12:32:50PM -0800, Florian Fainelli wrote:
> On 11/6/18 6:06 AM, Mike Rapoport wrote:
> > On Mon, Nov 05, 2018 at 02:54:25PM -0800, Florian Fainelli wrote:
> >> Hi all,
> >>
> >> Changes in v4:
> >>
> >> - dropped initrd_below_start_ok assignment in ARM64, not necessary at
> >>   all (Ard)
> >> - replace #ifdef CONFIG_BLK_DEV_INITRD with if
> >>   (IS_ENABLED(CONFIG_BLK_DEV_INITRD) for consistency with other parts
> >>   of arm64_memblock_init() (Rob)
> >>
> >> Changes in v3:
> >>
> >> - use C conditionals in drivers/of/fdt.c
> >> - added check on phys_initrd_size in arch/arm64/mm/init.c to determine
> >>   whether initrd_start must be populated
> >> - fixed a build warning with ARC that was just missing an (unsigned
> >>   long) cast
> >>
> >> Changes in v2:
> >>
> >> - get rid of ARCH_HAS_PHYS_INITRD and instead define
> >>   phys_initrd_start/phys_initrd_size in init/do_mounts_initrd.c
> >>
> >> - make __early_init_dt_declare_initrd() account for ARM64 specific
> >>   behavior with __va() when having CONFIG_DEBUG_VM enabled
> >>
> >> - consolidate early_initrd() command line parsing into
> >>   init/do_mounts_initrd.c
> >>
> >> Because phys_initrd_start/phys_initrd_size are now compiled in
> >> ini/do_mounts_initrd.c which is only built with CONFIG_BLK_DEV_INITRD=y,
> >> we need to be a bit careful about the uses throughout architecture
> >> specific code.
> >>
> >> Previous discussions/submissions list here:
> >>
> >> v3:
> >> https://www.spinics.net/lists/arm-kernel/msg683566.html
> >> v2:
> >> https://lkml.org/lkml/2018/10/25/4
> >>
> >> Florian Fainelli (6):
> >>   nds32: Remove phys_initrd_start and phys_initrd_size
> >>   arch: Make phys_initrd_start and phys_initrd_size global variables
> >>   of/fdt: Populate phys_initrd_start/phys_initrd_size from FDT
> >>   arm64: Utilize phys_initrd_start/phys_initrd_size
> >>   of/fdt: Remove custom __early_init_dt_declare_initrd() implementation
> >>   arch: Move initrd= parsing into do_mounts_initrd.c
> > 
> > For the series:
> > 
> > Reviewed-by: Mike Rapoport 
> 
> Thanks Mike, Rob, do you want to merge that series through the OF tree?

Sure, some arch maintainer acks would be nice.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 5/6] of/fdt: Remove custom __early_init_dt_declare_initrd() implementation

2018-10-31 Thread Rob Herring
On Tue, Oct 30, 2018 at 6:07 PM Florian Fainelli  wrote:
>
> Now that ARM64 uses phys_initrd_start/phys_initrd_size, we can get rid
> of its custom __early_init_dt_declare_initrd() which causes a fair
> amount of objects rebuild when changing CONFIG_BLK_DEV_INITRD. In order
> to make sure ARM64 does not produce a BUG() when VM debugging is turned
> on though, we must avoid early calls to __va() which is what
> __early_init_dt_declare_initrd() does and wrap this around to avoid
> running that code on ARM64.
>
> Signed-off-by: Florian Fainelli 
> ---
>  arch/arm64/include/asm/memory.h | 8 
>  drivers/of/fdt.c| 9 +++--
>  2 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b96442960aea..dc3ca21ba240 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -168,14 +168,6 @@
>  #define IOREMAP_MAX_ORDER  (PMD_SHIFT)
>  #endif
>
> -#ifdef CONFIG_BLK_DEV_INITRD
> -#define __early_init_dt_declare_initrd(__start, __end) \
> -   do {\
> -   initrd_start = (__start);   \
> -   initrd_end = (__end);   \
> -   } while (0)
> -#endif
> -
>  #ifndef __ASSEMBLY__
>
>  #include 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index e34cb49231b5..f2b5becae96a 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -892,15 +892,20 @@ const void * __init of_flat_dt_match_machine(const void 
> *default_match,
>  }
>
>  #ifdef CONFIG_BLK_DEV_INITRD
> -#ifndef __early_init_dt_declare_initrd
>  static void __early_init_dt_declare_initrd(unsigned long start,
>unsigned long end)
>  {
> +   /* ARM64 would cause a BUG to occur here when CONFIG_DEBUG_VM is
> +* enabled since __va() is called too early. ARM64 does make use
> +* of phys_initrd_start/phys_initrd_size so we can skip this
> +* conversion.
> +*/
> +#if (!IS_ENABLED(CONFIG_ARM64))

Use 'if' not '#if'. Use C code rather than preprocessor whenever possible.

> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> initrd_below_start_ok = 1;
> -}
>  #endif
> +}
>
>  /**
>   * early_init_dt_check_for_initrd - Decode initrd location from flat tree
> --
> 2.17.1
>

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD

2018-10-25 Thread Rob Herring
On Thu, Oct 25, 2018 at 12:30 PM Mike Rapoport  wrote:
>
> On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
> > +Ard
> >
> > On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport  wrote:
> > >
> > > On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > > > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli  
> > > > wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > > > because we define __early_init_dt_declare_initrd() differently and we 
> > > > > do
> > > > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > > > amount of other header files, and translation units as well.
> > > >
> > > > I scratch my head sometimes as to why some config options rebuild so
> > > > much stuff. One down, ? to go. :)
> > > >
> > > > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with 
> > > > > build
> > > > > systems that generate two kernels: one with the initramfs and one
> > > > > without. buildroot is one of these build systems, OpenWrt is also
> > > > > another one that does this.
> > > > >
> > > > > This patch series proposes adding an empty initrd.h to satisfy the 
> > > > > need
> > > > > for drivers/of/fdt.c to unconditionally include that file, and moves 
> > > > > the
> > > > > custom __early_init_dt_declare_initrd() definition away from
> > > > > asm/memory.h
> > > > >
> > > > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > > > factor 73 approximately.
> > > > >
> > > > > Apologies for the long CC list, please let me know how you would go
> > > > > about merging that and if another approach would be preferable, e.g:
> > > > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > > > something like that.
> > > >
> > > > There may be a better way as of 4.20 because bootmem is now gone and
> > > > only memblock is used. This should unify what each arch needs to do
> > > > with initrd early. We need the physical address early for memblock
> > > > reserving. Then later on we need the virtual address to access the
> > > > initrd. Perhaps we should just change initrd_start and initrd_end to
> > > > physical addresses (or add 2 new variables would be less invasive and
> > > > allow for different translation than __va()). The sanity checks and
> > > > memblock reserve could also perhaps be moved to a common location.
> > > >
> > > > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > > > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > > > __early_init_dt_declare_initrd as long as we have a path to removing
> > > > it like the above option.
> > >
> > > I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> > > Something like this might be just all we need (completely untested,
> > > probably it won't even compile):
> > >
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > index 9d9582c..e9ca238 100644
> > > --- a/arch/arm64/mm/init.c
> > > +++ b/arch/arm64/mm/init.c
> > > @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
> > >  phys_addr_t arm64_dma_phys_limit __ro_after_init;
> > >
> > >  #ifdef CONFIG_BLK_DEV_INITRD
> > > +
> > > +static phys_addr_t initrd_start_phys, initrd_end_phys;
> > > +
> > >  static int __init early_initrd(char *p)
> > >  {
> > > unsigned long start, size;
> > > @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> > > if (*endp == ',') {
> > > size = memparse(endp + 1, NULL);
> > >
> > > -   initrd_start = start;
> > > -   initrd_end = start + size;
> > > +   initrd_start_phys = start;
> > > +   initrd_end_phys = end;
> > > }
> > > return 0;
> > >  }
> > > @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> > >

Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD

2018-10-25 Thread Rob Herring
+Ard

On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport  wrote:
>
> On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli  
> > wrote:
> > >
> > > Hi all,
> > >
> > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > because we define __early_init_dt_declare_initrd() differently and we do
> > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > amount of other header files, and translation units as well.
> >
> > I scratch my head sometimes as to why some config options rebuild so
> > much stuff. One down, ? to go. :)
> >
> > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> > > systems that generate two kernels: one with the initramfs and one
> > > without. buildroot is one of these build systems, OpenWrt is also
> > > another one that does this.
> > >
> > > This patch series proposes adding an empty initrd.h to satisfy the need
> > > for drivers/of/fdt.c to unconditionally include that file, and moves the
> > > custom __early_init_dt_declare_initrd() definition away from
> > > asm/memory.h
> > >
> > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > factor 73 approximately.
> > >
> > > Apologies for the long CC list, please let me know how you would go
> > > about merging that and if another approach would be preferable, e.g:
> > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > something like that.
> >
> > There may be a better way as of 4.20 because bootmem is now gone and
> > only memblock is used. This should unify what each arch needs to do
> > with initrd early. We need the physical address early for memblock
> > reserving. Then later on we need the virtual address to access the
> > initrd. Perhaps we should just change initrd_start and initrd_end to
> > physical addresses (or add 2 new variables would be less invasive and
> > allow for different translation than __va()). The sanity checks and
> > memblock reserve could also perhaps be moved to a common location.
> >
> > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > __early_init_dt_declare_initrd as long as we have a path to removing
> > it like the above option.
>
> I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> Something like this might be just all we need (completely untested,
> probably it won't even compile):
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9d9582c..e9ca238 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
>  phys_addr_t arm64_dma_phys_limit __ro_after_init;
>
>  #ifdef CONFIG_BLK_DEV_INITRD
> +
> +static phys_addr_t initrd_start_phys, initrd_end_phys;
> +
>  static int __init early_initrd(char *p)
>  {
> unsigned long start, size;
> @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> if (*endp == ',') {
> size = memparse(endp + 1, NULL);
>
> -   initrd_start = start;
> -   initrd_end = start + size;
> +   initrd_start_phys = start;
> +   initrd_end_phys = end;
> }
> return 0;
>  }
> @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> }
>
> -   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> +   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
> +   (initrd_start || initrd_start_phys)) {
> +   /*
> +* FIXME: ensure proper precendence between
> +* early_initrd and DT when both are present

Command line takes precedence, so just reverse the order.

> +*/
> +   if (initrd_start) {
> +   initrd_start_phys = __phys_to_virt(initrd_start);
> +   initrd_end_phys = __phys_to_virt(initrd_end);

AIUI, the original issue was doing the P2V translation was happening
too early and the VA could be wrong if the linear range is adjusted.
So I don't think this would work.

I suppose you could convert the VA back to a PA before any adjustments
and then back to a VA again after. But that's kind of hacky. 2 wrongs
making a right.

> +   } else if (i

Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD

2018-10-24 Thread Rob Herring
On Wed, Oct 24, 2018 at 3:01 PM Florian Fainelli  wrote:
>
> On 10/24/18 12:55 PM, Rob Herring wrote:
> > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli  
> > wrote:
> >>
> >> Hi all,
> >>
> >> While investigating why ARM64 required a ton of objects to be rebuilt
> >> when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> >> because we define __early_init_dt_declare_initrd() differently and we do
> >> that in arch/arm64/include/asm/memory.h which gets included by a fair
> >> amount of other header files, and translation units as well.
> >
> > I scratch my head sometimes as to why some config options rebuild so
> > much stuff. One down, ? to go. :)
> >
>
> This one was by far the most invasive one due to its include chain, but
> yes, there would be many more that could be optimized.
>
> >> Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> >> systems that generate two kernels: one with the initramfs and one
> >> without. buildroot is one of these build systems, OpenWrt is also
> >> another one that does this.
> >>
> >> This patch series proposes adding an empty initrd.h to satisfy the need
> >> for drivers/of/fdt.c to unconditionally include that file, and moves the
> >> custom __early_init_dt_declare_initrd() definition away from
> >> asm/memory.h
> >>
> >> This cuts the number of objects rebuilds from 1920 down to 26, so a
> >> factor 73 approximately.
> >>
> >> Apologies for the long CC list, please let me know how you would go
> >> about merging that and if another approach would be preferable, e.g:
> >> introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> >> something like that.
> >
> > There may be a better way as of 4.20 because bootmem is now gone and
> > only memblock is used. This should unify what each arch needs to do
> > with initrd early. We need the physical address early for memblock
> > reserving. Then later on we need the virtual address to access the
> > initrd. Perhaps we should just change initrd_start and initrd_end to
> > physical addresses (or add 2 new variables would be less invasive and
> > allow for different translation than __va()). The sanity checks and
> > memblock reserve could also perhaps be moved to a common location.
> >
> > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > __early_init_dt_declare_initrd as long as we have a path to removing
> > it like the above option.
>
> OK, let me cook a patch doing that and meanwhile I will look at how much
> work is involved to implement the above option you outlined, which also
> sounds entirely reasonable.

BTW, I would suspect that initrd_below_start_ok being 1 is not okay
for most arches. I'm not sure how that would work. min_low_pfn is
typically based on the start of memory. arm64 is not even setting it.

Rob

> --
> Florian

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD

2018-10-24 Thread Rob Herring
On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli  wrote:
>
> Hi all,
>
> While investigating why ARM64 required a ton of objects to be rebuilt
> when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> because we define __early_init_dt_declare_initrd() differently and we do
> that in arch/arm64/include/asm/memory.h which gets included by a fair
> amount of other header files, and translation units as well.

I scratch my head sometimes as to why some config options rebuild so
much stuff. One down, ? to go. :)

> Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> systems that generate two kernels: one with the initramfs and one
> without. buildroot is one of these build systems, OpenWrt is also
> another one that does this.
>
> This patch series proposes adding an empty initrd.h to satisfy the need
> for drivers/of/fdt.c to unconditionally include that file, and moves the
> custom __early_init_dt_declare_initrd() definition away from
> asm/memory.h
>
> This cuts the number of objects rebuilds from 1920 down to 26, so a
> factor 73 approximately.
>
> Apologies for the long CC list, please let me know how you would go
> about merging that and if another approach would be preferable, e.g:
> introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> something like that.

There may be a better way as of 4.20 because bootmem is now gone and
only memblock is used. This should unify what each arch needs to do
with initrd early. We need the physical address early for memblock
reserving. Then later on we need the virtual address to access the
initrd. Perhaps we should just change initrd_start and initrd_end to
physical addresses (or add 2 new variables would be less invasive and
allow for different translation than __va()). The sanity checks and
memblock reserve could also perhaps be moved to a common location.

Alternatively, given arm64 is the only oddball, I'd be fine with an
"if (IS_ENABLED(CONFIG_ARM64))" condition in the default
__early_init_dt_declare_initrd as long as we have a path to removing
it like the above option.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


[PATCH v4 6/9] kbuild: consolidate Devicetree dtb build rules

2018-10-01 Thread Rob Herring
There is nothing arch specific about building dtb files other than their
location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
The dependencies and supported targets are all slightly different.
Also, a cross-compiler for each arch is needed, but really the host
compiler preprocessor is perfectly fine for building dtbs. Move the
build rules to a common location and remove the arch specific ones. This
is done in a single step to avoid warnings about overriding rules.

The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
These pull in several dependencies some of which need a target compiler
(specifically devicetable-offsets.h) and aren't needed to build dtbs.
All that is really needed is dtc, so adjust the dependencies to only be
dtc.

This change enables support 'dtbs_install' on some arches which were
missing the target.

Acked-by: Will Deacon 
Acked-by: Paul Burton 
Acked-by: Ley Foon Tan 
Cc: Masahiro Yamada 
Cc: Michal Marek 
Cc: Vineet Gupta 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Yoshinori Sato 
Cc: Michal Simek 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: linux-kbu...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: linux-m...@linux-mips.org
Cc: nios2-...@lists.rocketboards.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-xte...@linux-xtensa.org
Signed-off-by: Rob Herring 
---
v4:
 - Make dtbs and %.dtb rules depend on arch/$ARCH/boot/dts path rather than
   CONFIG_OF_EARLY_FLATTREE
 - Fix install path missing kernel version for dtbs_install
 - Fix "make CONFIG_OF_ALL_DTBS=y" for arches like ARM which selectively
   enable CONFIG_OF (and therefore dtc)


 Makefile  | 37 ++-
 arch/arc/Makefile |  6 -
 arch/arm/Makefile | 20 +
 arch/arm64/Makefile   | 17 +-
 arch/c6x/Makefile |  2 --
 arch/h8300/Makefile   | 11 +
 arch/microblaze/Makefile  |  4 +---
 arch/microblaze/boot/dts/Makefile |  2 ++
 arch/mips/Makefile| 15 +
 arch/nds32/Makefile   |  2 +-
 arch/nios2/Makefile   |  7 --
 arch/nios2/boot/Makefile  |  4 
 arch/powerpc/Makefile |  3 ---
 arch/xtensa/Makefile  | 12 +-
 scripts/Makefile  |  3 +--
 scripts/Makefile.lib  |  2 +-
 scripts/dtc/Makefile  |  2 +-
 17 files changed, 48 insertions(+), 101 deletions(-)

diff --git a/Makefile b/Makefile
index 6c3da3e10f07..251875470c5b 100644
--- a/Makefile
+++ b/Makefile
@@ -1061,7 +1061,7 @@ include/config/kernel.release: $(srctree)/Makefile FORCE
 # Carefully list dependencies so we do not try to build scripts twice
 # in parallel
 PHONY += scripts
-scripts: scripts_basic asm-generic gcc-plugins $(autoksyms_h)
+scripts: scripts_basic scripts_dtc asm-generic gcc-plugins $(autoksyms_h)
$(Q)$(MAKE) $(build)=$(@)

 # Things we need to do before we recursively start building the kernel
@@ -1205,6 +1205,35 @@ kselftest-merge:
$(srctree)/tools/testing/selftests/*/config
+$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig

+# ---
+# Devicetree files
+
+ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
+dtstree := arch/$(SRCARCH)/boot/dts
+endif
+
+ifneq ($(dtstree),)
+
+%.dtb: prepare3 scripts_dtc
+   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
+
+PHONY += dtbs dtbs_install
+dtbs: prepare3 scripts_dtc
+   $(Q)$(MAKE) $(build)=$(dtstree)
+
+dtbs_install:
+   $(Q)$(MAKE) $(dtbinst)=$(dtstree)
+
+ifdef CONFIG_OF_EARLY_FLATTREE
+all: dtbs
+endif
+
+endif
+
+PHONY += scripts_dtc
+scripts_dtc: scripts_basic
+   $(Q)$(MAKE) $(build)=scripts/dtc
+
 # ---
 # Modules

@@ -1414,6 +1443,12 @@ help:
@echo  '  kselftest-merge - Merge all the config dependencies of 
kselftest to existing'
@echo  '.config.'
@echo  ''
+   @$(if $(dtstree), \
+   echo 'Devicetree:'; \
+   echo '* dtbs- Build device tree blobs for enabled 
boards'; \
+   echo '  dtbs_install- Install dtbs to 
$(INSTALL_DTBS_PATH)'; \
+   echo '')
+
@echo 'Userspace tools targets:'
@echo '  use "make tools/help"'
@echo '  or  "cd tools; make help"'
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 99cce77ab98f..caece8866080 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -124,11 +124,5 @@ boot_targets += uImage uImage.bin uImage.gz
 $(boot_targets): vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(bo

[PATCH v4 0/9] Devicetree build consolidation

2018-10-01 Thread Rob Herring
This series addresses a couple of issues I have with building dts files.

First, the ability to build all the dts files in the tree. This has been
supported on most arches for some time with powerpc being the main
exception. The reason powerpc wasn't supported was it needed a change
in the location built dtb files are put.

Secondly, it's a pain to acquire all the cross-compilers needed to build
dtbs for each arch. There's no reason to build with the cross compiler and
the host compiler is perfectly fine as we only need the pre-processor.

I started addressing just those 2 problems, but kept finding small
differences such as target dependencies and dtbs_install support across
architectures. Instead of trying to align all these, I've consolidated the
build targets moving them out of the arch makefiles.

I'd like to take the series via the DT tree.

PPC maintainers, really need you review/ack on this especially patch 1.

Rob


v4:
 - Make dtbs and %.dtb rules depend on arch/$ARCH/boot/dts path rather than
   CONFIG_OF_EARLY_FLATTREE
 - Fix install path missing kernel version for dtbs_install
 - Fix "make CONFIG_OF_ALL_DTBS=y" for arches like ARM which selectively
   enable CONFIG_OF (and therefore dtc)

v3:
 - Rework dtc dependency to avoid 2 entry paths to scripts/dtc/. Essentially,
   I copied 'scripts_basic'.
 - Add missing scripts_basic dependency for dtc and missing PHONY tag.
 - Drop the '|' order only from dependencies
 - Drop %.dtb.S and %.dtb.o as top-level targets
 - PPC: remove duplicate mpc5200 dtbs from image-y targets

v2:
 - Fix $arch/boot/dts path check for out of tree builds
 - Fix dtc dependency for building built-in dtbs
 - Fix microblaze built-in dtb building
 - Add dtbs target for microblaze


Rob Herring (9):
  powerpc: build .dtb files in dts directory
  nios2: build .dtb files in dts directory
  nios2: use common rules to build built-in dtb
  nios2: fix building all dtbs
  c6x: use common built-in dtb support
  kbuild: consolidate Devicetree dtb build rules
  powerpc: enable building all dtbs
  c6x: enable building all dtbs
  microblaze: enable building all dtbs

 Makefile   | 37 +++-
 arch/arc/Makefile  |  6 
 arch/arm/Makefile  | 20 +--
 arch/arm64/Makefile| 17 +
 arch/c6x/Makefile  |  2 --
 arch/c6x/boot/dts/Makefile | 17 -
 arch/c6x/boot/dts/linked_dtb.S |  2 --
 arch/c6x/include/asm/sections.h|  1 -
 arch/c6x/kernel/setup.c|  4 +--
 arch/c6x/kernel/vmlinux.lds.S  | 10 --
 arch/h8300/Makefile| 11 +-
 arch/microblaze/Makefile   |  4 +--
 arch/microblaze/boot/dts/Makefile  |  4 +++
 arch/mips/Makefile | 15 +---
 arch/nds32/Makefile|  2 +-
 arch/nios2/Makefile| 11 +-
 arch/nios2/boot/Makefile   | 22 
 arch/nios2/boot/dts/Makefile   |  6 
 arch/nios2/boot/linked_dtb.S   | 19 ---
 arch/powerpc/Makefile  |  3 --
 arch/powerpc/boot/Makefile | 55 ++
 arch/powerpc/boot/dts/Makefile |  6 
 arch/powerpc/boot/dts/fsl/Makefile |  4 +++
 arch/xtensa/Makefile   | 12 +--
 scripts/Makefile   |  3 +-
 scripts/Makefile.lib   |  2 +-
 scripts/dtc/Makefile   |  2 +-
 27 files changed, 102 insertions(+), 195 deletions(-)
 delete mode 100644 arch/c6x/boot/dts/linked_dtb.S
 create mode 100644 arch/nios2/boot/dts/Makefile
 delete mode 100644 arch/nios2/boot/linked_dtb.S
 create mode 100644 arch/powerpc/boot/dts/Makefile
 create mode 100644 arch/powerpc/boot/dts/fsl/Makefile

--
2.17.1

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules

2018-10-01 Thread Rob Herring
On Mon, Oct 1, 2018 at 12:49 AM Masahiro Yamada
 wrote:
>
> Hi Rob,
>
>
> 2018年9月29日(土) 0:43 Rob Herring :
>
> > +#
> > ---
> > +# Devicetree files
> > +
> > +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
> > +dtstree := arch/$(SRCARCH)/boot/dts
> > +endif
> > +
> > +ifneq ($(dtstree),)
> > +
> > +%.dtb : scripts_dtc
>
> %.dtb: prepare3 prepare

I assume you didn't mean to drop scripts_dtc as that doesn't work.

Why "prepare" here and not on dtbs?

> because we need to make sure KERNELRELEASE
> is correctly defined before dtbs_install happens.

Yes, indeed. With prepare3 added I get:

cp: cannot create regular file
'/boot/dtbs/4.19.0-rc3-9-g0afba9b7b2ea-dirty': No such file or
directory

vs. with it:

cp: cannot create regular file '/boot/dtbs/': Not a directory

>
>
> > +   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
> > +
> > +PHONY += dtbs dtbs_install
> > +dtbs: scripts_dtc
>
>
> dtbs: prepare3 scripts_dtc
>
>
>
> > +   $(Q)$(MAKE) $(build)=$(dtstree)
> > +
> > +dtbs_install: dtbs
>
>
> Please do not have dtbs_install to depend on dtbs.
>
> No install targets should ever trigger building anything
> in the source tree.
>
>
> For the background, see the commit log of
> 19514fc665ffbce624785f76ee7ad0ea6378a527

Okay, thanks.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules

2018-09-28 Thread Rob Herring
On Fri, Sep 28, 2018 at 12:21 PM Andreas Färber  wrote:
>
> Hi Geert,
>
> Am 13.09.18 um 17:51 schrieb Geert Uytterhoeven:
> > On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada
> >  wrote:
> >> Even x86 can enable OF and OF_UNITTEST.
> >>
> >> Another solution might be,
> >> guard it by 'depends on ARCH_SUPPORTS_OF'.
> >>
> >> This is actually what ACPI does.
> >>
> >> menuconfig ACPI
> >> bool "ACPI (Advanced Configuration and Power Interface) Support"
> >> depends on ARCH_SUPPORTS_ACPI
> >>  ...
> >
> > ACPI is a real platform feature, as it depends on firmware.
> >
> > CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform,
> > even if it has ACPI ;-)
>
> How would loading a DT overlay work on an ACPI platform? I.e., what
> would it overlay against and how to practically load such a file?

The DT unittests do just that. I run them on x86 and UM builds. In
this case, the loading source is built-in.

> I wonder whether that could be helpful for USB devices and serdev...

How to load the overlays is pretty orthogonal to the issues to be
solved here. It would certainly be possible to move forward with
prototyping this and just have the overlay built-in. It may not even
need to be an overlay if we can support multiple root nodes.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules

2018-09-28 Thread Rob Herring
On Sun, Sep 23, 2018 at 06:31:14AM -0400, Masahiro Yamada wrote:
> 2018-09-13 11:51 GMT-04:00 Geert Uytterhoeven :
> > Hi Yamada-san,
> >
> > On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada
> >  wrote:
> >> 2018-09-12 0:40 GMT+09:00 Rob Herring :
> >> > On Mon, Sep 10, 2018 at 10:04 AM Rob Herring  wrote:
> >> >> There is nothing arch specific about building dtb files other than their
> >> >> location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
> >> >> The dependencies and supported targets are all slightly different.
> >> >> Also, a cross-compiler for each arch is needed, but really the host
> >> >> compiler preprocessor is perfectly fine for building dtbs. Move the
> >> >> build rules to a common location and remove the arch specific ones. This
> >> >> is done in a single step to avoid warnings about overriding rules.
> >> >>
> >> >> The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
> >> >> These pull in several dependencies some of which need a target compiler
> >> >> (specifically devicetable-offsets.h) and aren't needed to build dtbs.
> >> >> All that is really needed is dtc, so adjust the dependencies to only be
> >> >> dtc.
> >> >>
> >> >> This change enables support 'dtbs_install' on some arches which were
> >> >> missing the target.
> >> >
> >> > [...]
> >> >
> >> >> @@ -1215,6 +1215,33 @@ kselftest-merge:
> >> >> $(srctree)/tools/testing/selftests/*/config
> >> >> +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig
> >> >>
> >> >> +# 
> >> >> ---
> >> >> +# Devicetree files
> >> >> +
> >> >> +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
> >> >> +dtstree := arch/$(SRCARCH)/boot/dts
> >> >> +endif
> >> >> +
> >> >> +ifdef CONFIG_OF_EARLY_FLATTREE
> >> >
> >> > This can be true when dtstree is unset. So this line should be this
> >> > instead to fix the 0-day reported error:
> >> >
> >> > ifneq ($(dtstree),)
> >> >
> >> >> +
> >> >> +%.dtb : scripts_dtc
> >> >> +   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
> >> >> +
> >> >> +PHONY += dtbs dtbs_install
> >> >> +dtbs: scripts_dtc
> >> >> +   $(Q)$(MAKE) $(build)=$(dtstree)
> >> >> +
> >> >> +dtbs_install: dtbs
> >> >> +   $(Q)$(MAKE) $(dtbinst)=$(dtstree)
> >> >> +
> >> >> +all: dtbs
> >> >> +
> >> >> +endif
> >>
> >>
> >> Ah, right.
> >> Even x86 can enable OF and OF_UNITTEST.
> >>
> >>
> >>
> >> Another solution might be,
> >> guard it by 'depends on ARCH_SUPPORTS_OF'.
> >>
> >>
> >>
> >> This is actually what ACPI does.
> >>
> >> menuconfig ACPI
> >> bool "ACPI (Advanced Configuration and Power Interface) Support"
> >> depends on ARCH_SUPPORTS_ACPI
> >>  ...
> >
> > ACPI is a real platform feature, as it depends on firmware.
> >
> > CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform,
> > even if it has ACPI ;-)
> >
> 
> OK, understood.

Any other comments on this? I'd like to get the series into linux-next 
soon.

There was one other problem 0-day reported when building with 
CONFIG_OF=n while setting CONFIG_OF_ALL_DTBS=y on the kernel command 
line. The problem is dtc is not built as setting options on the command 
line doesn't invoke kconfig select(s). This can be fixed by also 
adding CONFIG_DTC=y to the command line, always building dtc regardless 
of Kconfig, or making 'all' conditionally dependent on 'dtbs'. I've gone 
with the last option as that is how this problem was avoided before. 

So the hunk in question with the 2 fixes now looks like this:

@@ -1215,6 +1215,35 @@ kselftest-merge:
$(srctree)/tools/testing/selftests/*/config
+$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig
 
+# 
---
+# Devicetree files
+
+ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
+dtstree := arch/$(SRCARCH)/boot/dts
+endif
+
+ifneq ($(dtstree),)
+
+%.dtb : scripts_dtc
+   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
+
+PHONY += dtbs dtbs_install
+dtbs: scripts_dtc
+   $(Q)$(MAKE) $(build)=$(dtstree)
+
+dtbs_install: dtbs
+   $(Q)$(MAKE) $(dtbinst)=$(dtstree)
+
+ifdef CONFIG_OF_EARLY_FLATTREE
+all: dtbs
+endif
+
+endif
+
+PHONY += scripts_dtc
+scripts_dtc: scripts_basic
+   $(Q)$(MAKE) $(build)=scripts/dtc
+
 # 
---
 # Modules
 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v3 2/2] dt-bindings: Document the Synopsys GPIO via CREG bindings

2018-09-26 Thread Rob Herring
On Tue, 11 Sep 2018 18:09:25 +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> GPIO via CREG driver.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  .../devicetree/bindings/gpio/snps,creg-gpio.txt| 18 
> ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> 

Reviewed-by: Rob Herring 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules

2018-09-11 Thread Rob Herring
On Mon, Sep 10, 2018 at 10:04 AM Rob Herring  wrote:
>
> There is nothing arch specific about building dtb files other than their
> location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
> The dependencies and supported targets are all slightly different.
> Also, a cross-compiler for each arch is needed, but really the host
> compiler preprocessor is perfectly fine for building dtbs. Move the
> build rules to a common location and remove the arch specific ones. This
> is done in a single step to avoid warnings about overriding rules.
>
> The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
> These pull in several dependencies some of which need a target compiler
> (specifically devicetable-offsets.h) and aren't needed to build dtbs.
> All that is really needed is dtc, so adjust the dependencies to only be
> dtc.
>
> This change enables support 'dtbs_install' on some arches which were
> missing the target.

[...]

> @@ -1215,6 +1215,33 @@ kselftest-merge:
> $(srctree)/tools/testing/selftests/*/config
> +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig
>
> +# ---
> +# Devicetree files
> +
> +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
> +dtstree := arch/$(SRCARCH)/boot/dts
> +endif
> +
> +ifdef CONFIG_OF_EARLY_FLATTREE

This can be true when dtstree is unset. So this line should be this
instead to fix the 0-day reported error:

ifneq ($(dtstree),)

> +
> +%.dtb : scripts_dtc
> +   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
> +
> +PHONY += dtbs dtbs_install
> +dtbs: scripts_dtc
> +   $(Q)$(MAKE) $(build)=$(dtstree)
> +
> +dtbs_install: dtbs
> +   $(Q)$(MAKE) $(dtbinst)=$(dtstree)
> +
> +all: dtbs
> +
> +endif

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


[PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules

2018-09-10 Thread Rob Herring
There is nothing arch specific about building dtb files other than their
location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
The dependencies and supported targets are all slightly different.
Also, a cross-compiler for each arch is needed, but really the host
compiler preprocessor is perfectly fine for building dtbs. Move the
build rules to a common location and remove the arch specific ones. This
is done in a single step to avoid warnings about overriding rules.

The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
These pull in several dependencies some of which need a target compiler
(specifically devicetable-offsets.h) and aren't needed to build dtbs.
All that is really needed is dtc, so adjust the dependencies to only be
dtc.

This change enables support 'dtbs_install' on some arches which were
missing the target.

Acked-by: Will Deacon 
Acked-by: Paul Burton 
Acked-by: Ley Foon Tan 
Cc: Masahiro Yamada 
Cc: Michal Marek 
Cc: Vineet Gupta 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Yoshinori Sato 
Cc: Michal Simek 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: linux-kbu...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: linux-m...@linux-mips.org
Cc: nios2-...@lists.rocketboards.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-xte...@linux-xtensa.org
Signed-off-by: Rob Herring 
---
 Makefile  | 35 ++-
 arch/arc/Makefile |  6 --
 arch/arm/Makefile | 20 +-
 arch/arm64/Makefile   | 17 +--
 arch/c6x/Makefile |  2 --
 arch/h8300/Makefile   | 11 +-
 arch/microblaze/Makefile  |  4 +---
 arch/microblaze/boot/dts/Makefile |  2 ++
 arch/mips/Makefile| 15 +
 arch/nds32/Makefile   |  2 +-
 arch/nios2/Makefile   |  7 ---
 arch/nios2/boot/Makefile  |  4 
 arch/powerpc/Makefile |  3 ---
 arch/xtensa/Makefile  | 12 +--
 scripts/Makefile  |  3 +--
 scripts/Makefile.lib  |  2 +-
 scripts/dtc/Makefile  |  2 +-
 17 files changed, 46 insertions(+), 101 deletions(-)

diff --git a/Makefile b/Makefile
index 19948e556941..c43859eba70f 100644
--- a/Makefile
+++ b/Makefile
@@ -1071,7 +1071,7 @@ include/config/kernel.release: $(srctree)/Makefile FORCE
 # Carefully list dependencies so we do not try to build scripts twice
 # in parallel
 PHONY += scripts
-scripts: scripts_basic asm-generic gcc-plugins $(autoksyms_h)
+scripts: scripts_basic scripts_dtc asm-generic gcc-plugins $(autoksyms_h)
$(Q)$(MAKE) $(build)=$(@)
 
 # Things we need to do before we recursively start building the kernel
@@ -1215,6 +1215,33 @@ kselftest-merge:
$(srctree)/tools/testing/selftests/*/config
+$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig
 
+# ---
+# Devicetree files
+
+ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
+dtstree := arch/$(SRCARCH)/boot/dts
+endif
+
+ifdef CONFIG_OF_EARLY_FLATTREE
+
+%.dtb : scripts_dtc
+   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
+
+PHONY += dtbs dtbs_install
+dtbs: scripts_dtc
+   $(Q)$(MAKE) $(build)=$(dtstree)
+
+dtbs_install: dtbs
+   $(Q)$(MAKE) $(dtbinst)=$(dtstree)
+
+all: dtbs
+
+endif
+
+PHONY += scripts_dtc
+scripts_dtc: scripts_basic
+   $(Q)$(MAKE) $(build)=scripts/dtc
+
 # ---
 # Modules
 
@@ -1424,6 +1451,12 @@ help:
@echo  '  kselftest-merge - Merge all the config dependencies of 
kselftest to existing'
@echo  '.config.'
@echo  ''
+   @$(if $(dtstree), \
+   echo 'Devicetree:'; \
+   echo '* dtbs- Build device tree blobs for enabled 
boards'; \
+   echo '  dtbs_install- Install dtbs to 
$(INSTALL_DTBS_PATH)'; \
+   echo '')
+
@echo 'Userspace tools targets:'
@echo '  use "make tools/help"'
@echo '  or  "cd tools; make help"'
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index fb026196aaab..5c7bc6d62f43 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -132,11 +132,5 @@ boot_targets += uImage uImage.bin uImage.gz
 $(boot_targets): vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
-%.dtb %.dtb.S %.dtb.o: scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@
-
-dtbs: scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts
-
 archclean:
$(Q)$(MAKE) $(clean)=$(boot)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d1516f85f25d..161c2df6567e 100644
--- a/arch/arm/Makefile
+++

[PATCH v3 0/9] Devicetree build consolidation

2018-09-10 Thread Rob Herring
This series addresses a couple of issues I have with building dts files.

First, the ability to build all the dts files in the tree. This has been
supported on most arches for some time with powerpc being the main
exception. The reason powerpc wasn't supported was it needed a change
in the location built dtb files are put.

Secondly, it's a pain to acquire all the cross-compilers needed to build
dtbs for each arch. There's no reason to build with the cross compiler and
the host compiler is perfectly fine as we only need the pre-processor.

I started addressing just those 2 problems, but kept finding small
differences such as target dependencies and dtbs_install support across
architectures. Instead of trying to align all these, I've consolidated the
build targets moving them out of the arch makefiles.

I'd like to take the series via the DT tree.

Rob

v3:
 - Rework dtc dependency to avoid 2 entry paths to scripts/dtc/. Essentially,
   I copied 'scripts_basic'.
 - Add missing scripts_basic dependency for dtc and missing PHONY tag.
 - Drop the '|' order only from dependencies
 - Drop %.dtb.S and %.dtb.o as top-level targets
 - PPC: remove duplicate mpc5200 dtbs from image-y targets

v2:
 - Fix $arch/boot/dts path check for out of tree builds
 - Fix dtc dependency for building built-in dtbs
 - Fix microblaze built-in dtb building
 - Add dtbs target for microblaze

Rob Herring (9):
  powerpc: build .dtb files in dts directory
  nios2: build .dtb files in dts directory
  nios2: use common rules to build built-in dtb
  nios2: fix building all dtbs
  c6x: use common built-in dtb support
  kbuild: consolidate Devicetree dtb build rules
  powerpc: enable building all dtbs
  c6x: enable building all dtbs
  microblaze: enable building all dtbs

 Makefile   | 35 ++-
 arch/arc/Makefile  |  6 
 arch/arm/Makefile  | 20 +--
 arch/arm64/Makefile| 17 +
 arch/c6x/Makefile  |  2 --
 arch/c6x/boot/dts/Makefile | 17 -
 arch/c6x/boot/dts/linked_dtb.S |  2 --
 arch/c6x/include/asm/sections.h|  1 -
 arch/c6x/kernel/setup.c|  4 +--
 arch/c6x/kernel/vmlinux.lds.S  | 10 --
 arch/h8300/Makefile| 11 +-
 arch/microblaze/Makefile   |  4 +--
 arch/microblaze/boot/dts/Makefile  |  4 +++
 arch/mips/Makefile | 15 +---
 arch/nds32/Makefile|  2 +-
 arch/nios2/Makefile| 11 +-
 arch/nios2/boot/Makefile   | 22 
 arch/nios2/boot/dts/Makefile   |  6 
 arch/nios2/boot/linked_dtb.S   | 19 ---
 arch/powerpc/Makefile  |  3 --
 arch/powerpc/boot/Makefile | 55 ++
 arch/powerpc/boot/dts/Makefile |  6 
 arch/powerpc/boot/dts/fsl/Makefile |  4 +++
 arch/xtensa/Makefile   | 12 +--
 scripts/Makefile   |  3 +-
 scripts/Makefile.lib   |  2 +-
 scripts/dtc/Makefile   |  2 +-
 27 files changed, 100 insertions(+), 195 deletions(-)
 delete mode 100644 arch/c6x/boot/dts/linked_dtb.S
 create mode 100644 arch/nios2/boot/dts/Makefile
 delete mode 100644 arch/nios2/boot/linked_dtb.S
 create mode 100644 arch/powerpc/boot/dts/Makefile
 create mode 100644 arch/powerpc/boot/dts/fsl/Makefile

--
2.17.1

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules

2018-09-10 Thread Rob Herring
On Sun, Sep 9, 2018 at 6:28 PM Masahiro Yamada
 wrote:
>
> 2018-09-06 8:53 GMT+09:00 Rob Herring :
> > There is nothing arch specific about building dtb files other than their
> > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
> > The dependencies and supported targets are all slightly different.
> > Also, a cross-compiler for each arch is needed, but really the host
> > compiler preprocessor is perfectly fine for building dtbs. Move the
> > build rules to a common location and remove the arch specific ones. This
> > is done in a single step to avoid warnings about overriding rules.
> >
> > The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
> > These pull in several dependencies some of which need a target compiler
> > (specifically devicetable-offsets.h) and aren't needed to build dtbs.
> > All that is really needed is dtc, so adjust the dependencies to only be
> > dtc.
> >
> > This change enables support 'dtbs_install' on some arches which were
> > missing the target.
> >
> > Cc: Masahiro Yamada 
> > Cc: Michal Marek 
> > Cc: Vineet Gupta 
> > Cc: Russell King 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Yoshinori Sato 
> > Cc: Michal Simek 
> > Cc: Ralf Baechle 
> > Cc: Paul Burton 
> > Cc: James Hogan 
> > Cc: Ley Foon Tan 
> > Cc: Benjamin Herrenschmidt 
> > Cc: Paul Mackerras 
> > Cc: Michael Ellerman 
> > Cc: Chris Zankel 
> > Cc: Max Filippov 
> > Cc: linux-kbu...@vger.kernel.org
> > Cc: linux-snps-arc@lists.infradead.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: uclinux-h8-de...@lists.sourceforge.jp
> > Cc: linux-m...@linux-mips.org
> > Cc: nios2-...@lists.rocketboards.org
> > Cc: linuxppc-...@lists.ozlabs.org
> > Cc: linux-xte...@linux-xtensa.org
> > Signed-off-by: Rob Herring 
> > ---
> > Please ack so I can take the whole series via the DT tree.
> >
> > v2:
> >  - Fix $arch/boot/dts path check for out of tree builds
> >  - Fix dtc dependency for building built-in dtbs
> >  - Fix microblaze built-in dtb building
> >
> >  Makefile  | 32 +++
> >  arch/arc/Makefile |  6 --
> >  arch/arm/Makefile | 20 +--
> >  arch/arm64/Makefile   | 17 +---
> >  arch/c6x/Makefile |  2 --
> >  arch/h8300/Makefile   | 11 +--
> >  arch/microblaze/Makefile  |  4 +---
> >  arch/microblaze/boot/dts/Makefile |  2 ++
> >  arch/mips/Makefile| 15 +--
> >  arch/nds32/Makefile   |  2 +-
> >  arch/nios2/Makefile   |  7 ---
> >  arch/nios2/boot/Makefile  |  4 
> >  arch/powerpc/Makefile |  3 ---
> >  arch/xtensa/Makefile  | 12 +---
> >  scripts/Makefile.lib  |  2 +-
> >  15 files changed, 42 insertions(+), 97 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 2b458801ba74..bc18dbbc16c5 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1212,6 +1212,32 @@ kselftest-merge:
> > $(srctree)/tools/testing/selftests/*/config
> > +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig
> >
> > +# 
> > ---
> > +# Devicetree files
> > +
> > +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
> > +dtstree := arch/$(SRCARCH)/boot/dts
> > +endif
> > +
> > +ifdef CONFIG_OF_EARLY_FLATTREE
> > +
> > +%.dtb %.dtb.S %.dtb.o: | dtc
> > +   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
>
>
> Hmm, I was worried about '%.dtb.o: | dtc'
> but seems working.
>
> Compiling %.S -> %.o requires objtool for x86,
> but x86 does not support DT.

Well, x86 does support DT to some extent. There's 2 platforms and the
DT unittests build and run on x86.

Actually, we can remove "%.dtb.S %.dtb.o" because we don't need those
as top-level build targets. Must have been a copy-n-paste relic from
before having common rules.

>
> If CONFIG_MODVERSIONS=y, scripts/genksyms/genksyms is required,
> %.dtb.S does not contain EXPORT_SYMBOL.

Okay, but that shouldn't affect any of this. We only build *.dtb.S
when doing built-in dtbs.

> BTW, 'dtc' should be a PHONY target.

Right, I found that too.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules

2018-09-07 Thread Rob Herring
On Fri, Sep 7, 2018 at 5:33 AM Masahiro Yamada
 wrote:
>
> 2018-09-06 8:53 GMT+09:00 Rob Herring :
> > There is nothing arch specific about building dtb files other than their
> > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
> > The dependencies and supported targets are all slightly different.
> > Also, a cross-compiler for each arch is needed, but really the host
> > compiler preprocessor is perfectly fine for building dtbs. Move the
> > build rules to a common location and remove the arch specific ones. This
> > is done in a single step to avoid warnings about overriding rules.
> >
> > The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
> > These pull in several dependencies some of which need a target compiler
> > (specifically devicetable-offsets.h) and aren't needed to build dtbs.
> > All that is really needed is dtc, so adjust the dependencies to only be
> > dtc.
> >
> > This change enables support 'dtbs_install' on some arches which were
> > missing the target.
> >
> > Cc: Masahiro Yamada 
> > Cc: Michal Marek 
> > Cc: Vineet Gupta 
> > Cc: Russell King 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Yoshinori Sato 
> > Cc: Michal Simek 
> > Cc: Ralf Baechle 
> > Cc: Paul Burton 
> > Cc: James Hogan 
> > Cc: Ley Foon Tan 
> > Cc: Benjamin Herrenschmidt 
> > Cc: Paul Mackerras 
> > Cc: Michael Ellerman 
> > Cc: Chris Zankel 
> > Cc: Max Filippov 
> > Cc: linux-kbu...@vger.kernel.org
> > Cc: linux-snps-arc@lists.infradead.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: uclinux-h8-de...@lists.sourceforge.jp
> > Cc: linux-m...@linux-mips.org
> > Cc: nios2-...@lists.rocketboards.org
> > Cc: linuxppc-...@lists.ozlabs.org
> > Cc: linux-xte...@linux-xtensa.org
> > Signed-off-by: Rob Herring 
> > ---
> > Please ack so I can take the whole series via the DT tree.
> >
> > v2:
> >  - Fix $arch/boot/dts path check for out of tree builds
> >  - Fix dtc dependency for building built-in dtbs
> >  - Fix microblaze built-in dtb building
>
>
> This breaks parallel building
> because two threads could descend into scripts/dtc
> at the same time.
>
> 'all' depends on both 'scripts' and 'dtc'.
>
> * 'scripts' target -- descends into scripts/, then scripts/dtc
> * 'dtc' target -- descents into scripts/dtc directly

Any suggestions for how to fix given the problem with depending on
scripts? I suppose I could make scripts depend on dtc instead, but I'd
be back to needing to fix cleaning. Or I could just skip removing the
cross compiler dependency for now.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


[PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules

2018-09-05 Thread Rob Herring
There is nothing arch specific about building dtb files other than their
location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
The dependencies and supported targets are all slightly different.
Also, a cross-compiler for each arch is needed, but really the host
compiler preprocessor is perfectly fine for building dtbs. Move the
build rules to a common location and remove the arch specific ones. This
is done in a single step to avoid warnings about overriding rules.

The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
These pull in several dependencies some of which need a target compiler
(specifically devicetable-offsets.h) and aren't needed to build dtbs.
All that is really needed is dtc, so adjust the dependencies to only be
dtc.

This change enables support 'dtbs_install' on some arches which were
missing the target.

Cc: Masahiro Yamada 
Cc: Michal Marek 
Cc: Vineet Gupta 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Yoshinori Sato 
Cc: Michal Simek 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Ley Foon Tan 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: linux-kbu...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: linux-m...@linux-mips.org
Cc: nios2-...@lists.rocketboards.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-xte...@linux-xtensa.org
Signed-off-by: Rob Herring 
---
Please ack so I can take the whole series via the DT tree.

v2:
 - Fix $arch/boot/dts path check for out of tree builds
 - Fix dtc dependency for building built-in dtbs
 - Fix microblaze built-in dtb building

 Makefile  | 32 +++
 arch/arc/Makefile |  6 --
 arch/arm/Makefile | 20 +--
 arch/arm64/Makefile   | 17 +---
 arch/c6x/Makefile |  2 --
 arch/h8300/Makefile   | 11 +--
 arch/microblaze/Makefile  |  4 +---
 arch/microblaze/boot/dts/Makefile |  2 ++
 arch/mips/Makefile| 15 +--
 arch/nds32/Makefile   |  2 +-
 arch/nios2/Makefile   |  7 ---
 arch/nios2/boot/Makefile  |  4 
 arch/powerpc/Makefile |  3 ---
 arch/xtensa/Makefile  | 12 +---
 scripts/Makefile.lib  |  2 +-
 15 files changed, 42 insertions(+), 97 deletions(-)

diff --git a/Makefile b/Makefile
index 2b458801ba74..bc18dbbc16c5 100644
--- a/Makefile
+++ b/Makefile
@@ -1212,6 +1212,32 @@ kselftest-merge:
$(srctree)/tools/testing/selftests/*/config
+$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig

+# ---
+# Devicetree files
+
+ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
+dtstree := arch/$(SRCARCH)/boot/dts
+endif
+
+ifdef CONFIG_OF_EARLY_FLATTREE
+
+%.dtb %.dtb.S %.dtb.o: | dtc
+   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
+
+PHONY += dtbs
+dtbs: | dtc
+   $(Q)$(MAKE) $(build)=$(dtstree)
+
+dtbs_install: dtbs
+   $(Q)$(MAKE) $(dtbinst)=$(dtstree)
+
+all: dtbs
+
+dtc:
+   $(Q)$(MAKE) $(build)=scripts/dtc
+
+endif
+
 # ---
 # Modules

@@ -1421,6 +1447,12 @@ help:
@echo  '  kselftest-merge - Merge all the config dependencies of 
kselftest to existing'
@echo  '.config.'
@echo  ''
+   @$(if $(dtstree), \
+   echo 'Devicetree:'; \
+   echo '* dtbs- Build device tree blobs for enabled 
boards'; \
+   echo '  dtbs_install- Install dtbs to 
$(INSTALL_DTBS_PATH)'; \
+   echo '')
+
@echo 'Userspace tools targets:'
@echo '  use "make tools/help"'
@echo '  or  "cd tools; make help"'
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index fb026196aaab..5c7bc6d62f43 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -132,11 +132,5 @@ boot_targets += uImage uImage.bin uImage.gz
 $(boot_targets): vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@

-%.dtb %.dtb.S %.dtb.o: scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@
-
-dtbs: scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts
-
 archclean:
$(Q)$(MAKE) $(clean)=$(boot)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d1516f85f25d..161c2df6567e 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -307,12 +307,7 @@ else
 KBUILD_IMAGE := $(boot)/zImage
 endif

-# Build the DT binary blobs if we have OF configured
-ifeq ($(CONFIG_USE_OF),y)
-KBUILD_DTBS := dtbs
-endif
-
-all:   $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
+all:   $(notdir $(KBUILD_IMAGE))


 archheaders:
@@ -339,17 +334,6 @@ $(BOOT_TARGETS): vmlinux
 $(INSTALL_TARGETS):
$(Q)$(M

[PATCH v2 0/9] Devicetree build consolidation

2018-09-05 Thread Rob Herring
This series addresses a couple of issues I have with building dts files.

First, the ability to build all the dts files in the tree. This has been
supported on most arches for some time with powerpc being the main
exception. The reason powerpc wasn't supported was it needed a change
in the location built dtb files are put.

Secondly, it's a pain to acquire all the cross-compilers needed to build
dtbs for each arch. There's no reason to build with the cross compiler and
the host compiler is perfectly fine as we only need the pre-processor.

I started addressing just those 2 problems, but kept finding small
differences such as target dependencies and dtbs_install support across
architectures. Instead of trying to align all these, I've consolidated the
build targets moving them out of the arch makefiles.

I'd like to take the series via the DT tree.

Rob

v2:
 - Fix $arch/boot/dts path check for out of tree builds
 - Fix dtc dependency for building built-in dtbs
 - Fix microblaze built-in dtb building
 - Add dtbs target for microblaze

Rob Herring (9):
  powerpc: build .dtb files in dts directory
  nios2: build .dtb files in dts directory
  nios2: use common rules to build built-in dtb
  nios2: fix building all dtbs
  c6x: use common built-in dtb support
  kbuild: consolidate Devicetree dtb build rules
  powerpc: enable building all dtbs
  c6x: enable building all dtbs
  microblaze: enable building all dtbs

 Makefile   | 32 +++
 arch/arc/Makefile  |  6 
 arch/arm/Makefile  | 20 +---
 arch/arm64/Makefile| 17 +--
 arch/c6x/Makefile  |  2 --
 arch/c6x/boot/dts/Makefile | 17 +--
 arch/c6x/boot/dts/linked_dtb.S |  2 --
 arch/c6x/include/asm/sections.h|  1 -
 arch/c6x/kernel/setup.c|  4 +--
 arch/c6x/kernel/vmlinux.lds.S  | 10 --
 arch/h8300/Makefile| 11 +--
 arch/microblaze/Makefile   |  4 +--
 arch/microblaze/boot/dts/Makefile  |  4 +++
 arch/mips/Makefile | 15 +
 arch/nds32/Makefile|  2 +-
 arch/nios2/Makefile| 11 +--
 arch/nios2/boot/Makefile   | 22 --
 arch/nios2/boot/dts/Makefile   |  6 
 arch/nios2/boot/linked_dtb.S   | 19 
 arch/powerpc/Makefile  |  3 --
 arch/powerpc/boot/Makefile | 49 ++
 arch/powerpc/boot/dts/Makefile |  6 
 arch/powerpc/boot/dts/fsl/Makefile |  4 +++
 arch/xtensa/Makefile   | 12 +---
 scripts/Makefile.lib   |  2 +-
 25 files changed, 93 insertions(+), 188 deletions(-)
 delete mode 100644 arch/c6x/boot/dts/linked_dtb.S
 create mode 100644 arch/nios2/boot/dts/Makefile
 delete mode 100644 arch/nios2/boot/linked_dtb.S
 create mode 100644 arch/powerpc/boot/dts/Makefile
 create mode 100644 arch/powerpc/boot/dts/fsl/Makefile

--
2.17.1

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys GPIO via CREG bindings

2018-08-28 Thread Rob Herring
On Tue, Aug 28, 2018 at 02:27:21PM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> GPIO via CREG driver.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  .../devicetree/bindings/gpio/snps,creg-gpio.txt| 49 
> ++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt 
> b/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> new file mode 100644
> index ..eb022d44ccda
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> @@ -0,0 +1,49 @@
> +GPIO via CREG (Control REGisers) driver

REGisters?

Bindings don't describe drivers.

> +
> +This is is single-register MMIO GPIO driver to control such strangely mapped 
> +outputs:
> +
> +31118 75 0   < bit number
> +|  || || |
> +[   not used   | gpio-1 | shift-1 | gpio-0 | shift-0 ]   < 32 bit MMIO 
> register
> +   ^  ^
> +   |  |
> +   |   write 0x2 == set output to "1" (on)
> +   |   write 0x3 == set output to "0" (off)
> +   |
> +write 0x1 == set output to "1" (on)
> +write 0x4 == set output to "0" (off)

What kind of crazy h/w designer designed this?

> +Required properties:
> +- compatible : "snps,creg-gpio"
> +- reg : Exactly one register range with length 0x4.
> +- #gpio-cells : Should be one - the pin number.
> +- gpio-controller : Marks the device node as a GPIO controller.
> +- snps,ngpios: Number of GPIO pins.
> +- snps,bit-per-line: Number of bits per each gpio line (see picture).
> +  Array the size of "snps,ngpios"
> +- snps,shift: Shift (in bits) of the each GPIO field from the previous one in
> +  register (see picture). Array the size of "snps,ngpios"
> +- snps,on-val: Value should be set in corresponding field to set
> +  output to "1" (see picture). Array the size of "snps,ngpios"
> +- snps,off-val: Value should be set in corresponding field to set
> +  output to "0" (see picture). Array the size of "snps,ngpios"

Convince me we need to parameterize all this. We try to avoid describing 
h/w like this.

> +
> +Optional properties:
> +- snps,default-val: default output field values. Array the size of 
> "snps,ngpios"
> +
> +Example (see picture):
> +
> +gpio: gpio@f00014b0 {
> + compatible = "snps,creg-gpio";
> + reg = <0xf00014b0 0x4>;
> + gpio-controller;
> + #gpio-cells = <1>;
> + snps,ngpios = <2>;
> + snps,shift = <5 1>;
> + snps,bit-per-line = <2 3>;
> + snps,on-val = <2 1>;
> + snps,off-val = <3 4>;
> + snps,default-val = <2 1>;
> +};
> -- 
> 2.14.4
> 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 6/8] kbuild: consolidate Devicetree dtb build rules

2018-08-26 Thread Rob Herring
On Sat, Aug 25, 2018 at 9:06 PM Masahiro Yamada
 wrote:
>
> Hi Rob,
>
>
> 2018-08-22 6:55 GMT+09:00 Rob Herring :
> > There is nothing arch specific about building dtb files other than their
> > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
> > The dependencies and supported targets are all slightly different.
> > Also, a cross-compiler for each arch is needed, but really the host
> > compiler preprocessor is perfectly fine for building dtbs. Move the
> > build rules to a common location and remove the arch specific ones. This
> > is done in a single step to avoid warnings about overriding rules.
> >
> > The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
> > These pull in several dependencies some of which need a target compiler
> > (specifically devicetable-offsets.h) and aren't needed to build dtbs.
> > All that is really needed is dtc, so adjust the dependencies to only be
> > dtc.
> >
> > This change enables support 'dtbs_install' on some arches which were
> > missing the target.
> >
> > Cc: Masahiro Yamada 
> > Cc: Michal Marek 
> > Cc: Vineet Gupta 
> > Cc: Russell King 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Yoshinori Sato 
> > Cc: Michal Simek 
> > Cc: Ralf Baechle 
> > Cc: Paul Burton 
> > Cc: James Hogan 
> > Cc: Ley Foon Tan 
> > Cc: Benjamin Herrenschmidt 
> > Cc: Paul Mackerras 
> > Cc: Michael Ellerman 
> > Cc: Chris Zankel 
> > Cc: Max Filippov 
> > Cc: linux-kbu...@vger.kernel.org
> > Cc: linux-snps-arc@lists.infradead.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: uclinux-h8-de...@lists.sourceforge.jp
> > Cc: linux-m...@linux-mips.org
> > Cc: nios2-...@lists.rocketboards.org
> > Cc: linuxppc-...@lists.ozlabs.org
> > Cc: linux-xte...@linux-xtensa.org
> > Signed-off-by: Rob Herring 
> > ---
> >  Makefile | 30 ++
> >  arch/arc/Makefile|  6 --
> >  arch/arm/Makefile| 20 +---
> >  arch/arm64/Makefile  | 17 +
> >  arch/c6x/Makefile|  2 --
> >  arch/h8300/Makefile  | 11 +--
> >  arch/microblaze/Makefile |  4 +---
> >  arch/mips/Makefile   | 15 +--
> >  arch/nds32/Makefile  |  2 +-
> >  arch/nios2/Makefile  |  7 ---
> >  arch/nios2/boot/Makefile |  4 
> >  arch/powerpc/Makefile|  3 ---
> >  arch/xtensa/Makefile | 12 +---
> >  scripts/Makefile |  1 -
> >  scripts/Makefile.lib |  2 +-
> >  15 files changed, 38 insertions(+), 98 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index c13f8b85ba60..6d89e673f192 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1212,6 +1212,30 @@ kselftest-merge:
> > $(srctree)/tools/testing/selftests/*/config
> > +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig
> >
> > +# 
> > ---
> > +# Devicetree files
> > +
> > +dtstree := $(wildcard arch/$(SRCARCH)/boot/dts)

BTW, there's an error here too. It doesn't work right with
KBUILD_OUTPUT set and should be:

ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
dtstree := arch/$(SRCARCH)/boot/dts
endif

> > +
> > +ifdef CONFIG_OF_EARLY_FLATTREE
> > +
> > +%.dtb %.dtb.S %.dtb.o: | dtc
>
> I think the pipe operator is unnecessary
> because Kbuild will descend to $(dtstree) anyway.

The pipe means 'order-only', right? So it is just a weaker dependency
for things which are not input files as dtc is not. The 'dtc' here is
just the dtc rule below, not the actual executable. Or am I missing
something?

> > +   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
> > +
> > +PHONY += dtbs
> > +dtbs: | dtc
>
> Ditto.
>
>
> > +   $(Q)$(MAKE) $(build)=$(dtstree)
> > +
> > +dtbs_install: dtbs
> > +   $(Q)$(MAKE) $(dtbinst)=$(dtstree)
> > +
> > +all: dtbs
> > +
> > +dtc:
> > +   $(Q)$(MAKE) $(build)=scripts/dtc
> > +
> > +endif
> > +
>
>
> arch/*/boot/dts/ are not only directories that
> require dtc.

Ah yes, of course...

> > diff --git a/scripts/Makefile b/scripts/Makefile
> > index 61affa300d25..a716a6b10954 100644
> > --- a/scripts/Makefile
> > +++ b/scripts/Makefile
> > @@ -39,7 +39,6 @@ build_unifdef: $(obj)/unifdef
> >  subdir-$(CONFIG_MODVERSIONS) += genksyms
> >  subdir-y += mod
> >  subdir-$(CONFIG_SECURITY_SELINUX) += selinux
> > -subdir-$(CONFIG_DTC) += dtc
> >  subdir-$(CONFIG_GDB_SCRIPTS) += gdb
> >
> >  # Let clean descend into subdirs

Looks like I need to leave this line to fix the above and cleaning.

Thanks for the review.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


[PATCH 6/8] kbuild: consolidate Devicetree dtb build rules

2018-08-21 Thread Rob Herring
There is nothing arch specific about building dtb files other than their
location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
The dependencies and supported targets are all slightly different.
Also, a cross-compiler for each arch is needed, but really the host
compiler preprocessor is perfectly fine for building dtbs. Move the
build rules to a common location and remove the arch specific ones. This
is done in a single step to avoid warnings about overriding rules.

The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
These pull in several dependencies some of which need a target compiler
(specifically devicetable-offsets.h) and aren't needed to build dtbs.
All that is really needed is dtc, so adjust the dependencies to only be
dtc.

This change enables support 'dtbs_install' on some arches which were
missing the target.

Cc: Masahiro Yamada 
Cc: Michal Marek 
Cc: Vineet Gupta 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Yoshinori Sato 
Cc: Michal Simek 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Ley Foon Tan 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: linux-kbu...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: linux-m...@linux-mips.org
Cc: nios2-...@lists.rocketboards.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-xte...@linux-xtensa.org
Signed-off-by: Rob Herring 
---
 Makefile | 30 ++
 arch/arc/Makefile|  6 --
 arch/arm/Makefile| 20 +---
 arch/arm64/Makefile  | 17 +
 arch/c6x/Makefile|  2 --
 arch/h8300/Makefile  | 11 +--
 arch/microblaze/Makefile |  4 +---
 arch/mips/Makefile   | 15 +--
 arch/nds32/Makefile  |  2 +-
 arch/nios2/Makefile  |  7 ---
 arch/nios2/boot/Makefile |  4 
 arch/powerpc/Makefile|  3 ---
 arch/xtensa/Makefile | 12 +---
 scripts/Makefile |  1 -
 scripts/Makefile.lib |  2 +-
 15 files changed, 38 insertions(+), 98 deletions(-)

diff --git a/Makefile b/Makefile
index c13f8b85ba60..6d89e673f192 100644
--- a/Makefile
+++ b/Makefile
@@ -1212,6 +1212,30 @@ kselftest-merge:
$(srctree)/tools/testing/selftests/*/config
+$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig
 
+# ---
+# Devicetree files
+
+dtstree := $(wildcard arch/$(SRCARCH)/boot/dts)
+
+ifdef CONFIG_OF_EARLY_FLATTREE
+
+%.dtb %.dtb.S %.dtb.o: | dtc
+   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
+
+PHONY += dtbs
+dtbs: | dtc
+   $(Q)$(MAKE) $(build)=$(dtstree)
+
+dtbs_install: dtbs
+   $(Q)$(MAKE) $(dtbinst)=$(dtstree)
+
+all: dtbs
+
+dtc:
+   $(Q)$(MAKE) $(build)=scripts/dtc
+
+endif
+
 # ---
 # Modules
 
@@ -1425,6 +1449,12 @@ help:
@echo  '  kselftest-merge - Merge all the config dependencies of 
kselftest to existing'
@echo  '.config.'
@echo  ''
+   @$(if $(dtstree), \
+   echo 'Devicetree:'; \
+   echo '* dtbs- Build device tree blobs for enabled 
boards'; \
+   echo '  dtbs_install- Install dtbs to 
$(INSTALL_DTBS_PATH)'; \
+   echo '')
+
@echo 'Userspace tools targets:'
@echo '  use "make tools/help"'
@echo '  or  "cd tools; make help"'
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 6c1b20dd76ad..cbfb7a16b570 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -132,11 +132,5 @@ boot_targets += uImage uImage.bin uImage.gz
 $(boot_targets): vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
-%.dtb %.dtb.S %.dtb.o: scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@
-
-dtbs: scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts
-
 archclean:
$(Q)$(MAKE) $(clean)=$(boot)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e7d703d8fac3..7f02ef8dfdb2 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -308,12 +308,7 @@ else
 KBUILD_IMAGE := $(boot)/zImage
 endif
 
-# Build the DT binary blobs if we have OF configured
-ifeq ($(CONFIG_USE_OF),y)
-KBUILD_DTBS := dtbs
-endif
-
-all:   $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
+all:   $(notdir $(KBUILD_IMAGE))
 
 
 archheaders:
@@ -340,17 +335,6 @@ $(BOOT_TARGETS): vmlinux
 $(INSTALL_TARGETS):
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
 
-%.dtb: | scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@
-
-PHONY += dtbs dtbs_install
-
-dtbs: prepare scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts
-
-dtbs_install:
-   $(Q)$(MAKE) $(dtbinst)=$(boot)/dts
-
 PHONY += vdso_install
 vdso_install:
 ifeq ($(CONFIG_VDSO),y)
@@ -372,8 +356,6 @@ define archhel

[PATCH 0/8] Devicetree build consolidation

2018-08-21 Thread Rob Herring
This series addresses a couple of issues I have with building dts files.

First, the ability to build all the dts files in the tree. This has been
supported on most arches for some time with powerpc being the main
exception. The reason powerpc wasn't supported was it needed a change
in the location built dtb files are put.

Secondly, it's a pain to acquire all the cross-compilers needed to build
dtbs for each arch. There's no reason to build with the cross compiler and
the host compiler is perfectly fine as we only need the pre-processor.

I started addressing just those 2 problems, but kept finding small
differences such as target dependencies and dtbs_install support across
architectures. Instead of trying to align all these, I've consolidated the
build targets moving them out of the arch makefiles.

I'd like to take the series via the DT tree.

Rob

Rob Herring (8):
  powerpc: build .dtb files in dts directory
  nios2: build .dtb files in dts directory
  nios2: use common rules to build built-in dtb
  nios2: fix building all dtbs
  c6x: use common built-in dtb support
  kbuild: consolidate Devicetree dtb build rules
  powerpc: enable building all dtbs
  c6x: enable building all dtbs

 Makefile   | 30 ++
 arch/arc/Makefile  |  6 
 arch/arm/Makefile  | 20 +---
 arch/arm64/Makefile| 17 +--
 arch/c6x/Makefile  |  2 --
 arch/c6x/boot/dts/Makefile | 17 +--
 arch/c6x/boot/dts/linked_dtb.S |  2 --
 arch/c6x/include/asm/sections.h|  1 -
 arch/c6x/kernel/setup.c|  4 +--
 arch/c6x/kernel/vmlinux.lds.S  | 10 --
 arch/h8300/Makefile| 11 +--
 arch/microblaze/Makefile   |  4 +--
 arch/mips/Makefile | 15 +
 arch/nds32/Makefile|  2 +-
 arch/nios2/Makefile| 11 +--
 arch/nios2/boot/Makefile   | 22 --
 arch/nios2/boot/dts/Makefile   |  6 
 arch/nios2/boot/linked_dtb.S   | 19 
 arch/powerpc/Makefile  |  3 --
 arch/powerpc/boot/Makefile | 49 ++
 arch/powerpc/boot/dts/Makefile |  6 
 arch/powerpc/boot/dts/fsl/Makefile |  4 +++
 arch/xtensa/Makefile   | 12 +---
 scripts/Makefile   |  1 -
 scripts/Makefile.lib   |  2 +-
 25 files changed, 87 insertions(+), 189 deletions(-)
 delete mode 100644 arch/c6x/boot/dts/linked_dtb.S
 create mode 100644 arch/nios2/boot/dts/Makefile
 delete mode 100644 arch/nios2/boot/linked_dtb.S
 create mode 100644 arch/powerpc/boot/dts/Makefile
 create mode 100644 arch/powerpc/boot/dts/fsl/Makefile

--
2.17.1

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys DW AXI DMA bindings

2018-03-05 Thread Rob Herring
On Mon, Mar 05, 2018 at 11:02:56AM +0530, Vinod Koul wrote:
> On Fri, Mar 02, 2018 at 08:32:20AM +, Alexey Brodkin wrote:
> > Hi Vinod,
> > 
> > On Fri, 2018-03-02 at 13:44 +0530, Vinod Koul wrote:
> > > On Mon, Feb 26, 2018 at 05:56:28PM +0300, Eugeniy Paltsev wrote:
> > > > This patch adds documentation of device tree bindings for the Synopsys
> > > > DesignWare AXI DMA controller.
> > > > 
> > > > Signed-off-by: Eugeniy Paltsev 
> > > > ---
> > > >  .../devicetree/bindings/dma/snps,dw-axi-dmac.txt   | 41 
> > > > ++
> > > >  1 file changed, 41 insertions(+)
> > > >  create mode 100644 
> > > > Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt 
> > > > b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > > new file mode 100644
> > > > index 000..f237b79
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > > @@ -0,0 +1,41 @@
> > > > +Synopsys DesignWare AXI DMA Controller
> > > > +
> > > > +Required properties:
> > > > +- compatible: "snps,axi-dma-1.01a"
> > > > +- reg: Address range of the DMAC registers. This should include
> > > > +  all of the per-channel registers.
> > > > +- interrupt: Should contain the DMAC interrupt number.
> > > > +- interrupt-parent: Should be the phandle for the interrupt controller
> > > > +  that services interrupts for this device.
> > > > +- dma-channels: Number of channels supported by hardware.
> > > > +- snps,dma-masters: Number of AXI masters supported by the hardware.
> > > > +- snps,data-width: Maximum AXI data width supported by hardware.
> > > > +  (0 - 8bits, 1 - 16bits, 2 - 32bits, ..., 6 - 512bits)
> > > > +- snps,priority: Priority of channel. Array size is equal to the 
> > > > number of
> > > > +  dma-channels. Priority value must be programmed within 
> > > > [0:dma-channels-1]
> > > > +  range. (0 - minimum priority)
> > > > +- snps,block-size: Maximum block size supported by the controller 
> > > > channel.
> > > > +  Array size is equal to the number of dma-channels.
> > > > +
> > > > +Optional properties:
> > > > +- snps,axi-max-burst-len: Restrict master AXI burst length by value 
> > > > specified
> > > > +  in this property. If this property is missing the maximum AXI burst 
> > > > length
> > > > +  supported by DMAC is used. [1:256]
> > > > +
> > > > +Example:
> > > > +
> > > > +dmac: dma-controller@8 {
> > > > +   compatible = "snps,axi-dma-1.01a";
> > > 
> > > do we need "snps here..?
> > 
> > Synopsys is this IP-block vendor so shouldn't we put it that way?
> 
> Not a DT expert but why should vendor name come here, you can read the
> properties from device node, vendor name seems redundant to me

I don't follow...

In any case, yes, it must have a vendor prefix. It should also have a 
compatible for the vendor(s) that integrate the block because they all 
break it in different ways. Speaking of which, we already have 
snps-dma.txt and at least Analog Devices binding using a Synopsys DMA. 
What's the difference?

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] arc: dts: Remove leading 0x and 0s from bindings notation

2017-12-14 Thread Rob Herring
On Thu, Dec 14, 2017 at 10:53 AM, Mathieu Malaterre <ma...@debian.org> wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 
> "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e 
> "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 
> \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings 
> separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x 
> from bindings notation")
>
> Reported-by: David Daney <dda...@caviumnetworks.com>
> Suggested-by: Rob Herring <r...@kernel.org>
> Signed-off-by: Mathieu Malaterre <ma...@debian.org>
> ---

For the series,

Reviewed-by: Rob Herring <r...@kernel.org>

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: Setting CPU clock frequency on early boot

2017-09-06 Thread Rob Herring
On Wed, Sep 6, 2017 at 11:22 AM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> Hi Rob,
>
> On Wed, 2017-09-06 at 10:25 -0500, Rob Herring wrote:
>> On Wed, Sep 6, 2017 at 8:51 AM, Alexey Brodkin
>> <alexey.brod...@synopsys.com> wrote:
>> >
>> > Hi Vineet, Rob,
>> >
>> > On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote:
>> > >
>> > > On 09/05/2017 03:04 PM, Rob Herring wrote:
>> > > >
>> > > >
>> > > > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin
>> > > > <alexey.brod...@synopsys.com> wrote:
>
> [snip]
>
>> > Yeah, that's an interesting question. We may indeed move more smarts to 
>> > the clock driver
>> > but:
>> >  1. We'll have duplicate code in different clock drivers. Even today that 
>> > kind of clock
>> > setup is applicable to AXS10x and HSDK platforms (and they use 
>> > different clock drivers).
>>
>> No, you could provide a common, shared function to call. Then each
>> platform can opt-in. If you can make something that applies to every
>> single platform now or in the future, then I'd put it in arch. If you
>> have plans to decouple the timer and cpu clocks, then sounds like you
>> can't.
>
> Right so we'll implement a function which is called by a platform if required.
> That way we escape copy-pasting while keeping enough flexibility for current
> and future platforms.
>
>> IMO, if it's not part of the defined CPU architecture, then don't put
>> it in arch/. That's how we end up with multiple copies of the same
>> thing done arbitrarily different ways because few people look across
>> architectures.
>
> So do you propose to have the function [that reads "clock-frequency" from say
> CPU node and passes its value to CPU's parent clock driver] in generic
> [i.e. architecture agnostic] code somewhere in "init/main.c"?

No, just like you said above and have the platform's clock driver
initialize frequencies.

I haven't seen anyone else want such a thing as generally the
bootloader should initialize things to something reasonable.

>> >  2. Print out of CPU frequency which is used during boot process for us is 
>> > important as well
>> > especially during bring-up of new HW.
>> >
>> >  3. If there's no dedicated "clock-frequency" parameter in CPU node we 
>> > won't
>> > change anything so that non-affected platforms will live as they used 
>> > to.
>> >
>> > That said IMHO proposed implementation is what we want to kep for now.
>> >
>> > >
>> > > Also note that this code is using a new / adhoc DT binding cpu-freq in 
>> > > cou node to
>> > > do the override - is that acceptable ?
>>
>> No, I meant to point that out.
>
> Sorry, but for me it's not clear what did you mean here.
> Care to elaborate a bit more?

I noticed the same thing and meant to highlight that in my first
reply. Use clock-frequency, don't invent something new.

>> > I think we'll switch to more common "clock-frequency" in the next respin.
>> > Indeed "cpu-freq" might be a bit misleading.
>>
>> Ideally, you'd use the clock binding eventually.
>
> Again I'm probably missing something :)

"clock-frequency" property and the clock bindings (i.e. clocks =
<>) are generally mutually exclusive at least within clock
consumer side. There's the assigned-clocks binding which provides the
ability to set both parent clocks and frequency.

> I meant we will have both clock phandle and "clock-frequency" at the same 
> time.
> Something like this:
> >8---
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> cpu@0 {
> device_type = "cpu";
> compatible = "snps,archs38";
> reg = <0>;
> clocks = <_clk>;
> clock-frequency = <1>;  <-- That's where we 
> want to set desired value
> };
> ...
> }
>
> core_clk: core-clk@80 {
> compatible = "snps,axs10x-arc-pll-clock";
> reg = <0x80 0x10>, <0x100 0x10>;
> #clock-cells = <0>;
> clocks = <_clk>;
> };
> >8---
>
> Or alternatively we may move "clock-frequency" right to the clock's node and 
> have
> it like that:
> >8---
> core_clk: core-clk@80 {
> compatible = "snps,axs10x-arc-pll-clock";
> reg = <0x80 0x10>, <0x100 0x10>;
>
> #clock-cells = <0>;
> clocks = <_clk>;
> clock-frequency = <1>;  <-- That's where we want to 
> set desired value

I think this is how it should be done if you use clock-frequency prop.
This is inline with how fixed-clock binding is done.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: Setting CPU clock frequency on early boot

2017-09-06 Thread Rob Herring
On Wed, Sep 6, 2017 at 8:51 AM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> Hi Vineet, Rob,
>
> On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote:
>> On 09/05/2017 03:04 PM, Rob Herring wrote:
>> >
>> > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin
>> > <alexey.brod...@synopsys.com> wrote:
>> > >
>> > > Hello,
>> > >
>> > > I'd like to get some feedback on our idea as well as check
>> > > if somebody faces similar situations and if so what would be the best
>> > > way to implement some generic solution that suits everyone.
>> > >
>> > > So that's our problem:
>> > > 1. On power-on hardware might start clocking CPU with either
>> > > too high frequency (such that CPU may get stuck at some point)
>> > > or too low frequency.
>> > >
>> > > That all sounds stupid but let me elaborate a bit here.
>> > > I'm talking about FPGA-based devboards firmware for which
>> > > (here I mean just image loaded in FPGA with CPU implementation
>> > > but not some software yet) might not be stable or be even 
>> > > experimental.
>> > >
>> > > For example we may deal with dual-core or quad-core designs.
>> > > Former might be OK running @100MHz and latter is only usable
>> > > @75MHz and lower. The simplest solution might be to use some safe
>> > > value before something like CPUfreq kicks in. But we don't yet have
>> > > CPUfreq for ARC (we do plan to get it working sometime soon)
>>
>> But even if we had cpufreq driver going - I don't think it would be usable 
>> for
>> doing large freq switches, since in current implementations of SoCs (or 
>> fpga), the
>> clk/pll etc driving core (and all timers etc) are not fixed like say ARM. 
>> And as
>> discussed before (and pointed to by tglx), timer subsys can't tolerate (on
>> purpose) such large drifts.
>
> Essentially cpufreq only makes sense for "compatible" systems and 
> unfortunately
> most of our current boards are not capable due to missing constant [decoupled 
> from
> CPU frequency] clock source. But looking forward we are planning to improve 
> on that
> so that hopefully even our FPGA-based boards will be usable with cpufreq.
>
>> > > which
>> > > means simple change of CPU frequency once time-keeping infrastructure
>> > > was brought-up is not an option... I.e. we'll end up with the system 
>> > > running
>> > > much slower compared what could have been possible.
>> > >
>> > > 2. Up until now we used to do dirty hacks in early platform init code.
>> > > Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c):
>> > >  1) Read CPU's "clock-frequency" from .dtb (remember we're on very 
>> > > early
>> > > boot stage still so no expanded DevTree yet exists).
>> > >  2) Check how many cores we have and which freq is usable
>> > >  3) Update PLL settings right in place if new freq != existing in 
>> > > PLL.
>> > >
>> > > Even though it is proven to work but with more platforms in the 
>> > > pipeline
>> > > we'll need to copy-paste pretty much the same stuff across all 
>> > > affected
>> > > plats. Which is not nice.
>> > >
>> > > Moreover back in the day we didn't have a proper clk driver for 
>> > > CPU's PLL.
>> > > Thus acting on PLL registers right in place was the only thing we 
>> > > were able
>> > > to do. Now with introduction of normal clk driver
>> > > (see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to 
>> > > utilize
>> > > it and have a cleaner and more universal solution to the problem.
>> > >
>> > > That's how it could be done - 
>> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_=DwICAg=DPL6_X_6JkXF
>> > > x7AXWqB0tg=c14YS-cH-
>> > > kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs=wuUcceY8Cz5EhVklWLAgj7RzU3rvpanujvQ3qTJK0Gw=N5IBjq_eCyOf_GRkZskzqGhczBPTbxLJW_MUfauKvuA=
>> > > Basically in architecture's time_init() we check if there's 
>> > > explicitly
>> > > specified "clock-frequency" parameter in cpu's node in Device Tree 
>> > > and
>> > > if there's one we set it v

Re: Setting CPU clock frequency on early boot

2017-09-05 Thread Rob Herring
On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin
 wrote:
> Hello,
>
> I'd like to get some feedback on our idea as well as check
> if somebody faces similar situations and if so what would be the best
> way to implement some generic solution that suits everyone.
>
> So that's our problem:
> 1. On power-on hardware might start clocking CPU with either
>too high frequency (such that CPU may get stuck at some point)
>or too low frequency.
>
>That all sounds stupid but let me elaborate a bit here.
>I'm talking about FPGA-based devboards firmware for which
>(here I mean just image loaded in FPGA with CPU implementation
>but not some software yet) might not be stable or be even experimental.
>
>For example we may deal with dual-core or quad-core designs.
>Former might be OK running @100MHz and latter is only usable
>@75MHz and lower. The simplest solution might be to use some safe
>value before something like CPUfreq kicks in. But we don't yet have
>CPUfreq for ARC (we do plan to get it working sometime soon) which
>means simple change of CPU frequency once time-keeping infrastructure
>was brought-up is not an option... I.e. we'll end up with the system 
> running
>much slower compared what could have been possible.
>
> 2. Up until now we used to do dirty hacks in early platform init code.
>Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c):
> 1) Read CPU's "clock-frequency" from .dtb (remember we're on very early
>boot stage still so no expanded DevTree yet exists).
> 2) Check how many cores we have and which freq is usable
> 3) Update PLL settings right in place if new freq != existing in PLL.
>
>Even though it is proven to work but with more platforms in the pipeline
>we'll need to copy-paste pretty much the same stuff across all affected
>plats. Which is not nice.
>
>Moreover back in the day we didn't have a proper clk driver for CPU's PLL.
>Thus acting on PLL registers right in place was the only thing we were able
>to do. Now with introduction of normal clk driver
>(see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize
>it and have a cleaner and more universal solution to the problem.
>
>That's how it could be done - http://patchwork.ozlabs.org/patch/801240/
>Basically in architecture's time_init() we check if there's explicitly
>specified "clock-frequency" parameter in cpu's node in Device Tree and
>if there's one we set it via just instantiated clk driver.

The patch looks generally okay. I'd move all the logic to the clock
driver unless perhaps how to set the cpu freq is defined by the
architecture.

> We may indeed proceed with mentioned solution for ARC but if that makes
> sense for somebody else it might worth getting something similar in generic
> init code. Any thoughts?

If any ARM platforms are doing something similar, then it's done in
their clock driver via of_clk_init. Or they just wait for cpufreq to
kick in and expect the bootloader has initialized things to a
reasonable frequency.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2] OF: move extern declarations of of_stdout inside ifdef

2017-08-25 Thread Rob Herring
On Fri, Aug 25, 2017 at 11:56 AM, Eugeniy Paltsev
<eugeniy.palt...@synopsys.com> wrote:
> Move extern declarations of "of_stdout" pointer inside "CONFIG_OF"
> ifdef to be able to get rid of "CONFIG_OF" ifdef in its usage places.
>
> Suggested-by: Steven Rostedt <rost...@goodmis.org>
>
> Signed-off-by: Eugeniy Paltsev <eugeniy.palt...@synopsys.com>
> ---
> For example see: https://lkml.org/lkml/2017/8/25/337
>
> Changes v1->v2:
>  * Move only "of_stdout" declarations instead of all entry pointers
>declarations
>
>  include/linux/of.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Acked-by: Rob Herring <r...@kernel.org>

Merge this with the console change needing it.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] OF: move extern declarations of entry pointers inside ifdef

2017-08-25 Thread Rob Herring
On Fri, Aug 25, 2017 at 10:00 AM, Eugeniy Paltsev
 wrote:
> Move extern declarations of "of_root", "of_chosen", "of_aliases",
> "of_stdout" pointers inside "CONFIG_OF" ifdef to be able to get rid
> of "CONFIG_OF" ifdef in their usage places.
>
> Suggested-by: Steven Rostedt 
>
> Signed-off-by: Eugeniy Paltsev 
> ---
> For example see: https://lkml.org/lkml/2017/8/25/337
>
>  include/linux/of.h | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index cfc3411..d117bf1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -131,11 +131,6 @@ static inline struct device_node *of_node_get(struct 
> device_node *node)
>  static inline void of_node_put(struct device_node *node) { }
>  #endif /* !CONFIG_OF_DYNAMIC */
>
> -/* Pointer for first entry in chain of all nodes. */
> -extern struct device_node *of_root;
> -extern struct device_node *of_chosen;
> -extern struct device_node *of_aliases;
> -extern struct device_node *of_stdout;

Just move what you need. Some of these I'd like to see be internal to
the DT code.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] earlycon: initialise baud field of earlycon device structure

2017-08-16 Thread Rob Herring
On Wed, Aug 16, 2017 at 6:52 AM, Eugeniy Paltsev
<eugeniy.palt...@synopsys.com> wrote:
> Hi Rob,
>
> On Tue, 2017-08-15 at 14:26 -0500, Rob Herring wrote:
>> On Tue, Aug 15, 2017 at 12:21 PM, Eugeniy Paltsev
>> <eugeniy.palt...@synopsys.com> wrote:
>> > [snip]
>> > @@ -282,7 +283,15 @@ int __init of_setup_earlycon(const struct
>> > earlycon_id *match,
>> > }
>> > }
>> >
>> > +   val = of_get_flat_dt_prop(node, "baud", NULL);
>>
>> No, we already have a defined way to set the baud, we don't need a
>> property in addition. Plus you didn't document it.
>
> I guess by defined way to set the baud you mean setting baud after
> device alias
> in stdout-path property (like stdout-path = "serial:115200n8"), right?
>
> The idea was to reuse "baud" property from serial node to set the
> earlycon baud:
>
> chosen {
> ...
> stdout-path = 
> };
>
> serial: uart@... {
> ...
> baud = <115200>;   /* Get baud from here */

"current-speed" is already defined for this purpose. If you want to
add that, that's fine.

> };
>
>> > +   if (val)
>> > +   early_console_dev.baud = be32_to_cpu(*val);
>> > +
>> > if (options) {
>> > +   err = kstrtoul(options, 10, );
>> > +   if (!err)
>> > +   early_console_dev.baud = baud;
>>
>> This seems fine to do here, but then we should also parse the other
>> standard options here too. And we should make sure we're not doing it
>> twice.
> I added only baud parsing here because we parse only baud from standard
> options
> when register_earlycon is used. (see parse_options function which is
> called
> from register_earlycon)
>
> But I can add other standard options parsing here (probably using
> uart_parse_options + uart_set_options).
> What do you think?

That seems fine as long as consoles can still have their own options.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] earlycon: initialise baud field of earlycon device structure

2017-08-15 Thread Rob Herring
On Tue, Aug 15, 2017 at 12:21 PM, Eugeniy Paltsev
 wrote:
> For now baud field of earlycon structure device is't initialised at all
> in of_setup_earlycon (in oppositе to register_earlycon).
>
> So when I use stdout-path to point earlycon device
> (like stdout-path =  or stdout-path = "serial:115200n8")
> baud field of earlycon device structure remains uninitialised and
> earlycon initialization is not performed correctly as
> of_setup_earlycon is used.

Because the console driver is supposed to parse the option string.
That allows in theory for the options to be specific for each console.
Maybe your earlycon driver is failing to do that.

> When pass all arguments via bootargs
> (like bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8")
> initialization is performed correctly as register_earlycon is used.
>
> So initialise baud field of earlycon device structure by baud value
> from device tree or from options (if they exist) when we use
> of_setup_earlycon
>
> Signed-off-by: Eugeniy Paltsev 
> ---
>  drivers/tty/serial/earlycon.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index c365154..6c2e2b6 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -240,6 +240,7 @@ int __init of_setup_earlycon(const struct earlycon_id 
> *match,
>  {
> int err;
> struct uart_port *port = _console_dev.port;
> +   unsigned long baud;
> const __be32 *val;
> bool big_endian;
> u64 addr;
> @@ -282,7 +283,15 @@ int __init of_setup_earlycon(const struct earlycon_id 
> *match,
> }
> }
>
> +   val = of_get_flat_dt_prop(node, "baud", NULL);

No, we already have a defined way to set the baud, we don't need a
property in addition. Plus you didn't document it.

> +   if (val)
> +   early_console_dev.baud = be32_to_cpu(*val);
> +
> if (options) {
> +   err = kstrtoul(options, 10, );
> +   if (!err)
> +   early_console_dev.baud = baud;

This seems fine to do here, but then we should also parse the other
standard options here too. And we should make sure we're not doing it
twice.

> +
> strlcpy(early_console_dev.options, options,
> sizeof(early_console_dev.options));
> }
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer

2017-08-03 Thread Rob Herring
On Fri, Jul 28, 2017 at 03:07:03PM -0700, Alexandru Gagniuc wrote:
> Before the GMAC on the Anarion chip can be used, the PHY interface
> selection must be configured with the DWMAC block in reset.
> 
> This layer covers a block containing only two registers. Although it
> is possible to model this as a reset controller and use the "resets"
> property of stmmac, it's much more intuitive to include this in the
> glue layer instead.
> 
> At this time only RGMII is supported, because it is the only mode
> which has been validated hardware-wise.
> 
> Signed-off-by: Alexandru Gagniuc 
> ---
>  .../devicetree/bindings/net/anarion-gmac.txt   |  25 

The binding looks fine, but please split to separate patch.

>  drivers/net/ethernet/stmicro/stmmac/Kconfig|   9 ++
>  drivers/net/ethernet/stmicro/stmmac/Makefile   |   1 +
>  .../net/ethernet/stmicro/stmmac/dwmac-anarion.c| 151 
> +
>  4 files changed, 186 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/anarion-gmac.txt
>  create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 1/5] of: Add vendor prefix for Adaptrum, Inc.

2017-08-03 Thread Rob Herring
On Sat, Jul 29, 2017 at 04:48:28PM +0200, Andreas Färber wrote:
> Hi Alexandru,
> 
> Am 29.07.2017 um 00:07 schrieb Alexandru Gagniuc:
> > Signed-off-by: Alexandru Gagniuc 
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Not sure why I'm CC'ed here, but it looks sane, so
> 
> Reviewed-by: Andreas Färber 
> 
> If this patch gets respun, please add a sentence about your company to
> the commit message. I also think "dt-bindings:" is a more common prefix?

Please respin with the above and just send by itself. This can go 
separately as there's no need to merge via the same tree just in the 
name of satisfying checkpatch.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 3/3 v8] ARC: hsdk: initial port for HSDK board

2017-07-17 Thread Rob Herring
On Wed, Jul 12, 2017 at 12:40:23PM +0300, Eugeniy Paltsev wrote:
> From: Alexey Brodkin <abrod...@synopsys.com>
> 
> This initial port adds support of ARC HS Development Kit board with some
> basic features such serial port, USB, SD/MMC and Ethernet.
> 
> Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
> heavily use IO Coherency for speeding-up DMA-aware peripherals.
> 
> Note as opposed to other ARC boards we link Linux kernel to
> 0x9000_ intentionally because cores 1 and 3 configured with DCCM
> situated at our more usual link base 0x8000_. We still can use
> memory region starting at 0x8000_ as we reallocate DCCM in our
> platform code.
> 
> Note that PAE remapping for DMA clients does not work due to an RTL bug,
> so CREG_PAE register must be programmed to all zeroes, otherwise it will
> cause problems with DMA to/from peripherals even if PAE40 is not used.
> 
> Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> Signed-off-by: Eugeniy Paltsev <eugeniy.palt...@synopsys.com>
> ---
> Changes v7 -> v8:
>  * DTS: move cpu_intc, idu_intc, arcpct, timer, gfrc nodes to root
>level and out of the cpus node.
>  * DTS: add vendor-specific compatible for ohci and ehci nodes.
>  * DTS: style fixes

Acked-by: Rob Herring <r...@kernel.org>

> + ohci@6 {
> + compatible = "snps,hsdk-v1.0-ohci", "generic-ohci";
> + reg = <0x6 0x100>;
> + interrupts = <15>;
> + };
> +
> + ehci@4 {
> + compatible = "snps,hsdk-v1.0-ehci", "generic-ehci";
> + reg = <0x4 0x100>;
> + interrupts = <15>;
> + };

Of course, now these compatibles need to be documented. You can do that 
in a separate follow-up patch.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 3/3 v7] ARC: hsdk: initial port for HSDK board

2017-07-09 Thread Rob Herring
On Mon, Jul 03, 2017 at 07:51:09PM +0300, Eugeniy Paltsev wrote:
> From: Alexey Brodkin 
> 
> This initial port adds support of ARC HS Development Kit board with some
> basic features such serial port, USB, SD/MMC and Ethernet.
> 
> Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
> heavily use IO Coherency for speeding-up DMA-aware peripherals.
> 
> Note as opposed to other ARC boards we link Linux kernel to
> 0x9000_ intentionally because cores 1 and 3 configured with DCCM
> situated at our more usual link base 0x8000_. We still can use
> memory region starting at 0x8000_ as we reallocate DCCM in our
> platform code.
> 
> Note that PAE remapping for DMA clients does not work due to an RTL bug,
> so CREG_PAE register must be programmed to all zeroes, otherwise it will
> cause problems with DMA to/from peripherals even if PAE40 is not used.
> 
> Signed-off-by: Alexey Brodkin 
> Signed-off-by: Eugeniy Paltsev 
> ---
> Changes v6 -> v7:
>  * DTS: get rid of skeleton.dts, move cpus nodes to hsdk.dts
>  * DTS: style fixes
>  * Enable loadable modules, module unloading and NFS client as defaults
>  * Get rid of ARC_PLAT_HSDK board config option
> 
>  Documentation/devicetree/bindings/arc/hsdk.txt |   7 +
>  arch/arc/Makefile  |   1 +
>  arch/arc/boot/dts/hsdk.dts | 189 
> +
>  arch/arc/configs/hsdk_defconfig|  78 ++
>  arch/arc/kernel/devtree.c  |   5 +-
>  arch/arc/plat-hsdk/Makefile|   9 ++
>  arch/arc/plat-hsdk/platform.c  |  79 +++
>  7 files changed, 366 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arc/hsdk.txt
>  create mode 100644 arch/arc/boot/dts/hsdk.dts
>  create mode 100644 arch/arc/configs/hsdk_defconfig
>  create mode 100644 arch/arc/plat-hsdk/Makefile
>  create mode 100644 arch/arc/plat-hsdk/platform.c
> 
> diff --git a/Documentation/devicetree/bindings/arc/hsdk.txt 
> b/Documentation/devicetree/bindings/arc/hsdk.txt
> new file mode 100644
> index 000..be50654
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arc/hsdk.txt
> @@ -0,0 +1,7 @@
> +Synopsys DesignWare ARC HS Development Kit Device Tree Bindings
> +---
> +
> +ARC HSDK Board with quad-core ARC HS38x4 in silicon.
> +
> +Required root node properties:
> +- compatible = "snps,hsdk";
> diff --git a/arch/arc/Makefile b/arch/arc/Makefile
> index 44ef35d..e67397e 100644
> --- a/arch/arc/Makefile
> +++ b/arch/arc/Makefile
> @@ -111,6 +111,7 @@ core-$(CONFIG_ARC_PLAT_SIM)   += arch/arc/plat-sim/
>  core-$(CONFIG_ARC_PLAT_TB10X)+= arch/arc/plat-tb10x/
>  core-$(CONFIG_ARC_PLAT_AXS10X)   += arch/arc/plat-axs10x/
>  core-$(CONFIG_ARC_PLAT_EZNPS)+= arch/arc/plat-eznps/
> +core-y   += arch/arc/plat-hsdk/
>  
>  ifdef CONFIG_ARC_PLAT_EZNPS
>  KBUILD_CPPFLAGS += -I$(srctree)/arch/arc/plat-eznps/include
> diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
> new file mode 100644
> index 000..33872f1
> --- /dev/null
> +++ b/arch/arc/boot/dts/hsdk.dts
> @@ -0,0 +1,189 @@
> +/*
> + * Copyright (C) 2017 Synopsys, Inc. (www.synopsys.com)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/*
> + * Device Tree for ARC HS Development Kit
> + */
> +/dts-v1/;
> +
> +#include 
> +
> +/ {
> + model = "snps,hsdk";
> + compatible = "snps,hsdk";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + chosen {
> + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8 
> console=ttyS0,115200n8 debug print-fatal-signals=1";
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "snps,archs38";
> + reg = <0>;
> + clocks = <_clk>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "snps,archs38";
> + reg = <1>;
> + clocks = <_clk>;
> + };
> +
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "snps,archs38";
> + reg = <2>;
> + clocks = <_clk>;
> + };
> +
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "snps,archs38";
> + reg = <3>;
> + clocks = <_clk>;
> + };
> +

Move all 

Re: [PATCH 3/3 v6] ARC: hsdk: initial port for HSDK board

2017-06-26 Thread Rob Herring
On Mon, Jun 26, 2017 at 10:11 AM, Eugeniy Paltsev
 wrote:
> From: Alexey Brodkin 
>
> This initial port adds support of ARC HS Development Kit board with some
> basic features such serial port, USB, SD/MMC and Ethernet.
>
> Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
> heavily use IO Coherency for speeding-up DMA-aware peripherals.
>
> Note as opposed to other ARC boards we link Linux kernel to
> 0x9000_ intentionally because cores 1 and 3 configured with DCCM
> situated at our more usual link base 0x8000_. We still can use
> memory region starting at 0x8000_ as we reallocate DCCM in our
> platform code.
>
> Note that PAE remapping for DMA clients does not work due to an RTL bug,
> so CREG_PAE register must be programmed to all zeroes, otherwise it will
> cause problems with DMA to/from peripherals even if PAE40 is not used.
>
> Signed-off-by: Alexey Brodkin 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  Documentation/devicetree/bindings/arc/hsdk.txt |   7 ++
>  arch/arc/Kconfig   |   1 +
>  arch/arc/Makefile  |   1 +
>  arch/arc/boot/dts/hsdk.dts | 150 
> +
>  arch/arc/configs/hsdk_defconfig|  75 +
>  arch/arc/kernel/devtree.c  |   5 +-
>  arch/arc/plat-hsdk/Kconfig |  12 ++
>  arch/arc/plat-hsdk/Makefile|   9 ++
>  arch/arc/plat-hsdk/platform.c  |  79 +
>  9 files changed, 337 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arc/hsdk.txt
>  create mode 100644 arch/arc/boot/dts/hsdk.dts
>  create mode 100644 arch/arc/configs/hsdk_defconfig
>  create mode 100644 arch/arc/plat-hsdk/Kconfig
>  create mode 100644 arch/arc/plat-hsdk/Makefile
>  create mode 100644 arch/arc/plat-hsdk/platform.c
>
> diff --git a/Documentation/devicetree/bindings/arc/hsdk.txt 
> b/Documentation/devicetree/bindings/arc/hsdk.txt
> new file mode 100644
> index 000..be50654
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arc/hsdk.txt
> @@ -0,0 +1,7 @@
> +Synopsys DesignWare ARC HS Development Kit Device Tree Bindings
> +---
> +
> +ARC HSDK Board with quad-core ARC HS38x4 in silicon.
> +
> +Required root node properties:
> +- compatible = "snps,hsdk";
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 75e5276..825a112 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -101,6 +101,7 @@ source "arch/arc/plat-tb10x/Kconfig"
>  source "arch/arc/plat-axs10x/Kconfig"
>  #New platform adds here
>  source "arch/arc/plat-eznps/Kconfig"
> +source "arch/arc/plat-hsdk/Kconfig"
>
>  endmenu
>
> diff --git a/arch/arc/Makefile b/arch/arc/Makefile
> index 44ef35d..55ca925 100644
> --- a/arch/arc/Makefile
> +++ b/arch/arc/Makefile
> @@ -111,6 +111,7 @@ core-$(CONFIG_ARC_PLAT_SIM) += arch/arc/plat-sim/
>  core-$(CONFIG_ARC_PLAT_TB10X)  += arch/arc/plat-tb10x/
>  core-$(CONFIG_ARC_PLAT_AXS10X) += arch/arc/plat-axs10x/
>  core-$(CONFIG_ARC_PLAT_EZNPS)  += arch/arc/plat-eznps/
> +core-$(CONFIG_ARC_PLAT_HSDK)   += arch/arc/plat-hsdk/
>
>  ifdef CONFIG_ARC_PLAT_EZNPS
>  KBUILD_CPPFLAGS += -I$(srctree)/arch/arc/plat-eznps/include
> diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
> new file mode 100644
> index 000..6a4e471
> --- /dev/null
> +++ b/arch/arc/boot/dts/hsdk.dts
> @@ -0,0 +1,150 @@
> +/*
> + * Copyright (C) 2017 Synopsys, Inc. (www.synopsys.com)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/*
> + * Device Tree for ARC HS Development Kit
> + */
> +/dts-v1/;
> +
> +/include/ "skeleton_hs_idu.dtsi"
> +
> +#include 
> +
> +/ {
> +   model = "snps,hsdk";
> +   compatible = "snps,hsdk";
> +
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +
> +   chosen {
> +   bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8 
> console=ttyS0,115200n8 debug print-fatal-signals=1";

Use stdout-path for the console. Really, the bootargs should be blank
and populated by the bootloader especially debug options.

> +   };
> +
> +   cpu {

'cpu' is for cpu nodes, so need something different.

> +   compatible = "simple-bus";
> +   #address-cells = <1>;
> +   #size-cells = <1>;

There are no reg properties, so these aren't needed. This doesn't look
like a simple-bus either.

Probably these child nodes should just be moved up to root level.

> +   interrupt-parent = <_intc>;
> +
> +   core_clk: core_clk {

core-clk {

> +   #clock-cells = <0>;
> +

Re: [PATCH] arc: Add "include chroot" for DT bindings

2017-05-30 Thread Rob Herring
On Tue, May 30, 2017 at 8:22 AM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> Basically this extends
> c58299aa8754 "kbuild: create an "include chroot" for DT bindings" for
> ARC where we extensively use Device Tree and there're good reasons
> to use DT bindings, especially if those are required.
>
> Otherwise on attempt to compile .dts with something like:
> >8-
>  #include 
> >8-
>
> we inevitably see this compilation failure:
> >8-
> arch/arc/boot/dts/hsdk.dts:16:40: fatal error: dt-bindings/net/ti-dp83867.h: 
> No such file or directory
>  #include 
> ^
> compilation terminated.
> >8-
>
> Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> Cc: Stephen Warren <swar...@wwwdotorg.org>
> Cc: Rob Herring <robh...@kernel.org>
> ---
>  arch/arc/boot/dts/include/dt-bindings | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 12 arch/arc/boot/dts/include/dt-bindings

I believe commit d5d332d3f7e8 ("devicetree: Move include prefixes from
arch to separate directory") does what you want.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v1 1/2] dt-bindings: Document the Synopsys DW AXI DMA bindings

2017-02-27 Thread Rob Herring
On Tue, Feb 21, 2017 at 11:38:03PM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> DesignWare AXI DMA controller.
> 
> Signed-off-by: Eugeniy Paltsev <eugeniy.palt...@synopsys.com>
> ---
>  .../devicetree/bindings/dma/snps,axi-dw-dmac.txt   | 34 
> ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/snps,axi-dw-dmac.txt

Acked-by: Rob Herring <r...@kernel.org>

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 1/2] dt-bindings: Document the Synopsys DW AXI DMA bindings

2017-01-30 Thread Rob Herring
On Wed, Jan 25, 2017 at 06:34:16PM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> DesignWare AXI DMA controller.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  .../devicetree/bindings/dma/snps,axi-dw-dmac.txt   | 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/snps,axi-dw-dmac.txt
> 
> diff --git a/Documentation/devicetree/bindings/dma/snps,axi-dw-dmac.txt 
> b/Documentation/devicetree/bindings/dma/snps,axi-dw-dmac.txt
> new file mode 100644
> index 000..21318a7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/snps,axi-dw-dmac.txt
> @@ -0,0 +1,33 @@
> +* Synopsys DesignWare AXI DMA Controller
> +
> +Required properties:
> +- compatible: "snps,axi-dma"

Too generic. This needs an IP version at least.

> +- reg: Address range of the DMAC registers. This should include
> +  all of the per-channel registers.
> +- interrupt: Should contain the DMAC interrupt number.
> +- interrupt-parent: Should be the phandle for the interrupt controller
> +  that services interrupts for this device.
> +- dma-channels: Number of channels supported by hardware.
> +- dma-masters: Number of AXI masters supported by the hardware.
> +- data-width: Maximum AXI data width supported by hardware.
> +  (0 - 8bits, 1 - 16bits, 2 - 32bits, ..., 6 - 512bits)

> +- priority: Priority of channel. Array property. Priority value must be
> +  programmed within [0:dma-channels-1] range. (0 - minimum priority)
> +- block-size: Maximum block size supported by the controller channel. Array
> +  property.

Array size equal to the number of dma-channels?

Other than dma-channels, all these either need vendor prefix.

> +
> +Example:
> +
> +dmac: dmac@8 {

dma-controller@...

> + compatible = "snps,axi-dma";
> + reg = <0x8 0x400>;
> + clocks = <_clk>;
> + interrupt-parent = <>;
> + interrupts = <27>;
> +
> + dma-channels = <4>;
> + dma-masters = <2>;
> + data-width = <3>;
> + block-size = <4096 4096 4096 4096>;
> + priority = <0 1 2 3>;
> +};
> -- 
> 2.5.5
> 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 4/4 v7] ASoC: dwc: Add irq parameter to DOCUMENTATION

2016-05-23 Thread Rob Herring
On Mon, May 23, 2016 at 11:02:25AM +0100, Jose Abreu wrote:
> A parameter description for the interruptions of the
> I2S controller was added. This interrupt parameter
> should only be set when I2S does not have DMA support.
> 
> Signed-off-by: Jose Abreu <joab...@synopsys.com>
> Cc: Carlos Palminha <palmi...@synopsys.com>
> Cc: Mark Brown <broo...@kernel.org>
> Cc: Liam Girdwood <lgirdw...@gmail.com>
> Cc: Jaroslav Kysela <pe...@perex.cz>
> Cc: Takashi Iwai <ti...@suse.com>
> Cc: Rob Herring <r...@kernel.org>
> Cc: Alexey Brodkin <abrod...@synopsys.com>
> Cc: linux-snps-arc@lists.infradead.org
> Cc: alsa-de...@alsa-project.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> 
> Changes v6 -> v7:
> * interrupts is now optional property
> 
> No changes v5 -> v6.
> 
> Changes v4 -> v5:
> * interrupts is now required property
> * Drop 'snps-use-dmaengine' property
> 
> This patch was only introduced in v4.
> 
>  Documentation/devicetree/bindings/sound/designware-i2s.txt | 4 
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring <r...@kernel.org>

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [RESEND PATCH 1/2 v6] clk/axs10x: Add I2S PLL clock driver

2016-05-03 Thread Rob Herring
On Mon, May 02, 2016 at 10:39:05AM +0100, Jose Abreu wrote:
> The ARC SDP I2S clock can be programmed using a
> specific PLL.
> 
> This patch has the goal of adding a clock driver
> that programs this PLL.
> 
> At this moment the rate values are hardcoded in
> a table but in the future it would be ideal to
> use a function which determines the PLL values
> given the desired rate.
> 
> Signed-off-by: Jose Abreu <joab...@synopsys.com>
> ---
> 
> Changes v5 -> v6:
> * Use parent clock to determine PLL input rate instead of using hardcoded 
> values
> * Documentation update (added 'clocks' field)
> 
> Changes v4 -> v5:
> * Documentation update (as suggested by Alexey Brodkin)
> * Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by 
> Alexey Brodkin)
> 
> Changes v3 -> v4:
> * Added binding document (as suggested by Stephen Boyd)
> * Minor code style fixes (as suggested by Stephen Boyd)
> * Use ioremap (as suggested by Stephen Boyd)
> * Implement round_rate (as suggested by Stephen Boyd)
> * Change to platform driver (as suggested by Stephen Boyd)
> * Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
> 
> Changes v2 -> v3:
> * Implemented recalc_rate
> 
> Changes v1 -> v2:
> * Renamed folder to axs10x (as suggested by Alexey Brodkin)
> * Added more supported rates
> 
> Cc: Carlos Palminha <palmi...@synopsys.com>
> Cc: Rob Herring <r...@kernel.org>
> Cc: Pawel Moll <pawel.m...@arm.com>
> Cc: Mark Rutland <mark.rutl...@arm.com>
> Cc: Ian Campbell <ijc+devicet...@hellion.org.uk>
> Cc: Kumar Gala <ga...@codeaurora.org>
> Cc: Michael Turquette <mturque...@baylibre.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Alexey Brodkin <abrod...@synopsys.com>
> Cc: Vineet Gupta <vgu...@synopsys.com>
> Cc: linux-snps-arc@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> 
>  .../bindings/clock/axs10x-i2s-pll-clock.txt|  25 +++

Acked-by: Rob Herring <r...@kernel.org>

>  drivers/clk/Makefile   |   1 +
>  drivers/clk/axs10x/Makefile|   1 +
>  drivers/clk/axs10x/i2s_pll_clock.c | 228 
> +
>  4 files changed, 255 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
>  create mode 100644 drivers/clk/axs10x/Makefile
>  create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 1/2 v5] clk/axs10x: Add I2S PLL clock driver

2016-04-13 Thread Rob Herring
On Tue, Apr 12, 2016 at 10:14:22AM +0100, Jose Abreu wrote:
> The ARC SDP I2S clock can be programmed using a
> specific PLL.
> 
> This patch has the goal of adding a clock driver
> that programs this PLL.
> 
> At this moment the rate values are hardcoded in
> a table but in the future it would be ideal to
> use a function which determines the PLL values
> given the desired rate.
> 
> Signed-off-by: Jose Abreu <joab...@synopsys.com>
> ---
> 
> Changes v4 -> v5:
> * Documentation update (as suggested by Alexey Brodkin)
> * Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by 
> Alexey Brodkin)
> 
> Changes v3 -> v4:
> * Added binding document (as suggested by Stephen Boyd)
> * Minor code style fixes (as suggested by Stephen Boyd)
> * Use ioremap (as suggested by Stephen Boyd)
> * Implement round_rate (as suggested by Stephen Boyd)
> * Change to platform driver (as suggested by Stephen Boyd)
> * Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
> 
> Changes v2 -> v3:
> * Implemented recalc_rate
> 
> Changes v1 -> v2:
> * Renamed folder to axs10x (as suggested by Alexey Brodkin)
> * Added more supported rates
> 
>  .../bindings/clock/axs10x-i2s-pll-clock.txt|  17 ++

Acked-by: Rob Herring <r...@kernel.org>

>  drivers/clk/Makefile   |   1 +
>  drivers/clk/axs10x/Makefile|   1 +
>  drivers/clk/axs10x/i2s_pll_clock.c | 217 
> +
>  4 files changed, 236 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
>  create mode 100644 drivers/clk/axs10x/Makefile
>  create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 2/5 v4] drm: Add DT bindings documentation for ARC PGU display controller

2016-03-25 Thread Rob Herring
On Thu, Mar 24, 2016 at 07:48:33PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
> 
> Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> Cc: Rob Herring <robh...@kernel.org>
> Cc: Pawel Moll <pawel.m...@arm.com>
> Cc: Mark Rutland <mark.rutl...@arm.com>
> Cc: Ian Campbell <ijc+devicet...@hellion.org.uk>
> Cc: Kumar Gala <ga...@codeaurora.org>
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> ---
> 
> Changes v3 -> v4: (addressing Rob's comments)
>  * Removed "encoder-slave" from required properties
>  * Removed "0x" from node names
> 
> Changes v2 -> v3:
>  * Reverted back to initial larger version of example
>with minor fixes (thanks Rob for spotting those).
> 
> Changes v1 -> v2:
>  * Removed everything except PGU node itself.
> 
>  .../devicetree/bindings/display/snps,arcpgu.txt| 71 
> ++
>  1 file changed, 71 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt 
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..b126577
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,71 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> +  - compatible: "snps,arcpgu"
> +  - reg: Physical base address and length of the controller's registers.
> +  - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> +  - clock-names: A list of clock names. For ARC PGU it should contain:
> +  - "pxlclk" for the clock feeding the output PLL of the controller.
> +
> +Required sub-nodes:
> +  - port: The PGU connection to an encoder chip.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu@XXXXXXXX {
> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <_node>;
> + clock-names = "pxlclk";
> + encoder-slave = <_node>;

Still in the example...

Otherwise,

Acked-by: Rob Herring <r...@kernel.org>

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 2/4] drm: Add DT bindings documentation for ARC PGU display controller

2016-03-18 Thread Rob Herring
On Thu, Mar 3, 2016 at 7:58 AM, Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
> Hi Rob,
>
> On Tue, 2016-02-23 at 14:38 -0600, Rob Herring wrote:
>> On Fri, Feb 19, 2016 at 04:03:52PM +0300, Alexey Brodkin wrote:
>> >
>> > This add DT bindings documentation for ARC PGU display controller.
>> >
>> > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
>> > Cc: Rob Herring <robh...@kernel.org>
>> > Cc: Pawel Moll <pawel.m...@arm.com>
>> > Cc: Mark Rutland <mark.rutl...@arm.com>
>> > Cc: Ian Campbell <ijc+devicet...@hellion.org.uk>
>> > Cc: Kumar Gala <ga...@codeaurora.org>
>> > Cc: devicet...@vger.kernel.org
>> > Cc: linux-snps-arc@lists.infradead.org
>> > ---
>> >  .../devicetree/bindings/display/snps,arcpgu.txt| 74 
>> > ++
>> >  1 file changed, 74 insertions(+)
>> >  create mode 100644 
>> > Documentation/devicetree/bindings/display/snps,arcpgu.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt
>> > b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
>> > new file mode 100644
>> > index 000..c8382fb
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
>> > @@ -0,0 +1,74 @@
>> > +ARC PGU
>> > +
>> > +This is a display controller found on several development boards produced
>> > +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
>> > +framebuffer and sends it to a single digital encoder (usually HDMI).
>> > +
>> > +Required properties:
>> > +  - compatible: "snps,arcpgu"
>> Seems like this should be more specific. Is there some sort or
>> versioning with ARC blocks?
>
> Well as of today there's only one and only version of PGU.
> So is there a real need for "snps,arcpgu-1.0"?
>
>> >
>> > +  - reg: Physical base address and length of the controller's registers.
>> > +  - clocks: A list of phandle + clock-specifier pairs, one for each
>> > +entry in 'clock-names'.
>> > +  - clock-names: A list of clock names. For ARC PGU it should contain:
>> > +  - "pxlclk" for the clock feeding the output PLL of the controller.
>> > +  - encoder-slave: Phandle of encoder chip.
>> This is unnecessary with the OF graph.
>
> Do you mean I may drop "encoder-slave" from bindings description?

Yes, you should drop it.

> I actually thought about that because in case of simulation platform where
> this device is also used there's no encoder as well as no connector - we're
> dealing with memory area which is read by host and then displayed on host's
> display.
>

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 2/4 v2] drm: Add DT bindings documentation for ARC PGU display controller

2016-03-04 Thread Rob Herring
On Thu, Mar 03, 2016 at 05:39:14PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
> 
> Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> Cc: Rob Herring <robh...@kernel.org>
> Cc: Pawel Moll <pawel.m...@arm.com>
> Cc: Mark Rutland <mark.rutl...@arm.com>
> Cc: Ian Campbell <ijc+devicet...@hellion.org.uk>
> Cc: Kumar Gala <ga...@codeaurora.org>
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> ---
> 
> Changes v1 -> v2:
>  * Clean-up

Not really useful. What we like to see is what changed. Maintainers have 
short memories and don't remember what they said previously (unless 
comments are ignored).

> 
>  .../devicetree/bindings/display/snps,arcpgu.txt| 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt 
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..57f3bc8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,33 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> +  - compatible: "snps,arcpgu"
> +  - reg: Physical base address and length of the controller's registers.
> +  - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> +  - clock-names: A list of clock names. For ARC PGU it should contain:
> +  - "pxlclk" for the clock feeding the output PLL of the controller.
> +
> +Required sub-nodes:
> +  - port: The PGU connection to an encoder chip. The connection is modelled
> +using the OF graph bindings specified in
> +Documentation/devicetree/bindings/graph.txt.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu@ {
> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <_node>;
> + clock-names = "pxlclk";

Where's the port? Didn't you previously say it was optional?

> + };
> +
> + ...
> +};
> -- 
> 2.5.0
> 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 2/4] drm: Add DT bindings documentation for ARC PGU display controller

2016-02-23 Thread Rob Herring
On Fri, Feb 19, 2016 at 04:03:52PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
> 
> Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> Cc: Rob Herring <robh...@kernel.org>
> Cc: Pawel Moll <pawel.m...@arm.com>
> Cc: Mark Rutland <mark.rutl...@arm.com>
> Cc: Ian Campbell <ijc+devicet...@hellion.org.uk>
> Cc: Kumar Gala <ga...@codeaurora.org>
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> ---
>  .../devicetree/bindings/display/snps,arcpgu.txt| 74 
> ++
>  1 file changed, 74 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt 
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..c8382fb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,74 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> +  - compatible: "snps,arcpgu"

Seems like this should be more specific. Is there some sort or 
versioning with ARC blocks?

> +  - reg: Physical base address and length of the controller's registers.
> +  - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> +  - clock-names: A list of clock names. For ARC PGU it should contain:
> +  - "pxlclk" for the clock feeding the output PLL of the controller.
> +  - encoder-slave: Phandle of encoder chip.

This is unnecessary with the OF graph.

> +
> +Required sub-nodes:
> +  - port: The PGU connection to an encoder chip. The connection is modelled
> +using the OF graph bindings specified in
> +Documentation/devicetree/bindings/graph.txt.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu@0x {

Unit address should not have '0x'

> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <_node>;
> + clock-names = "pxlclk";
> + encoder-slave = <_node>;
> +
> + port {
> + pgu_output: endpoint {
> + remote-endpoint = <_enc_input>;
> + };
> + };
> + };
> +
> + /* HDMI encoder on I2C bus */
> + i2c@0x {
> + compatible = "...";
> +
> + encoder_node:encoder_node@0x{

I2C addresses would be 8-bit only.

> + compatible="...";
> +
> + ports {
> + port@0 {
> + reg = <0>;
> + hdmi_enc_input:endpoint {
> + remote-endpoint = <_output>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + hdmi_enc_output:endpoint {
> + remote-endpoint = 
> <_connector_in>;
> + };
> + };
> + };
> + };
> + }
> +
> + hdmi0: connector {
> + compatible = "hdmi-connector";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <_enc_output>;
> + };
> + };
> + };
> +};
> -- 
> 2.5.0
> 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 2/9] ARC: [dts] Introduce Timer bindings

2016-02-03 Thread Rob Herring
On Wed, Feb 3, 2016 at 2:04 AM, Vineet Gupta <vineet.gup...@synopsys.com> wrote:
> Hi Rob,
>
> On Wednesday 03 February 2016 03:33 AM, Rob Herring wrote:
>> On Tue, Feb 02, 2016 at 04:28:52PM +0530, Vineet Gupta wrote:
>>> +Required properties:
>>> +
>>> +- compatible : should be "snps,arc-timer0"
>>
>> timer0 and timer1 are different h/w blocks, not just different
>> instances?
>
> Functionality wise they are identical (only the address of aux regs used to
> program them are different). Either can be configured to interrupt-on-limit or
> free-run-and-wrap-around. So we can indeed consider them 2 instances. ARC 
> Linux
> uses timer0 for tick handling, timer1 for gtod.
>
> Do you prefer they not be differentiated as timer0 and timer1 ?
>
> So we have
>
> CLOCKSOURCE_OF_DECLARE(arc_clkevt, "snps,arc-timer0", arc_clockevent_setup);
> CLOCKSOURCE_OF_DECLARE(arc_timer1, "snps,arc-timer1", arc_cs_setup_timer1);
>
> I don't know how to achieve above, by keeping the DT names the same.

You just need a single CLOCKSOURCE_OF_DECLARE which will be called
twice. On the first call, setup one timer and on the 2nd call setup
the other one. IIRC the sp804 timer has something similar.

You'll need a unit address in the node name to distinguish them.

>
>>
>>> +- interrupts : single Interrupt going into parent intc
>>> +   (16 for ARCHS cores, 3 for ARC700 cores)
>>> +- clocks : phandle to the source clock
>>> +
>>> +Optional properties:
>>> +
>>> +- interrupt-parent : phandle to parent intc
>>> +
>>> +Example:
>>> +
>>> +timer0: timer_clkevt {
>>
>> just "timer" for node name. clkevt is a Linuxism.
>
> OK. So to document that this is for clockevent, change the label ?

That shouldn't be documented in the DT at all.

>
> timer_clkevent: timer {
>
>>
>>> +compatible = "snps,arc-timer0";
>>> +interrupts = <3>;
>>> +interrupt-parent = <_intc>;
>>> +clocks = <_clk>;
>>> +};
>>> diff --git a/Documentation/devicetree/bindings/timer/snps,arc-timer1.txt 
>>> b/Documentation/devicetree/bindings/timer/snps,arc-timer1.txt
>>> new file mode 100644
>>> index ..4886192ce2f2
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/timer/snps,arc-timer1.txt
>>> @@ -0,0 +1,17 @@
>>> +Synopsys ARC Free Running Local 32-bit Timer
>>> +- Found on all ARC CPUs (ARC700/ARCHS)
>>> +- Mandatory clocksource provider on ARC700
>>> +- Optional clocksource provider on UP ARC HS CPUs
>>> +  (and if better timer archs-rtc not available in SoC)
>>> +
>>> +Required properties:
>>> +
>>> +- compatible : should be "snps,arc-timer1"
>>> +- clocks : phandle to the source clock
>>
>> No interrupt because it doesn't have one or you use this as a
>> clocksource and don't need it?
>
> Latter !

Then you should have the interrupt in the DT anyway.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 07/15] dmaengine: dw: revisit data_width property

2016-01-26 Thread Rob Herring
On Sun, Jan 24, 2016 at 07:21:54PM +, Mans Rullgard wrote:
> From: Andy Shevchenko 
> 
> There are several changes are done here:
> 
>  - Convert the property to be in bytes
> 
>Much more convenient than keeping encoded value.
> 
>  - Use one value for all AHB masters for now
> 
>It seems in practice we have no controllers where masters have different
>data bus width, we still might return to distinct values when there is a 
> use
>case.
> 
>  - Rename data_width to data-width in the device tree bindings.
> 
>  - While here, replace dwc_fast_ffs() by __ffs().
> 
> Signed-off-by: Andy Shevchenko 
> Signed-off-by: Mans Rullgard 
> ---
> This patch changes the DT binding, so it should probably be amended for
> compatibility with old device trees.  I've included it as is since I think
> the change as such is good.

Just because you update the dts files, it doesn't make the change okay. 
I'm fine with the DT change, but the driver would have to support both 
old and new property names. Doesn't really seem worth doing to me.

Rob

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


  1   2   >