date:20150826

This patch enable the generation of symbols  local fixup information
for trees compiled with the -@ (--symbols) option.

Using this patch labels in the tree and their users emit information
in __symbols__ and __local_fixups__ nodes.

The __fixups__ node make possible the dynamic resolution of phandle
references which are present in the plugin tree but lie in the
tree that are applying the overlay against.

panto: The original alternative syntax patch required the use of an empty node
which is no longer required.
Numbering of fragments in sequence was also implemented.

Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Jan Luebbe j...@pengutronix.de
---
 Documentation/manual.txt |  16 
 checks.c |  18 -
 dtc-lexer.l  |   5 ++
 dtc-parser.y |  54 +++--
 dtc.c|  21 -
 dtc.h|  13 ++-
 livetree.c   | 202 +++
 treesource.c |   3 +
 8 files changed, 321 insertions(+), 11 deletions(-)

diff --git a/Documentation/manual.txt b/Documentation/manual.txt
index 398de32..29682df 100644
--- a/Documentation/manual.txt
+++ b/Documentation/manual.txt
@@ -119,6 +119,20 @@ Options:
Make space for number reserve map entries
Relevant for dtb and asm output only.
 
+-@
+Generates a __symbols__ node at the root node of the resulting blob
+   for any node labels used, and for any local references using phandles
+   it also generates a __local_fixups__ node that tracks them.
+
+   When using the /plugin/ tag all unresolved label references to
+   be tracked in the __fixups__ node, making dynamic resolution possible.
+
+-A
+   Generate automatically aliases for all node labels. This is similar to
+   the -@ option (the __symbols__ node contain identical information) but
+   the semantics are slightly different since no phandles are automatically
+   generated for labeled nodes.
+
 -S bytes
Ensure the blob at least bytes long, adding additional
space if needed.
@@ -153,6 +167,8 @@ Here is a very rough overview of the layout of a DTS source 
file:
 
 devicetree:   '/' nodedef
 
+plugindecl:   '/' 'plugin' '/' ';'
+
 nodedef:  '{' list_of_property list_of_subnode '}' ';'
 
 property: label PROPNAME '=' propdata ';'
diff --git a/checks.c b/checks.c
index 0c03ac9..65bf6fd 100644
--- a/checks.c
+++ b/checks.c
@@ -466,8 +466,12 @@ static void fixup_phandle_references(struct check *c, 
struct node *dt,
 
refnode = get_node_by_ref(dt, m-ref);
if (! refnode) {
-   FAIL(c, Reference to non-existent node or label 
\%s\\n,
-m-ref);
+   if (!source_is_plugin)
+   FAIL(c, Reference to non-existent node or 
+   label \%s\\n, m-ref);
+   else /* mark the entry as unresolved */
+   *((cell_t *)(prop-val.val + m-offset)) =
+   cpu_to_fdt32(0x);
continue;
}
 
@@ -652,6 +656,15 @@ static void 
check_obsolete_chosen_interrupt_controller(struct check *c,
 }
 TREE_WARNING(obsolete_chosen_interrupt_controller, NULL);
 
+static void check_deprecated_plugin_syntax(struct check *c,
+  struct node *dt)
+{
+   if (deprecated_plugin_syntax_warning)
+   FAIL(c, Use '/dts-v1/ /plugin/'; syntax. /dts-v1/; /plugin/; 
+   is going to be removed in next versions);
+}
+TREE_WARNING(deprecated_plugin_syntax, NULL);
+
 static struct check *check_table[] = {
duplicate_node_names, duplicate_property_names,
node_name_chars, node_name_format, property_name_chars,
@@ -669,6 +682,7 @@ static struct check *check_table[] = {
 
avoid_default_addr_size,
obsolete_chosen_interrupt_controller,
+   deprecated_plugin_syntax,
 
always_fail,
 };
diff --git a/dtc-lexer.l b/dtc-lexer.l
index 0ee1caf..dd44ba2 100644
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -113,6 +113,11 @@ static void lexical_error(const char *fmt, ...);
return DT_V1;
}
 
+*/plugin/  {
+   DPRINT(Keyword: /plugin/\n);
+   return DT_PLUGIN;
+   }
+
 */memreserve/  {
DPRINT(Keyword: /memreserve/\n);
BEGIN_DEFAULT();
diff --git a/dtc-parser.y b/dtc-parser.y
index 5a897e3..aba 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -19,6 +19,7 @@
  */
 %{
 #include stdio.h
+#include inttypes.h
 
 #include dtc.h
 #include srcpos.h
@@ -52,9 +53,11 @@ extern bool treesource_error;
struct node *nodelist;

[PATCH v5 0/2] dtc: Dynamic DT support

Enable the generation of symbol  fixup information for
use with dynamic DT loading.

Changes since v4:
* Rebase to latest dtc version.
* Completely redesigned the generation of resolution data.
Now instead of being generated as part of blob generation
they are created in the live tree.
* Consequently the patchset is much smaller.
* Added -A auto-label alias generation option.
* Addressed maintainer comments.
* Added syntactic sugar for overlays in the form of .dtsi
* Added /dts-v1/ /plugin/ preferred plugin form and deprecate
the previous form (although still works for backward compatibility)

Changes since v3:
* Rebase to latest dtc version.

Changes since v2:
* Split single patch to a patchset.
* Updated to dtc mainline.
* Changed __local_fixups__ format
* Clean up for better legibility.


Pantelis Antoniou (2):
  dtc: Plugin and fixup support
  dtc: Document the dynamic plugin internals

 Documentation/dt-object-internal.txt | 317 +++
 Documentation/manual.txt |  16 ++
 checks.c |  18 +-
 dtc-lexer.l  |   5 +
 dtc-parser.y |  54 +-
 dtc.c|  21 ++-
 dtc.h|  13 +-
 livetree.c   | 202 ++
 treesource.c |   3 +
 9 files changed, 638 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/dt-object-internal.txt

-- 
1.7.12

--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/2] dtc: Document the dynamic plugin internals

Provides the document explaining the internal mechanics of
plugins and options.

Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com
---
 Documentation/dt-object-internal.txt | 317 +++
 1 file changed, 317 insertions(+)
 create mode 100644 Documentation/dt-object-internal.txt

diff --git a/Documentation/dt-object-internal.txt 
b/Documentation/dt-object-internal.txt
new file mode 100644
index 000..38a47b6
--- /dev/null
+++ b/Documentation/dt-object-internal.txt
@@ -0,0 +1,317 @@
+Device Tree Dynamic Object format internals
+---
+
+The Device Tree for most platforms is a static representation of
+the hardware capabilities. This is insufficient for many platforms
+that need to dynamically insert device tree fragments to the
+running kernel's live tree.
+
+This document explains the the device tree object format and the
+modifications made to the device tree compiler, which make it possible.
+
+1. Simplified Problem Definition
+
+
+Assume we have a platform which boots using following simplified device tree.
+
+ foo.dts -
+   /* FOO platform */
+   / {
+   compatible = corp,foo;
+
+   /* shared resources */
+   res: res {
+   };
+
+   /* On chip peripherals */
+   ocp: ocp {
+   /* peripherals that are always instantiated */
+   peripheral1 { ... };
+   }
+   };
+ foo.dts -
+
+We have a number of peripherals that after probing (using some undefined 
method)
+should result in different device tree configuration.
+
+We cannot boot with this static tree because due to the configuration of the
+foo platform there exist multiple conficting peripherals DT fragments.
+
+So for the bar peripheral we would have this:
+
+ foo+bar.dts -
+   /* FOO platform + bar peripheral */
+   / {
+   compatible = corp,foo;
+
+   /* shared resources */
+   res: res {
+   };
+
+   /* On chip peripherals */
+   ocp: ocp {
+   /* peripherals that are always instantiated */
+   peripheral1 { ... };
+
+   /* bar peripheral */
+   bar {
+   compatible = corp,bar;
+   ... /* various properties and child nodes */
+   }
+   }
+   };
+ foo+bar.dts -
+
+While for the baz peripheral we would have this:
+
+ foo+baz.dts -
+   /* FOO platform + baz peripheral */
+   / {
+   compatible = corp,foo;
+
+   /* shared resources */
+   res: res {
+   /* baz resources */
+   baz_res: res_baz { ... };
+   };
+
+   /* On chip peripherals */
+   ocp: ocp {
+   /* peripherals that are always instantiated */
+   peripheral1 { ... };
+
+   /* baz peripheral */
+   baz {
+   compatible = corp,baz;
+   /* reference to another point in the tree */
+   ref-to-res = baz_res;
+   ... /* various properties and child nodes */
+   }
+   }
+   };
+ foo+baz.dts -
+
+We note that the baz case is more complicated, since the baz peripheral needs 
to
+reference another node in the DT tree.
+
+2. Device Tree Object Format Requirements
+-
+
+Since the device tree is used for booting a number of very different hardware
+platforms it is imperative that we tread very carefully.
+
+2.a) No changes to the Device Tree binary format. We cannot modify the tree
+format at all and all the information we require should be encoded using device
+tree itself. We can add nodes that can be safely ignored by both bootloaders 
and
+the kernel.
+
+2.b) Changes to the DTS source format should be absolutely minimal, and should
+only be needed for the DT fragment definitions, and not the base boot DT.
+
+2.c) An explicit option should be used to instruct DTC to generate the required
+information needed for object resolution. Platforms that don't use the
+dynamic object format can safely ignore it.
+
+2.d) Finally, DT syntax changes should be kept to a minimum. It should be
+possible to express everything using the existing DT syntax.
+

[PATCH v5 2/2] dtc: Document the dynamic plugin internals

Provides the document explaining the internal mechanics of
plugins and options.

Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com
---
 Documentation/dt-object-internal.txt | 317 +++
 1 file changed, 317 insertions(+)
 create mode 100644 Documentation/dt-object-internal.txt

diff --git a/Documentation/dt-object-internal.txt 
b/Documentation/dt-object-internal.txt
new file mode 100644
index 000..38a47b6
--- /dev/null
+++ b/Documentation/dt-object-internal.txt
@@ -0,0 +1,317 @@
+Device Tree Dynamic Object format internals
+---
+
+The Device Tree for most platforms is a static representation of
+the hardware capabilities. This is insufficient for many platforms
+that need to dynamically insert device tree fragments to the
+running kernel's live tree.
+
+This document explains the the device tree object format and the
+modifications made to the device tree compiler, which make it possible.
+
+1. Simplified Problem Definition
+
+
+Assume we have a platform which boots using following simplified device tree.
+
+ foo.dts -
+   /* FOO platform */
+   / {
+   compatible = corp,foo;
+
+   /* shared resources */
+   res: res {
+   };
+
+   /* On chip peripherals */
+   ocp: ocp {
+   /* peripherals that are always instantiated */
+   peripheral1 { ... };
+   }
+   };
+ foo.dts -
+
+We have a number of peripherals that after probing (using some undefined 
method)
+should result in different device tree configuration.
+
+We cannot boot with this static tree because due to the configuration of the
+foo platform there exist multiple conficting peripherals DT fragments.
+
+So for the bar peripheral we would have this:
+
+ foo+bar.dts -
+   /* FOO platform + bar peripheral */
+   / {
+   compatible = corp,foo;
+
+   /* shared resources */
+   res: res {
+   };
+
+   /* On chip peripherals */
+   ocp: ocp {
+   /* peripherals that are always instantiated */
+   peripheral1 { ... };
+
+   /* bar peripheral */
+   bar {
+   compatible = corp,bar;
+   ... /* various properties and child nodes */
+   }
+   }
+   };
+ foo+bar.dts -
+
+While for the baz peripheral we would have this:
+
+ foo+baz.dts -
+   /* FOO platform + baz peripheral */
+   / {
+   compatible = corp,foo;
+
+   /* shared resources */
+   res: res {
+   /* baz resources */
+   baz_res: res_baz { ... };
+   };
+
+   /* On chip peripherals */
+   ocp: ocp {
+   /* peripherals that are always instantiated */
+   peripheral1 { ... };
+
+   /* baz peripheral */
+   baz {
+   compatible = corp,baz;
+   /* reference to another point in the tree */
+   ref-to-res = baz_res;
+   ... /* various properties and child nodes */
+   }
+   }
+   };
+ foo+baz.dts -
+
+We note that the baz case is more complicated, since the baz peripheral needs 
to
+reference another node in the DT tree.
+
+2. Device Tree Object Format Requirements
+-
+
+Since the device tree is used for booting a number of very different hardware
+platforms it is imperative that we tread very carefully.
+
+2.a) No changes to the Device Tree binary format. We cannot modify the tree
+format at all and all the information we require should be encoded using device
+tree itself. We can add nodes that can be safely ignored by both bootloaders 
and
+the kernel.
+
+2.b) Changes to the DTS source format should be absolutely minimal, and should
+only be needed for the DT fragment definitions, and not the base boot DT.
+
+2.c) An explicit option should be used to instruct DTC to generate the required
+information needed for object resolution. Platforms that don't use the
+dynamic object format can safely ignore it.
+
+2.d) Finally, DT syntax changes should be kept to a minimum. It should be
+possible to express everything using the existing DT syntax.
+

[linux-next][PATCH v2] ARM: sun7i: dt: Add new Olimex A20 EVB device

2015-08-26 Thread codekipper

From: Marcus Cooper codekip...@gmail.com

The A20-SOM-EVB is a reference design of a 2-layer board for the
A20-SOM.
It expands the features of A20-SOM by adding VGA connector, HDMI
connector, audio In/Out, LCD connector, 2 Mpix camera, gigabit
Ethernet, SATA, USB-OTG and 2 USB hosts.

This patch adds basic support for the device
https://www.olimex.com/Products/SOM/A20/A20-SOM-EVB/

More information on the SOM can be found here
http://linux-sunxi.org/Olimex_A20-SOM.

Signed-off-by: Marcus Cooper codekip...@gmail.com
---
Changes since v1:
- renamed dts from sun7i-a20-olinuxino-evb to sun7i-a20-olimex-som-evb
- added axp209 dtsi
- change regulator settings
---
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 216 +
 2 files changed, 217 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f830e1f..e4e1d29 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -588,6 +588,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-i12-tvbox.dtb \
sun7i-a20-m3.dtb \
sun7i-a20-mk808c.dtb \
+   sun7i-a20-olimex-som-evb.dtb \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
sun7i-a20-olinuxino-micro.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts 
b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
new file mode 100644
index 000..36d1e77
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
@@ -0,0 +1,216 @@
+/*
+ * Copyright 2015 - Marcus Cooper codekip...@gmail.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include sun7i-a20.dtsi
+#include sunxi-common-regulators.dtsi
+
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/pinctrl/sun4i-a10.h
+
+/ {
+   model = Olimex A20-Olimex-SOM-EVB;
+   compatible = olimex,a20-olimex-som-evb, allwinner,sun7i-a20;
+
+   aliases {
+   serial0 = uart0;
+   };
+
+   chosen {
+   stdout-path = serial0:115200n8;
+   };
+
+   leds {
+   compatible = gpio-leds;
+   pinctrl-names = default;
+   pinctrl-0 = led_pins_olimex_som_evb;
+
+   green {
+   label = a20-olimex-som-evb:green:usr;
+   gpios = pio 7 2 GPIO_ACTIVE_HIGH;
+   default-state = on;
+   };
+   };
+
+   reg_axp_ipsout: axp_ipsout {
+   compatible = regulator-fixed;
+   regulator-name = axp-ipsout;
+   regulator-min-microvolt = 500;
+   regulator-max-microvolt = 500;
+   regulator-always-on;
+   };
+};
+
+ahci {
+   target-supply = reg_ahci_5v;
+   status = okay;
+};
+
+ehci0 {
+   status = okay;
+};
+
+ehci1 {
+   status = okay;
+};
+
+gmac {
+   pinctrl-names = default;
+   pinctrl-0 = gmac_pins_rgmii_a;
+

Re: [PATCH 2/5] ARM: NSP: add minimal Northstar Plus device tree

On Tue, Aug 25, 2015 at 04:36:45PM -0700, Olof Johansson wrote:
 Hi,
 
 I'm not sure what the strategy behind your cc:ing on this patch set
 is. I only got a couple of them in my inbox, and this one wasn't one
 of them. :)

I sent them to the people listed as maintainers in get_maintainer.pl.
It didn't seem to include you in all of them, but I thought the
mailing list would be enough of a catch all.  My apologies.  I'll CC
everyone listed as a maintainer on all of the patches in the future.

 
 On Thu, Aug 20, 2015 at 10:46 AM, Jon Mason jonma...@broadcom.com wrote:
  Add a very minimalistic set of Northstar Plus Device Tree files which
  describes the SoC and the BCM958625 implementation.  The perpherials
  described are:
 
  ARM Cortex A9 CPU
  2 8250 UARTs
  ARM GIC
  PL310 L2 Cache
  ARM A9 Global timer
 
  Signed-off-by: Jon Mason jonma...@broadcom.com
  Signed-off-by: Kapil Hali kap...@broadcom.com
  Reviewed-by: Ray Jui r...@broadcom.com
  Reviewed-by: Scott Branden sbran...@broadcom.com
 
 Seeing reviewed-by already attached to a v1 of a patchset has limited
 value for someone on the outside.
 
 Reviewed-by is one of those tags that has a value that's mostly
 dependent on who it comes from. By not actually seeing the review and
 the feedback provided (and revisions made), less data is provided to
 tell if it's a valuable review or not.
 
 Also, if you're posting the code you should probably have your name
 below Kapil's, since you're the one signing off the origin of the
 code. See Documentation/SubmittingPatches.txt for details on what
 S-o-b actually means.

We worked on it together, but I'll be happy to reorder as you suggest.

 
 
  --- /dev/null
  +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
  @@ -0,0 +1,105 @@
  +/*
  + *  BSD LICENSE
  + *
  + *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
  + *
  + *  Redistribution and use in source and binary forms, with or without
  + *  modification, are permitted provided that the following conditions
  + *  are met:
  + *
  + ** Redistributions of source code must retain the above copyright
  + *  notice, this list of conditions and the following disclaimer.
  + ** Redistributions in binary form must reproduce the above copyright
  + *  notice, this list of conditions and the following disclaimer in
  + *  the documentation and/or other materials provided with the
  + *  distribution.
  + ** Neither the name of Broadcom Corporation nor the names of its
  + *  contributors may be used to endorse or promote products derived
  + *  from this software without specific prior written permission.
  + *
  + *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
  + *  AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
  + *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
  + *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
  + *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  + *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  + *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
  + *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
  + *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
  + *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  + *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  + */
 
 I'm not sure we've seen BSD-only submissions before. I'll let DT
 maintainers (or Ian) speak up in case this would cause problems.

I was following the precedent in arch/arm/boot/dts/bcm-cygnus.dtsi.
If this is preferred to be GPL v2, then I will happily comply.

 
 
  +
  +#include dt-bindings/interrupt-controller/arm-gic.h
  +#include dt-bindings/interrupt-controller/irq.h
  +
  +#include skeleton.dtsi
  +
  +/ {
  +   compatible = brcm,nsp;
  +   model = Broadcom Northstar Plus SoC;
  +   interrupt-parent = gic;
  +
  +   cpus {
  +   #address-cells = 1;
  +   #size-cells = 0;
  +
  +   cpu@0 {
  +   device_type = cpu;
  +   compatible = arm,cortex-a9;
  +   next-level-cache = L2;
  +   reg = 0x0;
  +   };
  +   };
  +
  +   clocks {
  +   #address-cells = 1;
  +   #size-cells = 1;
  +   ranges;
  +
  +   periph_clk: periph_clk {
  +   compatible = fixed-clock;
  +   #clock-cells = 0;
  +   clock-frequency = 5;
  +   };
  +   };
  +
  +   uart0: serial@18000300 {
  +   compatible = ns16550a;
  +   reg = 0x18000300 0x100;
  +   interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
  +   clock-frequency = 62499840;
  +   status = disabled;
  +   };
  +

Re: [PATCH 2/5] ARM: NSP: add minimal Northstar Plus device tree

2015-08-26 Thread Olof Johansson

On Wed, Aug 26, 2015 at 11:40 AM, Jon Mason jonma...@broadcom.com wrote:
 On Tue, Aug 25, 2015 at 04:36:45PM -0700, Olof Johansson wrote:
 Hi,

 I'm not sure what the strategy behind your cc:ing on this patch set
 is. I only got a couple of them in my inbox, and this one wasn't one
 of them. :)

 I sent them to the people listed as maintainers in get_maintainer.pl.
 It didn't seem to include you in all of them, but I thought the
 mailing list would be enough of a catch all.  My apologies.  I'll CC
 everyone listed as a maintainer on all of the patches in the future.

No worries. Just pointing it out since you asked me to look at the
patches and, well, I hadn't received them all. :)

 On Thu, Aug 20, 2015 at 10:46 AM, Jon Mason jonma...@broadcom.com wrote:
  Add a very minimalistic set of Northstar Plus Device Tree files which
  describes the SoC and the BCM958625 implementation.  The perpherials
  described are:
 
  ARM Cortex A9 CPU
  2 8250 UARTs
  ARM GIC
  PL310 L2 Cache
  ARM A9 Global timer
 
  Signed-off-by: Jon Mason jonma...@broadcom.com
  Signed-off-by: Kapil Hali kap...@broadcom.com
  Reviewed-by: Ray Jui r...@broadcom.com
  Reviewed-by: Scott Branden sbran...@broadcom.com

 Seeing reviewed-by already attached to a v1 of a patchset has limited
 value for someone on the outside.

 Reviewed-by is one of those tags that has a value that's mostly
 dependent on who it comes from. By not actually seeing the review and
 the feedback provided (and revisions made), less data is provided to
 tell if it's a valuable review or not.

 Also, if you're posting the code you should probably have your name
 below Kapil's, since you're the one signing off the origin of the
 code. See Documentation/SubmittingPatches.txt for details on what
 S-o-b actually means.

 We worked on it together, but I'll be happy to reorder as you suggest.



  --- /dev/null
  +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
  @@ -0,0 +1,105 @@
  +/*
  + *  BSD LICENSE
  + *
  + *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
  + *
  + *  Redistribution and use in source and binary forms, with or without
  + *  modification, are permitted provided that the following conditions
  + *  are met:
  + *
  + ** Redistributions of source code must retain the above copyright
  + *  notice, this list of conditions and the following disclaimer.
  + ** Redistributions in binary form must reproduce the above copyright
  + *  notice, this list of conditions and the following disclaimer in
  + *  the documentation and/or other materials provided with the
  + *  distribution.
  + ** Neither the name of Broadcom Corporation nor the names of its
  + *  contributors may be used to endorse or promote products derived
  + *  from this software without specific prior written permission.
  + *
  + *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
  + *  AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
  + *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
  + *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
  + *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  + *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  + *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
  + *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
  + *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
  + *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  + *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  + */

 I'm not sure we've seen BSD-only submissions before. I'll let DT
 maintainers (or Ian) speak up in case this would cause problems.

 I was following the precedent in arch/arm/boot/dts/bcm-cygnus.dtsi.
 If this is preferred to be GPL v2, then I will happily comply.

No, we'd rather have BSD-only than GPL-only, so keeping it as it is
should be OK.

  +   chosen {
  +   stdout-path = serial0:115200n8;
  +   };

 No way to mount a root filesystem yet? How much work remains for that
 to be possible, and what's the plan for that?

 It mounts rootfs.  I am adding the rootfs to the kernel and device
 tree blob via the u-boot mkimage command.  It boots all the way to
 shell without issue.

Sure, any system with memory can use ramdisk for root, that's not what I meant.

Still, based on post from Scott it sounds like NAND support isn't far away.


-Olof
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] Add support for img AXD audio hardware decoder

2015-08-26 Thread Mark Brown

On Mon, Aug 24, 2015 at 01:39:09PM +0100, Qais Yousef wrote:

 Qais Yousef (10):
   irqchip: irq-mips-gic: export gic_send_ipi
   dt: add img,axd.txt device tree binding document
   ALSA: add AXD Audio Processing IP alsa driver
   ALSA: axd: add fw binary header manipulation files
   ALSA: axd: add buffers manipulation files
   ALSA: axd: add basic files for sending/receiving axd cmds
   ALSA: axd: add cmd interface helper functions
   ALSA: axd: add low level AXD platform setup files
   ALSA: axd: add alsa compress offload operations
   ALSA: axd: add Makefile

Please try to use subject lines matching the style for the subsystem, I
very nearly deleted this unread because it looks like an ALSA patch
series, not an ASoC one.


signature.asc
Description: Digital signature

Re: [PATCH 2/5] ARM: NSP: add minimal Northstar Plus device tree

2015-08-26 Thread Scott Branden


Hi Olof,

Comments inline.

On 15-08-25 04:36 PM, Olof Johansson wrote:

Hi,

I'm not sure what the strategy behind your cc:ing on this patch set
is. I only got a couple of them in my inbox, and this one wasn't one
of them. :)

On Thu, Aug 20, 2015 at 10:46 AM, Jon Mason jonma...@broadcom.com wrote:

Add a very minimalistic set of Northstar Plus Device Tree files which
describes the SoC and the BCM958625 implementation.  The perpherials
described are:

ARM Cortex A9 CPU
2 8250 UARTs
ARM GIC
PL310 L2 Cache
ARM A9 Global timer

Signed-off-by: Jon Mason jonma...@broadcom.com
Signed-off-by: Kapil Hali kap...@broadcom.com
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com


Seeing reviewed-by already attached to a v1 of a patchset has limited
value for someone on the outside.




Reviewed-by is one of those tags that has a value that's mostly
dependent on who it comes from. By not actually seeing the review and
the feedback provided (and revisions made), less data is provided to
tell if it's a valuable review or not.
should we start using Ack'd instead then for things that were reviewed 
internally?


Also, if you're posting the code you should probably have your name
below Kapil's, since you're the one signing off the origin of the
code. See Documentation/SubmittingPatches.txt for details on what
S-o-b actually means.



--- /dev/null
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -0,0 +1,105 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */


I'm not sure we've seen BSD-only submissions before. I'll let DT
maintainers (or Ian) speak up in case this would cause problems.



Arnd is the one who require new DT content to be BSD licensed.
We're just following his orders:

http://lkml.iu.edu/hypermail/linux/kernel/1411.1/01109.html




+
+#include dt-bindings/interrupt-controller/arm-gic.h
+#include dt-bindings/interrupt-controller/irq.h
+
+#include skeleton.dtsi
+
+/ {
+   compatible = brcm,nsp;
+   model = Broadcom Northstar Plus SoC;
+   interrupt-parent = gic;
+
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   cpu@0 {
+   device_type = cpu;
+   compatible = arm,cortex-a9;
+   next-level-cache = L2;
+   reg = 0x0;
+   };
+   };
+
+   clocks {
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   periph_clk: periph_clk {
+   compatible = fixed-clock;
+   #clock-cells = 0;
+   clock-frequency = 5;
+   };
+   };
+
+   uart0: serial@18000300 {
+   compatible = ns16550a;
+   reg = 0x18000300 0x100;
+   interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
+   clock-frequency = 62499840;
+   status = disabled;
+   };
+
+   uart1: serial@18000400 {
+   compatible = ns16550a;
+   reg = 0x18000400 0x100;
+   interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
+   clock-frequency = 62499840;
+   status = disabled;
+   };
+
+   gic: interrupt-controller@19021000 {
+   compatible = arm,cortex-a9-gic;
+   #interrupt-cells = 3;
+

Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

2015-08-26 Thread Marek Vasut

On Wednesday, August 26, 2015 at 12:09:50 AM, vikas wrote:
 Hi,
 
 On 08/21/2015 02:20 AM, Marek Vasut wrote:
  From: Graham Moore grmo...@opensource.altera.com
  
  Add support for the Cadence QSPI controller. This controller is
  present in the Altera SoCFPGA SoCs and this driver has been tested
  on the Cyclone V SoC.
  
  Signed-off-by: Graham Moore grmo...@opensource.altera.com
  Signed-off-by: Marek Vasut ma...@denx.de
  Cc: Alan Tull at...@opensource.altera.com
  Cc: Brian Norris computersforpe...@gmail.com
  Cc: David Woodhouse dw...@infradead.org
  Cc: Dinh Nguyen dingu...@opensource.altera.com
  Cc: Graham Moore grmo...@opensource.altera.com
  Cc: Vikas MANOCHA vikas.mano...@st.com
  Cc: Yves Vandervennet yvand...@opensource.altera.com
  Cc: devicetree@vger.kernel.org
  ---
  
   drivers/mtd/spi-nor/Kconfig   |   11 +
   drivers/mtd/spi-nor/Makefile  |1 +
   drivers/mtd/spi-nor/cadence-quadspi.c | 1260
   + 3 files changed, 1272 insertions(+)
   create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c
  
  V2: use NULL instead of modalias in spi_nor_scan call
  V3: Use existing property is-decoded-cs instead of creating duplicate.
  V4: Support Micron quad mode by snooping command stream for EVCR command
  
  and subsequently configuring Cadence controller for quad mode.
  
  V5: Clean up sparse and smatch complaints.  Remove snooping of Micron
  
  quad mode.  Add comment on XIP mode bit and dummy clock cycles.  Set
  up SRAM partition at 1:1 during init.
  
  V6: Remove dts patch that was included by mistake.  Incorporate Vikas's
  
  comments regarding fifo width, SRAM partition setting, and trigger
  address.  Trigger address was added as an unsigned int, as it is not
  an IO resource per se, and does not need to be mapped. Also add
  Marek Vasut's workaround for picking up OF properties on subnodes.
  
  V7: - Perform coding-style cleanup and type fixes. Remove ugly QSPI_*()
  
macros and replace them with functions. Get rid of unused
variables.
  
  - Implement support for nor-set_protocol() to handle Quad-command,
  
this patch now depends on the following patch:
mtd: spi-nor: notify (Q)SPI controller about protocol change
  
  - Replace that cqspi_fifo_read() disaster with plain old readsl()
  
and cqspi_fifo_write() tentacle horror with pretty writesl().
  
  - Remove CQSPI_SUPPORT_XIP_CHIPS, which is broken.
  - Get rid of cqspi_find_chipselect() mess, instead just place the
  
struct cqspi_st and chipselect number into struct cqspi_flash_pdata
and set nor-priv to the struct cqspi_flash_pdata of that
particular chip.
  
  - Replace the odd math in calculate_ticks_for_ns() with
  DIV_ROUND_UP(). - Make variables const where applicable.
  
  V8: - Implement a function to wait for bit being set/unset for a given
  
period of time and use it to replace the ad-hoc bits of code.
  
  - Configure the write underflow watermark to be 1/8 if FIFO size.
  - Extract out the SPI NOR flash probing code into separate function
  
to clearly mark what will soon be considered a boilerplate code.
  
  - Repair the handling of mode bits, which caused instability in V7.
  - Clean up the interrupt handling
  - Fix Kconfig help text and make the patch depend on OF and
  COMPILE_TEST.
  
  diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
  index 89bf4c1..ed253a2 100644
  --- a/drivers/mtd/spi-nor/Kconfig
  +++ b/drivers/mtd/spi-nor/Kconfig
  @@ -40,4 +40,15 @@ config SPI_NXP_SPIFI
  
Flash. Enable this option if you have a device with a SPIFI
controller and want to access the Flash as a mtd device.
  
  +config SPI_CADENCE_QUADSPI
  +   tristate Cadence Quad SPI controller
  +   depends on OF  COMPILE_TEST
  +   help
  + Enable support for the Cadence Quad SPI Flash controller.
  +
  + Cadence QSPI is a specialized controller for connecting an SPI
  + Flash over 1/2/4-bit wide bus. Enable this option if you have a
  + device with a Cadence QSPI controller and want to access the
  + Flash as an MTD device.
  +
 
 the patch failed to apply, please rebase it to master.

it's based on -next, I'm sure you can fix trivial conflicts yourself if you
need to apply it elsewhere. Do you have any other review comments ?
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

On Tue, 25 Aug 2015, Peter Griffin wrote:

 Hi Vinod,
 
 Thanks for reviewing.
 
 On Wed, 19 Aug 2015, Vinod Koul wrote:
 
  On Wed, Jul 08, 2015 at 05:11:22PM +0100, Peter Griffin wrote:
   This patch adds the DT binding documentation for the FDMA constroller
   found on STi based chipsets from STMicroelectronics.
   
   Signed-off-by: Ludovic Barre ludovic.ba...@st.com
   Signed-off-by: Peter Griffin peter.grif...@linaro.org
   ---
Documentation/devicetree/bindings/dma/st_fdma.txt | 76 
   +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt
   
   diff --git a/Documentation/devicetree/bindings/dma/st_fdma.txt 
   b/Documentation/devicetree/bindings/dma/st_fdma.txt
   new file mode 100644
   index 000..1ec7470
   --- /dev/null
   +++ b/Documentation/devicetree/bindings/dma/st_fdma.txt
   @@ -0,0 +1,76 @@
   +* STMicroelectronics Flexible Direct Memory Access Device Tree bindings
   +
   +The FDMA is a general-purpose direct memory access controller capable of
   +supporting 16 independent DMA channels. It accepts up to 32 DMA requests.
   +The FDMA is based on a Slim processor which require a firmware.
   +
   +* FDMA Controller
   +
   +Required properties:
   +- compatible : Should be st,fdma_mpe31
   +- reg: Should contain DMA registers location and length
   +- interrupts : Should contain one interrupt shared by all channel
  
  s/channel/channels
 
 Will fix in v2.
 
  
   +- dma-channels   : Number of channels supported by the controller
   +- #dma-cells : Must be 3.
  
  any reason three?
 
 Yes, it is documented further down in the file under DMA Client.
 
 To make it clearer in V2 I could change to
 
 - #dma-cells : Must be 3. See DMA client section below?

- #dma-cells: Must be 3
1st cell: Phandle to   ... blah
2nd cell: DMA channel  ... blah
3rd cell: Flags describing ... blah   

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node

2015-08-26 Thread Leo Yan

Hi Haojian,

On Wed, Aug 26, 2015 at 09:25:41AM +0800, Haojian Zhuang wrote:
 On Wed, 2015-08-26 at 00:00 +0800, Leo Yan wrote:
  On Tue, Aug 25, 2015 at 09:43:14PM +0800, Haojian Zhuang wrote:
   On Tue, 2015-08-25 at 11:42 +0100, Mark Rutland wrote:
  Are you then going to hack GRUB, release a special HiKey version of
  GRUB, not support any other versions, and still can your firmware
  UEFI?
 
 I don't need to hack GRUB at all.

Then it is working for you by pure chance alone.

Please listen to the advice you are being given here; we're trying to
ensure that your platform functions (and continues to function) as best
it can.
   
   Since we discussed a lot on this, let's make a conclusion on it.
   
   1. UEFI could append the reserved buffer in it's memory mapping.
   2. These reserved buffer must be declared in DT, since we also need to
  support non-UEFI (uboot) at the same time.
   3. Mailbox node should reference reserved buffer by phandle in DT. Then
  map the buffer as non-cacheable in driver.
   4. These reserved buffer must use no-map property since it should be
  non-cacheable in driver.
  
  For more specific discussion for DTS, i list two options at here;
  
  - Option 1: just simply reserve memory regions through memory node,
and mailbox node will directly use the buffer through reg ranges;
  
  - Option 2: use reserved-memory and mailbox node will refer phandle
of reserved-memory;
  
  These two options both can work well with UEFI and Uboot, but option 1
  is more simple and straightforward; so i personally prefer it. But
  look forwarding your guys' suggestion.
  
  Option 1:
  
  memory@0 {
  device_type = memory;
  reg = 0x 0x 0x 0x05e0,
0x 0x05f0 0x 0x00eff000,
0x 0x06e0 0x 0x0060f000,
0x 0x0741 0x 0x38bf;
  };
  
  [...]
  
  mailbox: mailbox@f751 {
  #mbox-cells = 1;
  compatible = hisilicon,hi6220-mbox;
  reg = 0x0 0xf751 0x0 0x1000, /* IPC_S */
0x0 0x06dff800 0x0 0x0800; /* Mailbox buffer */
  interrupts = GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH;
  };
  
  Option 2:
  
  memory@0 {
  device_type = memory;
  reg = 0x0 0x0 0x0 0x4000;
  };
  
  reserved-memory {
  #address-cells = 2;
  #size-cells = 2;
  ranges;
  
  mcu_reserved: mcu_reserved@06dff000 {
  no-map;
  reg = 0x0 0x06dff000 0x0 0x1000,  /* MCU mailbox 
  buffer */
0x0 0x05e0 0x0 0x0010,  /* MCU firmware 
  buffer */
0x0 0x0740f000 0x0 0x1000;  /* MCU firmware 
  section */
  };
  };
  
  [...]
  
  mailbox: mailbox@f751 {
  #mbox-cells = 1;
  compatible = hisilicon,hi6220-mbox;
  reg = 0x0 0xf751 0x0 0x1000; /* IPC_S */
  memory-region = mcu_reserved;   /* Mailbox buffer */
  interrupts = GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH;
  };
 
 I prefer the second one. From my view, memory node should only describe
 the hardware information of memory.

Yes, option 2 will be more simple for memory node.

But option 2 also will introduce complexity for mailbox node, due mailbox
driver need use property reg and memory-region to sepeately depict
the regions for mailbox's ipc and slots. If later mailbox is designed to
use SRAM for both ipc and slots, then it will no matter with DDR anymore,
in this case option 1 will easily switch to support it.

Another question is a general question: for Linux kernel, which is the
best method to reserve memory regions? According to previous discussion,
we can use /memory/ node or /reseved-memory/ node to reserve memory
regions.

when review Juno's dts, i also see there have reserved 16MB DDR for secure
world. If so, looks like /reserved-memory/ node is unnecessary. if have some
specific scenarios will we use reserved-memory node to help reserve memory
regions?

Thanks,
Leo Yan
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver

2015-08-26 Thread Pi-Cheng Chen

On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 26-08-15, 09:25, Pi-Cheng Chen wrote:
 The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which
 introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will
 cause some conflicts if it goes through your tree. I am not sure how this
 should be handled, but should it be merged through Mediatek SoC maintainer
 tree?

 Just get that applied to MTK tree, it doesn't have any dependency on
 rest of the patches for build/boot. The only thing is that cpufreq
 wouldn't work and it will work as soon as Rafael's and MTK's trees are
 merged by Linus.

Thanks for your explanation.

@Rafael, Would you please apply [1,2] to your tree?

@Matthias, Would you please apply [3/3] of this series?

Thanks.

Best Regards,
Pi-Cheng


 --
 viresh
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH 1/2] dt-bindings: drm/mediatek: Add Mediatek DRM dts binding

2015-08-26 Thread Philipp Zabel

Hi,

overall it looks to me like this binding is modeled after the Linux DRM
abstractions. Instead, the device nodes should be modeled after the
hardware.

Describing each function block as a separate device node is probably not
the best choice, as would be combining all devices in the mmsys range
into a single device node. So a somewhat arbitrary decision has to be
made what to group together. See my comments below:

Am Mittwoch, den 13.05.2015, 23:23 +0800 schrieb CK Hu:
 This patch includes
 1. Mediatek DRM Device binding
 2. Mediatek DSI Device binding
 3. Mediatek CRTC Main Device binding
 4. Mediatek DDP Device binding
 
 Signed-off-by: CK Hu ck...@mediatek.com
 ---
  .../bindings/drm/mediatek/mediatek,crtc-main.txt   | 38 
 ++
  .../bindings/drm/mediatek/mediatek,ddp.txt | 22 +
  .../bindings/drm/mediatek/mediatek,drm.txt | 27 +++
  .../bindings/drm/mediatek/mediatek,dsi.txt | 20 
  4 files changed, 107 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/drm/mediatek/mediatek,crtc-main.txt
  create mode 100644 
 Documentation/devicetree/bindings/drm/mediatek/mediatek,ddp.txt
  create mode 100644 
 Documentation/devicetree/bindings/drm/mediatek/mediatek,drm.txt
  create mode 100644 
 Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt
 
 diff --git 
 a/Documentation/devicetree/bindings/drm/mediatek/mediatek,crtc-main.txt 
 b/Documentation/devicetree/bindings/drm/mediatek/mediatek,crtc-main.txt
 new file mode 100644
 index 000..5c6c420
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/drm/mediatek/mediatek,crtc-main.txt
 @@ -0,0 +1,38 @@
 +Mediatek CRTC Main Device
 +
 +
 +The Mediatek CRTC Main device is a crtc device of DRM system.

crtc does not belong in the device tree. There is no crtc hardware.
What this node describes is a useful, but fixed configuration of a part
of the DISP subsystem function blocks.

In my opinion, it would be better to not describe the separate display
pipes in the device tree at all if they are dynamically configurable.
What for example if you model two separate fixed pipelines in the device
tree and then in the future you want to support the MERGE or SPLIT
blocks (I'm not sure what MERGE does, SPLIT seems to be needed for
8-lane DSI)?

As far as I currently understand, there are five source function blocks
that can read from memory (OVL0, OVL1, RDMA0, RDMA1, RDMA2) and three
sink function blocks (DSI0, DSI1, DPI0) that can be connected to panels,
or encoder bridges. How these map to the crtcs doesn't necessarily have
to be described in the device tree.

How about a single node that contains all of the DISP functional blocks
that don't need their own node (like DSI, which has to be connectable to
bridges or panels):

disp: disp@0x1400c000 {
compatible = mediatek,mt8173-disp;
interrupts = GIC_SPI 180 IRQ_TYPE_LEVEL_LOW, /* OVL0 */
 GIC_SPI 181 IRQ_TYPE_LEVEL_LOW; /* OVL1 */
interrupt-names = ovl0, ovl1;
reg = 0 0x1400c000 0 0x1000,  /* OVL0 */
  0 0x1400d000 0 0x1000,  /* OVL1 */
  0 0x1400e000 0 0x1000,  /* RDMA0 */
  0 0x1400f000 0 0x1000,  /* RDMA1 */
  0 0x1401 0 0x1000,  /* RDMA2 */
  0 0x14013000 0 0x1000,  /* COLOR0 */
  0 0x14014000 0 0x1000,  /* COLOR1 */
  0 0x14015000 0 0x1000,  /* AAL */
  0 0x14016000 0 0x1000,  /* GAMMA */
  0 0x14017000 0 0x1000,  /* MERGE */
  0 0x14018000 0 0x1000,  /* SPLIT0 */
  0 0x14019000 0 0x1000,  /* SPLIT1 */
  0 0x1401a000 0 0x1000,  /* UFOE */
  0 0x1402 0 0x1000;  /* MUTEX */
  0 0x14023000 0 0x1000;  /* OD */
reg-names = ovl0, ovl1, rdma0, rdma1, rdma2,
color0, color1, aal, gamma, merge,
split0, split1, ufoe, mutex, od;
clocks = mmsys CLK_MM_DISP_OVL0,
 mmsys CLK_MM_DISP_OVL1,
 mmsys CLK_MM_DISP_RDMA0,
 mmsys CLK_MM_DISP_RDMA1,
 mmsys CLK_MM_DISP_RDMA2,
 mmsys CLK_MM_DISP_COLOR0,
 mmsys CLK_MM_DISP_COLOR1,
 mmsys CLK_MM_DISP_AAL,
 mmsys CLK_MM_DISP_GAMMA,
 mmsys CLK_MM_DISP_MERGE,
 mmsys CLK_MM_DISP_SPLIT0,
 mmsys CLK_MM_DISP_SPLIT1,
 mmsys CLK_MM_DISP_UFOE,
 mmsys CLK_MM_MUTEX_32K,
 mmsys CLK_MM_DISP_OD;
clock-names = ovl0, ovl1, rdma0, rdma1, rdma2,
color0, color1, aal, gamma, merge,
split0, split1, ufoe, mutex, od;
power-domains = scpsys MT8173_POWER_DOMAIN_DIS;
config = mmsys; /* syscon */
};

How the muxes in the config area are set up to connect those blocks
could be determined by the driver.

 +Required properties:
 +-

Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

2015-08-26 Thread Brian Norris

On Wed, Aug 26, 2015 at 08:47:37AM -0700, vikas wrote:
 On 08/25/2015 11:19 PM, Marek Vasut wrote:
  On Wednesday, August 26, 2015 at 12:09:50 AM, vikas wrote:
  the patch failed to apply, please rebase it to master.
  
  it's based on -next, I'm sure you can fix trivial conflicts yourself if you
  need to apply it elsewhere. Do you have any other review comments ?
 
 Always rebase the patch on master.

Development works against -next, not Linus' master:

https://lwn.net/Articles/289013/

This is also noted here:

https://www.kernel.org/doc/man-pages/linux-next.html

Technically, you should work off of the respective subsystem tree (see
entries in MAINTAINERS). For MTD, this is also documented here:

http://linux-mtd.infradead.org/source.html

In the end, most MTD patches get applied to l2-mtd.git, but l2-mtd.git
and linux-next.git should provide pretty similar MTD patching
experiences, as the former is included in the latter.

Regards,
Brian
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

2015-08-26 Thread Nathan Lynch

On 08/26/2015 08:08 AM, Lee Jones wrote:
 diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt 
 b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
 new file mode 100644
 index 000..6a933c1
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
 @@ -0,0 +1,38 @@
 +STMicroelectronics Remote Processor
 +---
 +
 +This binding provides support for adjunct processors found on ST SoCs.
 +
 +The remote processors can be controlled from the bootloader or the primary 
 OS.
 +If the bootloader starts a remote processor processor the primary OS must 
 detect
 +its state and act accordingly.
 +
 +The node name is significant, as it defines the name of the CPU and the name
 +of the firmware to load: rproc-name-fw.

This business about the firmware name describes a behavior of Linux's
core remoteproc code and seems out of place in a binding document.

--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/irq: export of_get_irq_byname()

2015-08-26 Thread Wolfram Sang

On Tue, Aug 25, 2015 at 05:04:02PM -0700, Dmitry Torokhov wrote:
 Similarly to of_get_irq(), let's export of_irq_get_byname(), so if a bus core
 can be compiled as a module (such as I2C) it can have access to the symbol.
 
 Reported-by: Stephen Rothwell s...@canb.auug.org.au
 Reported-by: kbuild test robot fengguang...@intel.com
 Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com

Applied to for-next, thanks!



signature.asc
Description: Digital signature

Re: [PATCH 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs

2015-08-26 Thread Nathan Lynch

On 08/26/2015 08:08 AM, Lee Jones wrote:
 Signed-off-by: Lee Jones lee.jo...@linaro.org
 ---
  drivers/remoteproc/remoteproc_debugfs.c | 25 +
  1 file changed, 25 insertions(+)

The commit message should describe why this is needed...


 diff --git a/drivers/remoteproc/remoteproc_debugfs.c 
 b/drivers/remoteproc/remoteproc_debugfs.c
 index 9d30809..9620962 100644
 --- a/drivers/remoteproc/remoteproc_debugfs.c
 +++ b/drivers/remoteproc/remoteproc_debugfs.c
 @@ -88,8 +88,33 @@ static ssize_t rproc_state_read(struct file *filp, char 
 __user *userbuf,
   return simple_read_from_buffer(userbuf, count, ppos, buf, i);
  }
  
 +static ssize_t rproc_state_write(struct file *filp, const char __user 
 *userbuf,
 +  size_t count, loff_t *ppos)
 +{
 + struct rproc *rproc = filp-private_data;
 + char buf[2];
 + int ret;
 +
 + ret = copy_from_user(buf, userbuf, 1);
 + if (ret)
 + return -EFAULT;
 +
 + switch (buf[0]) {
 + case '1':
 + ret = rproc_boot(rproc);
 + if (ret)
 + dev_warn(rproc-dev, Boot failed: %d\n, ret);
 + break;
 + default:
 + rproc_shutdown(rproc);
 + }
 +
 + return count;
 +}

... and I suggest that the user interface be reconsidered.  If '1' means
boot and literally anything else means shut down then you can't add
operations in the future without potentially breaking things.

--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux-next v5 5/5] mtd: atmel-quadspi: add driver for Atmel QSPI controller

2015-08-26 Thread Marek Vasut

On Wednesday, August 26, 2015 at 02:30:27 PM, Cyrille Pitchen wrote:
 This driver add support to the new Atmel QSPI controller embedded into
 sama5d2x SoCs. It expects a NOR memory to be connected to the QSPI
 controller.
 
 Signed-off-by: Cyrille Pitchen cyrille.pitc...@atmel.com
 Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

Acked-by: Marek Vasut ma...@denx.de

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-08-26 Thread Stefan Agner

On 2015-08-25 12:54, Brian Norris wrote:
 On Mon, Aug 03, 2015 at 11:28:43AM +0200, Stefan Agner wrote:
 On 2015-08-03 11:27, Stefan Agner wrote:
 snip
  +static inline int vf610_nfc_correct_data(struct mtd_info *mtd, uint8_t 
  *dat,
  +   uint8_t *oob, int oob_loaded)
  +{
  +  struct vf610_nfc *nfc = mtd_to_nfc(mtd);
  +  u8 ecc_status;
  +  u8 ecc_count;
  +  int flip;
  +
  +  ecc_status = __raw_readb(nfc-regs + ECC_SRAM_ADDR * 8 + ECC_OFFSET);
 
 Why __raw_readb()? That's not normally encourage, and it has issues with
 endianness. It looks like maybe this is actulaly a 32-bit register, and
 you're having trouble when trying to do bytewise access? I see this
 earlier:
 
 /*
  * ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
  * and +7 for big-endian SoCs.
  */
 #ifdef __LITTLE_ENDIAN
 #define ECC_OFFSET  4
 #else
 #define ECC_OFFSET  7
 #endif
 
 So maybe you really just want:
 
 #define ECC_OFFSET4
 ...
   ecc_status = vf610_nfc_read(ECC_SRAM_ADDR * 8 + ECC_OFFSET)  0xff;
 
 ?
 

Agreed, much cleaner.

  +  ecc_count = ecc_status  ECC_ERR_COUNT;
  +
  +  if (!(ecc_status  ECC_STATUS_MASK))
  +  return ecc_count;
  +
  +  if (!oob_loaded)
  +  vf610_nfc_read_buf(mtd, oob, mtd-oobsize);
  +
  +  /*
  +   * On an erased page, bit count (including OOB) should be zero or
  +   * at least less then half of the ECC strength.
  +   */
  +  flip = count_written_bits(dat, nfc-chip.ecc.size, ecc_count);
 
 Another side note: why are you using ecc_count as a max threshold? AIUI,
 an ECC algorithm doesn't really report useful error count information if
 it's above the correction limit. So wouldn't we be looking to count up
 to our SW threshold? i.e., ecc.strength / 2, or similar? Similar
 comments below.
 

Initially, that was the only threshold below, hence it made sense. But I
agree, we should count up to the threshold used below...

  +  flip += count_written_bits(oob, mtd-oobsize - nfc-chip.ecc.bytes,
  + ecc_count);

 With ECC the controller seems to clear the ECC bytes in SRAM buffer.
 This is a dump of 64 Bit OOB with the 32-error ECC mode which requires
 60 bytes of OOB for ECC:

 [   22.190273] ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 
 Hmm, that's not really good. The point is that we need to make sure that
 everything that could have been programmed (including the ECC area) was
 not actually programmed. But your ECC controller is not, contrary to
 MTD's expectations, dumping raw uncorrected data here.
 
 [   22.209698] vf610_nfc_correct_data, flips 1

 Not sure if this is acceptable, but I now only count the bits in the
 non-ECC area of the OOB.
 
 That's not the intention of my suggestion. You're still missing out on a
 class of patterns that might look close to all 0xff but are not
 actually.
 
 If the HW ECC really doesn't give you valid data+OOB at this point, then
 you might have to re-read with ECC disabled. Of course, that's got a
 performance cost...

Yes I can do that. Not sure yet how it will look like exactly, maybe I
only need to reread the OOB area and (re-)use the main data part since
those arrive uncorrected in the error case.

 
 Or perhaps Boris has a better suggestion? He's been surveying other NAND
 drivers that need to do similar things, and he's working on providing
 some support code for common design patterns.
 
 Btw, if the ECC check fails, the controller seems kind of count the
 amount of bitflips. It works for most devices reliable, but we had
 devices for which that number was not accurate, see:
 http://thread.gmane.org/gmane.linux.ports.arm.kernel/357439
 
 I'm a little confused there. Why would you be expecting to get a count
 of bitflips, when the ECC engine can't correct all errors? How is it
 supposed to know what the right data is if the bit errors are beyond
 the correction strength?

When printing the ECC error count on ECC fail when reading an erased
NAND flash, the numbers of bit flips (stuck at zero) seem to widely
correlate with the number returned by the controller. While it seems to
correlate widely, there are exceptions, as discussed in the thread:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/295424

Maybe this is an artifact of the ECC algorithm we just can't/shouldn't
rely on? I am not sure where this originated, I did not found any
indication in the reference manual about what that value contains in the
error case.

Bill, do you have an idea why we used that value as threshold in early
implementations?

Otherwise I also think we should just drop the use of this value.

--
Stefan
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

2015-08-26 Thread Marek Vasut

On Wednesday, August 26, 2015 at 05:47:37 PM, vikas wrote:
 Hi,

Hi,

 On 08/25/2015 11:19 PM, Marek Vasut wrote:
  On Wednesday, August 26, 2015 at 12:09:50 AM, vikas wrote:
  Hi,
  
  On 08/21/2015 02:20 AM, Marek Vasut wrote:
  From: Graham Moore grmo...@opensource.altera.com
  
  Add support for the Cadence QSPI controller. This controller is
  present in the Altera SoCFPGA SoCs and this driver has been tested
  on the Cyclone V SoC.
  
  Signed-off-by: Graham Moore grmo...@opensource.altera.com
  Signed-off-by: Marek Vasut ma...@denx.de
  Cc: Alan Tull at...@opensource.altera.com
  Cc: Brian Norris computersforpe...@gmail.com
  Cc: David Woodhouse dw...@infradead.org
  Cc: Dinh Nguyen dingu...@opensource.altera.com
  Cc: Graham Moore grmo...@opensource.altera.com
  Cc: Vikas MANOCHA vikas.mano...@st.com
  Cc: Yves Vandervennet yvand...@opensource.altera.com
  Cc: devicetree@vger.kernel.org
  ---
  
   drivers/mtd/spi-nor/Kconfig   |   11 +
   drivers/mtd/spi-nor/Makefile  |1 +
   drivers/mtd/spi-nor/cadence-quadspi.c | 1260
   + 3 files changed, 1272 insertions(+)
   create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c
  
  V2: use NULL instead of modalias in spi_nor_scan call
  V3: Use existing property is-decoded-cs instead of creating duplicate.
  V4: Support Micron quad mode by snooping command stream for EVCR
  command
  
  and subsequently configuring Cadence controller for quad mode.
  
  V5: Clean up sparse and smatch complaints.  Remove snooping of Micron
  
  quad mode.  Add comment on XIP mode bit and dummy clock cycles. 
  Set up SRAM partition at 1:1 during init.
  
  V6: Remove dts patch that was included by mistake.  Incorporate Vikas's
  
  comments regarding fifo width, SRAM partition setting, and trigger
  address.  Trigger address was added as an unsigned int, as it is
  not an IO resource per se, and does not need to be mapped. Also
  add Marek Vasut's workaround for picking up OF properties on
  subnodes.
  
  V7: - Perform coding-style cleanup and type fixes. Remove ugly QSPI_*()
  
macros and replace them with functions. Get rid of unused
variables.
  
  - Implement support for nor-set_protocol() to handle Quad-command,
  
this patch now depends on the following patch:
mtd: spi-nor: notify (Q)SPI controller about protocol change
  
  - Replace that cqspi_fifo_read() disaster with plain old readsl()
  
and cqspi_fifo_write() tentacle horror with pretty writesl().
  
  - Remove CQSPI_SUPPORT_XIP_CHIPS, which is broken.
  - Get rid of cqspi_find_chipselect() mess, instead just place the
  
struct cqspi_st and chipselect number into struct
cqspi_flash_pdata and set nor-priv to the struct
cqspi_flash_pdata of that particular chip.
  
  - Replace the odd math in calculate_ticks_for_ns() with
  DIV_ROUND_UP(). - Make variables const where applicable.
  
  V8: - Implement a function to wait for bit being set/unset for a given
  
period of time and use it to replace the ad-hoc bits of code.
  
  - Configure the write underflow watermark to be 1/8 if FIFO size.
  - Extract out the SPI NOR flash probing code into separate function
  
to clearly mark what will soon be considered a boilerplate code.
  
  - Repair the handling of mode bits, which caused instability in V7.
  - Clean up the interrupt handling
  - Fix Kconfig help text and make the patch depend on OF and
  COMPILE_TEST.
  
  diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
  index 89bf4c1..ed253a2 100644
  --- a/drivers/mtd/spi-nor/Kconfig
  +++ b/drivers/mtd/spi-nor/Kconfig
  @@ -40,4 +40,15 @@ config SPI_NXP_SPIFI
  
Flash. Enable this option if you have a device with a SPIFI
controller and want to access the Flash as a mtd device.
  
  +config SPI_CADENCE_QUADSPI
  +   tristate Cadence Quad SPI controller
  +   depends on OF  COMPILE_TEST
  +   help
  + Enable support for the Cadence Quad SPI Flash controller.
  +
  + Cadence QSPI is a specialized controller for connecting an
  SPI + Flash over 1/2/4-bit wide bus. Enable this option if you
  have a + device with a Cadence QSPI controller and want to
  access the + Flash as an MTD device.
  +
  
  the patch failed to apply, please rebase it to master.
  
  it's based on -next, I'm sure you can fix trivial conflicts yourself if
  you need to apply it elsewhere. Do you have any other review comments ?
 
 Always rebase the patch on master.

The patch applies correctly both on next/master and l2-mtd/master.
I think the problem is on your end.

 I will be reviewing the patchset this week but on a quick look it seems
 many review comments of v7 are not there.

Aha.
--
To unsubscribe from this list: send the line unsubscribe devicetree

Re: [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

2015-08-26 Thread vikas

Hi,

On 08/25/2015 11:19 PM, Marek Vasut wrote:
 On Wednesday, August 26, 2015 at 12:09:50 AM, vikas wrote:
 Hi,

 On 08/21/2015 02:20 AM, Marek Vasut wrote:
 From: Graham Moore grmo...@opensource.altera.com

 Add support for the Cadence QSPI controller. This controller is
 present in the Altera SoCFPGA SoCs and this driver has been tested
 on the Cyclone V SoC.

 Signed-off-by: Graham Moore grmo...@opensource.altera.com
 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Alan Tull at...@opensource.altera.com
 Cc: Brian Norris computersforpe...@gmail.com
 Cc: David Woodhouse dw...@infradead.org
 Cc: Dinh Nguyen dingu...@opensource.altera.com
 Cc: Graham Moore grmo...@opensource.altera.com
 Cc: Vikas MANOCHA vikas.mano...@st.com
 Cc: Yves Vandervennet yvand...@opensource.altera.com
 Cc: devicetree@vger.kernel.org
 ---

  drivers/mtd/spi-nor/Kconfig   |   11 +
  drivers/mtd/spi-nor/Makefile  |1 +
  drivers/mtd/spi-nor/cadence-quadspi.c | 1260
  + 3 files changed, 1272 insertions(+)
  create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c

 V2: use NULL instead of modalias in spi_nor_scan call
 V3: Use existing property is-decoded-cs instead of creating duplicate.
 V4: Support Micron quad mode by snooping command stream for EVCR command

 and subsequently configuring Cadence controller for quad mode.

 V5: Clean up sparse and smatch complaints.  Remove snooping of Micron

 quad mode.  Add comment on XIP mode bit and dummy clock cycles.  Set
 up SRAM partition at 1:1 during init.

 V6: Remove dts patch that was included by mistake.  Incorporate Vikas's

 comments regarding fifo width, SRAM partition setting, and trigger
 address.  Trigger address was added as an unsigned int, as it is not
 an IO resource per se, and does not need to be mapped. Also add
 Marek Vasut's workaround for picking up OF properties on subnodes.

 V7: - Perform coding-style cleanup and type fixes. Remove ugly QSPI_*()

   macros and replace them with functions. Get rid of unused
   variables.
 
 - Implement support for nor-set_protocol() to handle Quad-command,
 
   this patch now depends on the following patch:
   mtd: spi-nor: notify (Q)SPI controller about protocol change
 
 - Replace that cqspi_fifo_read() disaster with plain old readsl()
 
   and cqspi_fifo_write() tentacle horror with pretty writesl().
 
 - Remove CQSPI_SUPPORT_XIP_CHIPS, which is broken.
 - Get rid of cqspi_find_chipselect() mess, instead just place the
 
   struct cqspi_st and chipselect number into struct cqspi_flash_pdata
   and set nor-priv to the struct cqspi_flash_pdata of that
   particular chip.
 
 - Replace the odd math in calculate_ticks_for_ns() with
 DIV_ROUND_UP(). - Make variables const where applicable.

 V8: - Implement a function to wait for bit being set/unset for a given

   period of time and use it to replace the ad-hoc bits of code.
 
 - Configure the write underflow watermark to be 1/8 if FIFO size.
 - Extract out the SPI NOR flash probing code into separate function
 
   to clearly mark what will soon be considered a boilerplate code.
 
 - Repair the handling of mode bits, which caused instability in V7.
 - Clean up the interrupt handling
 - Fix Kconfig help text and make the patch depend on OF and
 COMPILE_TEST.

 diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
 index 89bf4c1..ed253a2 100644
 --- a/drivers/mtd/spi-nor/Kconfig
 +++ b/drivers/mtd/spi-nor/Kconfig
 @@ -40,4 +40,15 @@ config SPI_NXP_SPIFI

   Flash. Enable this option if you have a device with a SPIFI
   controller and want to access the Flash as a mtd device.

 +config SPI_CADENCE_QUADSPI
 +   tristate Cadence Quad SPI controller
 +   depends on OF  COMPILE_TEST
 +   help
 + Enable support for the Cadence Quad SPI Flash controller.
 +
 + Cadence QSPI is a specialized controller for connecting an SPI
 + Flash over 1/2/4-bit wide bus. Enable this option if you have a
 + device with a Cadence QSPI controller and want to access the
 + Flash as an MTD device.
 +

 the patch failed to apply, please rebase it to master.
 
 it's based on -next, I'm sure you can fix trivial conflicts yourself if you
 need to apply it elsewhere. Do you have any other review comments ?

Always rebase the patch on master.
I will be reviewing the patchset this week but on a quick look it seems many 
review comments of v7 are not there.

Cheers,
Vikas

 .
 
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

On Wed, 26 Aug 2015, Nathan Lynch wrote:

 On 08/26/2015 08:08 AM, Lee Jones wrote:
  diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt 
  b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
  new file mode 100644
  index 000..6a933c1
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
  @@ -0,0 +1,38 @@
  +STMicroelectronics Remote Processor
  +---
  +
  +This binding provides support for adjunct processors found on ST SoCs.
  +
  +The remote processors can be controlled from the bootloader or the primary 
  OS.
  +If the bootloader starts a remote processor processor the primary OS must 
  detect
  +its state and act accordingly.
  +
  +The node name is significant, as it defines the name of the CPU and the 
  name
  +of the firmware to load: rproc-name-fw.
 
 This business about the firmware name describes a behavior of Linux's
 core remoteproc code and seems out of place in a binding document.

Agreed, will remove.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] remoteproc: Supply controller driver for ST's Remote Processors

2015-08-26 Thread Nathan Lynch

On 08/26/2015 08:08 AM, Lee Jones wrote:
 --- /dev/null
 +++ b/drivers/remoteproc/st_remoteproc.c
 @@ -0,0 +1,300 @@
 +/*
 + * ST's Remote Processor Control Driver
 + *
 + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
 + *
 + * Author: Ludovic Barre ludovic.ba...@st.com

When submitting code you didn't write, I'd say it's better practice to
clearly indicate its provenance in the commit message.  E.g. something
like Driver based on code authored by Ludovic Barre for ST.  And
obtain signoffs etc if possible.


 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License.

Please review the wording here.  It's unclear whether this is intended
to be v2-only or v2 or later.


 +static int st_rproc_stop(struct rproc *rproc)
 +{
 + struct st_rproc *st_rproc = rproc-priv;
 + int err = 0;
 +
 + if (st_rproc-config-sw_reset) {
 + err = reset_control_assert(st_rproc-sw_reset);
 + if (err)
 + dev_warn(rproc-dev, Failed to assert S/W Reset\n);
 + }
 +
 + if (st_rproc-config-pwr_reset) {
 + err = reset_control_assert(st_rproc-pwr_reset);
 + if (err)
 + dev_warn(rproc-dev, Failed to assert Power Reset\n);
 + }
 +
 + clk_disable(st_rproc-clk);
 +
 + return 0;
 +}

Seems like st_rproc_stop should propagate errors back to its caller
instead of always returning 0.

--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 3/5] mtd: nand: vf610_nfc: add device tree bindings

2015-08-26 Thread Stefan Agner

On 2015-08-26 08:39, Boris Brezillon wrote:
Hi Bill,

On Wed, 26 Aug 2015 11:26:36 -0400
Bill Pringlemeir bprin...@sympatico.ca wrote:

On 25 Aug 2015, computersforpe...@gmail.com wrote:

Sorry, I realized a potential issue here.

On Mon, Aug 03, 2015 at 11:27:28AM +0200, Stefan Agner wrote:
Signed-off-by: Bill Pringlemeir bpringlem...@nbsps.com
Acked-by: Shawn Guo shawn...@kernel.org
Reviewed-by: Brian Norris computersforpe...@gmail.com
Signed-off-by: Stefan Agner ste...@agner.ch
---
.../devicetree/bindings/mtd/vf610-nfc.txt | 45 ++
1 file changed, 45 insertions(+) create mode 100644
Documentation/devicetree/bindings/mtd/vf610-nfc.txt

diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..cae5f25
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
-0,0 +1,45 @@
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+- nand-on-flash-bbt: see nand.txt

Stumbling across the multi-CS questions on the driver reminds me: it
typically makes sense to define new NAND bindings using separate NAND
*controller* and *flash* device nodes. The above 3 properties, at
least, would apply on a per-flash basis, not per-controller
typically. See sunxi-nand, for instance:

http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt

brcmnand had a similar pattern:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt

(Perhaps it's time we standardized this a little more formally...)

These would apply per chip, but the controller has to be configured to
support each and every one. Every time an operation was performed, we
would have to check the chip type and reconfigure the controller.
Currently, the driver does not support this and it would add a lot of
overhead in some cases unless a register cache was used.

Is the flexibility of using a system with combined 8/16bit devices
really worth all the overhead? Isn't it sort of brain dead hardware not
to make all of the chips similar? Why would everyone have to pay for
such a crazy setup?

To separate it would at least be a lie versus the code in the current
form. As well, there are only a few SOC which support multiple chip
selects. The 'multi-CS' register bits of this controller varies between
PowerPC, 68K/Coldfire and ARM platforms.

The DT can be a lie versus the code. The DT should reflect how the
hardware is wired, afaik, if we take shortcuts in the driver code, that
is fine. If we don't support a certain configuration right now (e.g.
second NAND chip), the driver can just return an appropriate error code.

I looked briefly at the brcmnand.c and it seems that it is not
supporting different ECC per chip even though the nodes are broken out
this way. In fact, if some raw functions are called, I think it will
put it in ECC mode even if it wasn't before? Well, I agree that this
would be good generically, I think it puts a lot of effort in the
drivers for not so much payoff?

Hm, the sunxi driver supports it, and it does not add such a big
overhead...
The only thing you have to do is cache a bunch of register values
per-chip and restore/apply them when the chip is selected
(in your -select_chip() implementation).

Anyway, even if the suggested DT representation is a lie in regards to
your implementation, it's actually pretty accurate from an hardware
POV, and this is exactly what DT is supposed to represent.

I agree with both of you. I don't see much value implementing multi-NAND
chip support, especially with different configurations, at the moment. I
am not aware of any hardware making use of that now.

I will update the driver to parse a NAND sub node and get the ECC
properties from the per flash configuration. However, I won't add chip
select or multi-NAND support right now...

Any objection?

--
Stefan
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 3/5] mtd: nand: vf610_nfc: add device tree bindings

2015-08-26 Thread Brian Norris

On Wed, Aug 26, 2015 at 02:15:45PM -0700, Stefan Agner wrote:
 On 2015-08-26 08:39, Boris Brezillon wrote:
  On Wed, 26 Aug 2015 11:26:36 -0400
  Bill Pringlemeir bprin...@sympatico.ca wrote:
  These would apply per chip, but the controller has to be configured to
  support each and every one.  Every time an operation was performed, we
  would have to check the chip type and reconfigure the controller.
  Currently, the driver does not support this and it would add a lot of
  overhead in some cases unless a register cache was used.
 
  Is the flexibility of using a system with combined 8/16bit devices
  really worth all the overhead?  Isn't it sort of brain dead hardware not
  to make all of the chips similar?  Why would everyone have to pay for
  such a crazy setup?
 
  To separate it would at least be a lie versus the code in the current
  form.  As well, there are only a few SOC which support multiple chip
  selects.  The 'multi-CS' register bits of this controller varies between
  PowerPC, 68K/Coldfire and ARM platforms.
 
 The DT can be a lie versus the code. The DT should reflect how the
 hardware is wired, afaik, if we take shortcuts in the driver code, that
 is fine. If we don't support a certain configuration right now (e.g.
 second NAND chip), the driver can just return an appropriate error code.

Right, I was only asking for:
(1) a more accurate DT and
(2) clarity in the driver; the clarity might just be we don't support
multi-CS

  I looked briefly at the brcmnand.c  and it seems that it is not
  supporting different ECC per chip even though the nodes are broken out
  this way.  In fact, if some raw functions are called, I think it will
  put it in ECC mode even if it wasn't before?  Well, I agree that this
  would be good generically, I think it puts a lot of effort in the
  drivers for not so much payoff?
  
  Hm, the sunxi driver supports it, and it does not add such a big
  overhead...
  The only thing you have to do is cache a bunch of register values
  per-chip and restore/apply them when the chip is selected
  (in your -select_chip() implementation).
  
  Anyway, even if the suggested DT representation is a lie in regards to
  your implementation, it's actually pretty accurate from an hardware
  POV, and this is exactly what DT is supposed to represent.
 
 I agree with both of you. I don't see much value implementing multi-NAND
 chip support, especially with different configurations, at the moment. I
 am not aware of any hardware making use of that now.
 
 I will update the driver to parse a NAND sub node and get the ECC
 properties from the per flash configuration. However, I won't add chip
 select or multi-NAND support right now...
 
 Any objection?

Nope, sounds good to me.

A few tips:
 * be defensive; i.e., error out if someone specifies 2 flash in the DT
 * use the 'reg' property to be the addressing index in the flash
   sub-node; i.e., the chip-select. This fits the practice done by most
   others, I think.

Regards,
Brian
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 4/5] xhci: mediatek: support MTK xHCI host controller

2015-08-26 Thread Daniel Thompson


On 22/08/15 02:45, Chunfeng Yun wrote:

MTK xhci host controller defines some extra SW scheduling
parameters for HW to minimize the scheduling effort for
synchronous and interrupt endpoints. The parameters are
put into reseved DWs of slot context and endpoint context


According to the covering e-mail there are additional quirks beyond the 
scheduling algorithm. These should probably be mentioned here also (so 
that they end up in the changelog).





Signed-off-by: Chunfeng Yun chunfeng@mediatek.com
---
  drivers/usb/host/Kconfig|   9 +
  drivers/usb/host/Makefile   |   4 +
  drivers/usb/host/xhci-mtk-sch.c | 436 +
  drivers/usb/host/xhci-mtk.c | 831 
  drivers/usb/host/xhci-mtk.h | 133 +++
  drivers/usb/host/xhci-ring.c|  35 +-
  drivers/usb/host/xhci.c |  19 +-
  drivers/usb/host/xhci.h |   1 +
  8 files changed, 1461 insertions(+), 7 deletions(-)
  create mode 100644 drivers/usb/host/xhci-mtk-sch.c
  create mode 100644 drivers/usb/host/xhci-mtk.c
  create mode 100644 drivers/usb/host/xhci-mtk.h

[snip]

diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
new file mode 100644
index 000..d4b41a6
--- /dev/null
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -0,0 +1,436 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author:
+ *  Zhigang.Wei zhigang@mediatek.com
+ *  Chunfeng.Yun chunfeng@mediatek.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+
+#include xhci.h
+#include xhci-mtk.h
+
+#define SS_BW_BOUNDARY 51000
+/* table 5-5. High-speed Isoc Transaction Limits in usb_20 spec */
+#define HS_BW_BOUNDARY 6144
+/* usb2 spec section11.18.1: at most 188 FS bytes per microframe */
+#define FS_PAYLOAD_MAX 188
+
+/* mtk scheduler bitmasks */
+#define EP_BPKTS(p)((p)  0x3f)
+#define EP_BCSCOUNT(p) (((p)  0x7)  8)
+#define EP_BBM(p)  ((p)  11)
+#define EP_BOFFSET(p)  ((p)  0x3fff)
+#define EP_BREPEAT(p)  (((p)  0x7fff)  16)
+
+static int is_fs_or_ls(enum usb_device_speed speed)
+{
+   return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
+}


This function is only used three times (and one of the uses would have 
been a switch statement except for needing to make this function call). 
Does it really make code clearer?




+
+static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
+   struct usb_host_endpoint *ep)
+{
+   int bw_index;
+   int port_id;
+   struct xhci_virt_device *virt_dev;
+
+   virt_dev = xhci-devs[udev-slot_id];
+   port_id = virt_dev-real_port;
+
+   if (udev-speed == USB_SPEED_SUPER) {
+   if (usb_endpoint_dir_out(ep-desc))
+   bw_index = (port_id - 1) * 2;
+   else
+   bw_index = (port_id - 1) * 2 + 1;
+   } else {
+   bw_index = port_id + xhci-num_usb3_ports - 1;
+   }
+
+   return bw_index;
+}


This appears to be a function to help the scheduling code lookup 
per-port private data held as an array in the device private structure.


Is this really the best way to lookup this data? (and if it *is* we 
still need some comments explaining what this function does and how it 
relates to sch_array).




+
+static void setup_sch_info(struct usb_device *udev,
+   struct xhci_ep_ctx *ep_ctx, struct mu3h_sch_ep_info *sch_ep)
+{
+   u32 ep_type;
+   u32 ep_interval;
+   u32 max_packet_size;
+   u32 max_burst;
+   u32 mult;
+   u32 esit_pkts;
+
+   ep_type = CTX_TO_EP_TYPE(le32_to_cpu(ep_ctx-ep_info2));
+   ep_interval = CTX_TO_EP_INTERVAL(le32_to_cpu(ep_ctx-ep_info));
+   max_packet_size = MAX_PACKET_DECODED(le32_to_cpu(ep_ctx-ep_info2));
+   max_burst = CTX_TO_MAX_BURST(le32_to_cpu(ep_ctx-ep_info2));
+   mult = CTX_TO_EP_MULT(le32_to_cpu(ep_ctx-ep_info));
+
+   sch_ep-ep_type = ep_type;
+   sch_ep-max_packet_size = max_packet_size;
+   sch_ep-esit = 1  ep_interval;
+   sch_ep-offset = 0;
+   sch_ep-burst_mode = 0;
+
+   if (udev-speed == USB_SPEED_HIGH) {
+   sch_ep-cs_count = 0;
+   /*
+* usb_20 spec section5.9
+* a single microframe is enough for HS synchromous endpoints
+* in a interval
+*/
+   sch_ep-num_budget_microframes = 1;
+   sch_ep-repeat = 0;
+   /*
+* xHCI spec section6.2.3.4
+

[PATCH v2 0/5] Add Broadcom Northstar Plus Support


Changes in version 2 incorporate Olof's comments regarding:
* the removal of all Reviewed-by lines not occurring on external
  mailing lists
* reordering of s-o-b lines
* modification of the device tree file to use labels when enabling
* increated description of the modification to the MAINTAINERS entry

Also, modifying the to and cc recepients so that everyone is
receving all of the patches. 

--

This patch series adds support for the Broadcom Northstar Plus family of
SoCs.  NSP is a Cortex A9 based SoC under the Broadcom iProc family.

Jon Mason (5):
  dt-bindings: Create Documentation for NSP DT bindings
  ARM: NSP: add minimal Northstar Plus device tree
  ARM: NSP: Add basic support for Broadcom Northstar Plus SoC
  ARM: multi_v7_defconfig: Add NSP to defconfig
  MAINTAINERS: add entry for the Broadcom Northstar Plus SoCs

 .../devicetree/bindings/arm/bcm/brcm,nsp.txt   |  34 +++
 MAINTAINERS|  12 ++-
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/bcm-nsp.dtsi | 105 +
 arch/arm/boot/dts/bcm958625k.dts   |  57 +++
 arch/arm/configs/multi_v7_defconfig|   1 +
 arch/arm/mach-bcm/Kconfig  |  14 +++
 arch/arm/mach-bcm/Makefile |   5 +-
 arch/arm/mach-bcm/bcm_nsp.c|  25 +
 9 files changed, 252 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt
 create mode 100644 arch/arm/boot/dts/bcm-nsp.dtsi
 create mode 100644 arch/arm/boot/dts/bcm958625k.dts
 create mode 100644 arch/arm/mach-bcm/bcm_nsp.c

-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/5] dt-bindings: Create Documentation for NSP DT bindings

Add the documentation for the Broadcom Northstar Plus device tree
bindings.

Signed-off-by: Jon Mason jonma...@broadcom.com
---
 .../devicetree/bindings/arm/bcm/brcm,nsp.txt   | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt
new file mode 100644
index 000..eae53e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt
@@ -0,0 +1,34 @@
+Broadcom Northstar Plus device tree bindings
+
+
+Broadcom Northstar Plus family of SoCs are used for switching control
+and management applications as well as residential router/gateway
+applications. The SoC features dual core Cortex A9 ARM CPUs, integrating
+several peripheral interfaces including multiple Gigabit Ethernet PHYs,
+DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash,
+SATA and several other IO controllers.
+
+Boards with Northstar Plus SoCs shall have the following properties:
+
+Required root node property:
+
+BCM58522
+compatible = brcm,bcm58522, brcm,nsp;
+
+BCM58525
+compatible = brcm,bcm58525, brcm,nsp;
+
+BCM58535
+compatible = brcm,bcm58535, brcm,nsp;
+
+BCM58622
+compatible = brcm,bcm58622, brcm,nsp;
+
+BCM58623
+compatible = brcm,bcm58623, brcm,nsp;
+
+BCM58625
+compatible = brcm,bcm58625, brcm,nsp;
+
+BCM88312
+compatible = brcm,bcm88312, brcm,nsp;
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/5] ARM: NSP: add minimal Northstar Plus device tree

Add a very minimalistic set of Northstar Plus Device Tree files which
describes the SoC and the BCM958625 implementation.  The perpherials
described are:

ARM Cortex A9 CPU
2 8250 UARTs
ARM GIC
PL310 L2 Cache
ARM A9 Global timer

Signed-off-by: Kapil Hali kap...@broadcom.com
Signed-off-by: Jon Mason jonma...@broadcom.com
---
 arch/arm/boot/dts/Makefile   |   2 +
 arch/arm/boot/dts/bcm-nsp.dtsi   | 105 +++
 arch/arm/boot/dts/bcm958625k.dts |  57 +
 3 files changed, 164 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm-nsp.dtsi
 create mode 100644 arch/arm/boot/dts/bcm958625k.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 246473a..adb5732 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -82,6 +82,8 @@ dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
 dtb-$(CONFIG_ARCH_BCM_MOBILE) += \
bcm28155-ap.dtb \
bcm21664-garnet.dtb
+dtb-$(CONFIG_ARCH_BCM_NSP) += \
+   bcm958625k.dtb
 dtb-$(CONFIG_ARCH_BERLIN) += \
berlin2-sony-nsz-gs7.dtb \
berlin2cd-google-chromecast.dtb \
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
new file mode 100644
index 000..77f9bfc
--- /dev/null
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -0,0 +1,105 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include dt-bindings/interrupt-controller/arm-gic.h
+#include dt-bindings/interrupt-controller/irq.h
+
+#include skeleton.dtsi
+
+/ {
+   compatible = brcm,nsp;
+   model = Broadcom Northstar Plus SoC;
+   interrupt-parent = gic;
+
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   cpu@0 {
+   device_type = cpu;
+   compatible = arm,cortex-a9;
+   next-level-cache = L2;
+   reg = 0x0;
+   };
+   };
+
+   clocks {
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   periph_clk: periph_clk {
+   compatible = fixed-clock;
+   #clock-cells = 0;
+   clock-frequency = 5;
+   };
+   };
+
+   uart0: serial@18000300 {
+   compatible = ns16550a;
+   reg = 0x18000300 0x100;
+   interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
+   clock-frequency = 62499840;
+   status = disabled;
+   };
+
+   uart1: serial@18000400 {
+   compatible = ns16550a;
+   reg = 0x18000400 0x100;
+   interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
+   clock-frequency = 62499840;
+   status = disabled;
+   };
+
+   gic: interrupt-controller@19021000 {
+   compatible = arm,cortex-a9-gic;
+   #interrupt-cells = 3;
+   #address-cells = 0;
+   interrupt-controller;
+   reg = 0x19021000 0x1000,
+ 0x19020100 0x100;
+   };
+
+   L2: l2-cache {
+   compatible = arm,pl310-cache;
+   reg = 0x19022000 0x1000;
+   cache-unified;
+   cache-level = 2;
+   };
+
+   timer@19020200 {
+   compatible = arm,cortex-a9-global-timer;
+

Re: [PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.

2015-08-26 Thread Dave Airlie

On 27 August 2015 at 00:30, Rob Herring robherri...@gmail.com wrote:
 On Wed, Aug 26, 2015 at 7:09 AM, Thierry Reding
 thierry.red...@gmail.com wrote:
 On Wed, Aug 26, 2015 at 01:52:29PM +0200, Daniel Vetter wrote:
 On Tue, Aug 25, 2015 at 04:42:18PM -0400, Rob Clark wrote:
  On Mon, Aug 24, 2015 at 9:47 AM, Rob Herring robherri...@gmail.com 
  wrote:
   On Mon, Aug 17, 2015 at 1:30 PM, Eric Anholt e...@anholt.net wrote:
   Stephen Warren swar...@wwwdotorg.org writes:
  
   On 08/12/2015 06:56 PM, Eric Anholt wrote:
   Signed-off-by: Eric Anholt e...@anholt.net
  
   This one definitely needs a patch description, since someone might not
   know what a VC4 is, and git log won't show the text from the binding
   doc itself. I'd suggest adding the initial paragraph of the binding 
   doc
   as the patch description, or more.
  
   diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
   b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
  
   +- hvss: List of references to HVS video scalers
   +- encoders: List of references to output encoders (HDMI, SDTV)
  
   Would it make sense to make all those nodes child node of the vc4
   object. That way, there's no need to have these lists of objects; they
   can be automatically built up as the DT is enumerated. I know that 
   e.g.
   the NVIDIA Tegra host1x binding works this way, and I think it may 
   have
   been inspired by other similar cases.
  
   I've looked at tegra, and the component system used by msm appears to 
   be
   nicer than it.  To follow tegra's model, it looks like I need to build
   this extra bus thing corresponding to host1x that is effectively the
   drivers/base/component.c code, so that I can get at vc4's structure 
   from
   the component drivers.
  
   Of course, this is only appropriate if the HW modules really are
   logically children of the VC4 HW module. Perhaps they aren't. If they
   aren't though, I wonder what this vc4 module actually represents in 
   HW?
  
   It's the subsystem, same as we use a subsystem node for msm, sti,
   rockchip, imx, and exynos.  This appears to be the common model of how
   the collection of graphics-related components is represented in the DT.
  
   I think most of these bindings are wrong. They are grouped together
   because that is what DRM wants not because that reflects the h/w. So
   convince me this is one block, not that it is what other people do.
 
  I think, when it comes to more complex driver subsystems (like drm in
  particular) we have a bit of mismatch between how things look from the
  pure hw ignoring sw perspective, and the how sw and in particular
  userspace expects things perspective.  Maybe it is less a problem in
  other subsystems, where bindings map to things that are only visible
  in the kernel, or well defined devices like uart or sata controller.
  But when given the choice, I'm going to err on the side of not
  confusing userspace and the large software stack that sits above
  drm/kms, over dt purity.
 
  Maybe it would be nice to have a sort of dt overlay that adds the bits
  needed to tie together hw blocks that should be assembled into a
  single logical device for linux and userspace (but maybe not some
  other hypothetical operating system).  But so far that doesn't exist.
  All we have is a hammer (devicetree), everything looks like a nail.
  End result is we end up adding some things in the bindings which
  aren't purely about the hw.  Until someone invents a screwdriver, I'm
  not sure what else to do.  In the end, other hypothetical OS is free
  to ignore those extra fields in the bindings if it doesn't need them.
  So meh?

 I thought we agreed a while back that these kind of pull everything for
 the logical device together dt nodes which just have piles of phandles
 are totally accepted? At least that's the point behind the component
 helpers, and Eric even suggested to create dt-specific component helpers
 to cut down a bit on the usual boilerplate. dt maintainers are also fine
 with this approach afaik. From my understanding tegra with the host1x bus
 really is the odd one out and not the norm.

 I agree that in many aspects Tegra is somewhat special. But the same
 principles that the host1x infrastructure uses could be implemented in a
 similar way for other DRM drivers. You can easily collect information
 about subdevices by walking the device tree and matching on known
 compatible strings. And you can also instantiate the top-level device
 from driver code rather than have it in DT. It should still be possible
 to make this work without an artificial device node in DT. The component
 and master infrastructure is largely orthogonal to that, and as far as I
 remember the only blocker is the need for a top-level device. I wonder
 if perhaps this could be made to work by binding the master to the top-
 level SoC device.

 Obviously adding the node in DT is easier, but to my knowledge easy has
 never been a good excuse

Re: [PATCH 2/3] ARM: DT: STi: STiH407: Add c8sectpfe LinuxDVB DT node.

On Tue, 25 Aug 2015, Peter Griffin wrote:

 This patch adds in the required DT node for the c8sectpfe
 Linux DVB demux driver which allows the tsin channels
 to be used on an upstream kernel.
 
 Signed-off-by: Peter Griffin peter.grif...@linaro.org
 ---
  arch/arm/boot/dts/stihxxx-b2120.dtsi | 38 
 
  1 file changed, 38 insertions(+)
 
 diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi 
 b/arch/arm/boot/dts/stihxxx-b2120.dtsi
 index 62994ae..1bc018e 100644
 --- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
 +++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
 @@ -6,6 +6,10 @@
   * it under the terms of the GNU General Public License version 2 as
   * published by the Free Software Foundation.
   */
 +
 +#include dt-bindings/clock/stih407-clks.h
 +#include dt-bindings/media/c8sectpfe.h
 +

Looks like some of the STi files are a little wavering on convention,
but I suggest the extra '\n's are superfluous.

  / {
   soc {
   sbc_serial0: serial@953 {
 @@ -85,5 +89,39 @@
   status = okay;
   };
  
 + c8sectpfe@08a2 {

This should be a device type, not a model number.

demodulator@abcdabcd {

 + compatible = st,stih407-c8sectpfe;

To the uninitiated c8sectpfe is pretty indecipherable.

How about *-c8sectpfe-demod?

 + status = okay;
 + reg = 0x08a2 0x1, 0x08a0 0x4000;
 + reg-names = c8sectpfe, c8sectpfe-ram;
 +
 + interrupts = 0 34 0, 0 35 0;

Please use the predetermined DEFINES for the flags cell.

 + interrupt-names = c8sectpfe-error-irq,
 +   c8sectpfe-idle-irq;
 +
 + pinctrl-names   = tsin0-serial, tsin0-parallel,
 +   tsin3-serial, tsin4-serial,
 +   tsin5-serial;

I would put *-names *under* the properties they pertain to and in the
same format i.e. one per line in this case, for easy eye-match.

 + pinctrl-0   = pinctrl_tsin0_serial;
 + pinctrl-1   = pinctrl_tsin0_parallel;
 + pinctrl-2   = pinctrl_tsin3_serial;
 + pinctrl-3   = pinctrl_tsin4_serial_alt3;
 + pinctrl-4   = pinctrl_tsin5_serial_alt1;
 +
 + clocks = clk_s_c0_flexgen CLK_PROC_STFE;
 + clock-names = c8sectpfe;
 +
 + /* tsin0 is TSA on NIMA */
 + tsin0: port@0 {
 +

Why the '\n'?

 + tsin-num = 0;
 + serial-not-parallel;
 + i2c-bus = ssc2;

If you are adding this property, I would get Wolfram or one of the DT
guys to Ack it.

 + rst-gpio = pio15 4 0;

Why not use the whole name reset?

-gpio should be -gpios.

So, in full: reset-gpios?

Flags: GPIO_ACTIVE_HIGH ?

 + dvb-card = STV0367_TDA18212_NIMA_1;
 + };
 + };
   };
  };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v16 4/4] ARM: dts: add the support power-domain node on RK3288 SoCs

2015-08-26 Thread Caesar Wang




在 2015年08月26日 06:45, Kevin Hilman 写道:

Doug Anderson diand...@chromium.org writes:


Kevin,

On Tue, Aug 25, 2015 at 2:07 PM, Kevin Hilman khil...@kernel.org wrote:

Caesar Wang w...@rock-chips.com writes:


We can add more domains node in the future.
This patch add the needed clocks into power-controller.
As the discuess about all the device clocks being listed in
the power-domains itself.

There are several reasons as follows:

Firstly, the clocks need be turned off to save power when
the system enter the suspend state. So we need to enumerate
the clocks in the dts. In order to power domain can turn on and off.

Yes, but this is the job of device drivers which are runtime PM adapted
to gate their own clocks.  I agree these clocks need to be enumerated in
the DTS, but they should be in the device nodes.

I _think_ what Caesar means is that the alternative to this patch is
to leave the clocks on all the time as they were during the early days
of Rockchip (AKA last year).  If the clocks are on all the time then
the power domain patches can work fine.  However, once you start
letting clocks turn off then you need to make sure that the power
domain code turns the back on temporarily.

Yup, I understand that part, and many SoCs have this same feature.


Secondly, the reset-circuit should reset be synchronous on RK3288,
then sync revoked. So we need to enable clocks of all devices.
In other words, we have to enable the clocks before you operate them
if all the device clocks are included in someone domians.

Yes, this is pretty common for reset.


Someone wish was to get the clocks by reading the clocks from the
device nodes, We can do that but we can solve the above issues.

I don't follow this sentence.  Are you saying doing that will not solve
the above issues?  Why not?  Please explain.

If there are non-device clocks that also need to be enabled before
asserting reset, then those are candidates for the power-domain node,
but not device clocks.

It's been a long time and I don't know that I've reviewed every
revision of this series, but I think there was a proposal that we
shouldn't list clocks here.  Instead we should search through and find
all devices that refer to this power domain, reach in and find their
clocks, and turn them on.  Did I get that right?

Yes...


Sounds resonable, the domain(e.g. pd_vio...) idle will be abnormal but 
you have registered all devices.

Why?
AFAIK, you need turn on the noc/ip clocks if we are operating the 
pd_vio domain to enter the idle status.
if the noc is same clock with ip side.  We need turn on the IP side 
clocks. Otherwise we need turn on the noc clocks.



To put things in a
concrete way, for pd_vio we'd go through the entire device tree
ourselves and find all properties that look like power-domains =
power RK3288_PD_VIO;.  We'd then find the parent of those
properties and look for a property named clocks.  We'd then iterate
over all those clocks and turn those on.  Did I get that right?

... but you make it sound like more work than it is.  The genpd already
keeps a list of devices that refer to the power domain.  In fact, the
genpd 'attach' method can be platform-specific, so could be used to keep
track of a list (or a subset) of clocks which are needed for reset.


The above doesn't seem like a terribly great idea to me for a number
of reasons, including:

1. If I remember correctly, it's important to turn on clocks for
devices even if they're not something you're using / have a driver
for.  If you don't then the device won't get reset properly and this
can affect things like suspend/resume because the hardware in the SoC
will query all devices at suspend time to make sure they're ready.

Correct.  This condition also exists in the clock framework when unused
clocks are disabled, or if you have drivers but PM_RUNTIME is disabled
(which can happen from userspace on a per-device basis) so it needs to
be understood and managed already.


If
a device is wedged because its clock wasn't on at the right them then
it will cause problems.

Right.  I'm not arguing that the power domain doesn't have to deal with
device clocks. It has to for sync reset.  The objection I have have is
where these clocks are described.


2. If we absolutely need to turn all clocks and we get clocks from
device tree nodes on then it means we need device tree nodes for every
device in the domain.

Isn't that the end goal?


These would be needed even if there are no
accepted bindings for this device yet.  So we'd need to do one of: A)
Block power domain patches on feature complete bindings for all
drivers; B) Make up non-approved compatible strings for all devices
and throw them into the DTS; C) Add nodes in the DTS without a
compatible string just to satisfy the power domain requirements.  None
of these seem terribly appealing.

well, I think we can be slightly more accomodating than that and go for
somewhere in between:

D) In the power-domain DTS, clearly describe why each clock is

Re: [PATCH v2 1/7] drm/vc4: Add devicetree bindings for VC4.

2015-08-26 Thread Luc Verhaegen

On Tue, Aug 18, 2015 at 02:54:02PM -0700, Eric Anholt wrote:
 VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
 other Broadcom SoCs.
 ...
 +Broadcom VC4 GPU
 +
 +The VC4 device present on the Raspberry Pi includes a display system
 +with HDMI output and the HVS scaler for compositing display planes.

Is this a direct hw driver implementation, banging registers, or is this 
talking to the os/firmware/binary blob running on the videocore dsp?

Luc Verhaegen.
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/7] MAINTAINERS: Add FDMA driver files to STi section.

On Wed, 08 Jul 2015, Peter Griffin wrote:

 This patch adds the FDMA driver files to the STi
 section of the maintainers file.
 
 Signed-off-by: Peter Griffin peter.grif...@linaro.org
 ---
  MAINTAINERS | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/MAINTAINERS b/MAINTAINERS
 index 8133cef..8cb1ad9 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -1503,6 +1503,8 @@ S:  Maintained
  F:   arch/arm/mach-sti/
  F:   arch/arm/boot/dts/sti*
  F:   drivers/clocksource/arm_global_timer.c
 +F:   drivers/dma/st_fdma.*
 +F:   drivers/dma/st_fdma_xbar.c

How about you replace both lines with:

F:  drivers/dma/st_fdma*

  F:   drivers/i2c/busses/i2c-st.c
  F:   drivers/media/rc/st_rc.c
  F:   drivers/mmc/host/sdhci-st.c

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v16 3/4] soc: rockchip: power-domain: Add power domain driver

2015-08-26 Thread Caesar Wang




在 2015年08月26日 04:57, Kevin Hilman 写道:

Caesar Wang w...@rock-chips.com writes:


This driver is found on RK3288 SoCs.

In order to meet high performance and low power requirements, a power
management unit is designed or saving power when RK3288 in low power
mode.
The RK3288 PMU is dedicated for managing the power of the whole chip.

PMU can work in the Low Power Mode by setting bit[0] of PMU_PWRMODE_CON
register. After setting the register, PMU would enter the Low Power mode.
In the low power mode, pmu will auto power on/off the specified power
domain, send idle req to specified power domain, shut down/up pll and
so on. All of above are configurable by setting corresponding registers.

Signed-off-by: jinkun.hong jinkun.h...@rock-chips.com
Signed-off-by: Caesar Wang w...@rock-chips.com

[...]


diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
new file mode 100644
index 000..87a09c3
--- /dev/null
+++ b/drivers/soc/rockchip/Kconfig
@@ -0,0 +1,13 @@
+#
+# Rockchip Soc drivers
+#
+config PM_GENERIC_DOMAINS

Why are you (re)defining this config option?  This name is already used in 
kernel/pm/Kconfig.


Fixed.


Thanks,
Caesar


Kevin

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip


--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] add GPT timer support for mt8173

2015-08-26 Thread Daniel Lezcano


On 07/13/2015 11:32 AM, Yingjoe Chen wrote:

This series add GPT timer support for mt8173. This is based on v4.2-rc1
and Matthias' next branch (for dts parts).

The first 2 patches comes from 'Add SMP bringup support for mt65xx socs'
series [1]. I decide to move these 2 patches to this series, since it
is more relevent here. They are changed based on Matthias' and Daniel's
comments.

[1] http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000714.html

Daniel Kurtz (1):
   arm64: dts: mt8173: add timer node

Yingjoe Chen (4):
   clocksource: mediatek: do not enable GPT_CLK_EVT when setup
   clocksource: mediatek: Use GPT as sched clock source
   arm64: mediatek: enable MTK_TIMER
   clk: mediatek: add 13mhz clock for MT8173

  arch/arm64/Kconfig   |  1 +
  arch/arm64/boot/dts/mediatek/mt8173.dtsi |  9 +
  drivers/clk/mediatek/clk-mt8173.c|  5 +
  drivers/clocksource/mtk_timer.c  | 26 --
  include/dt-bindings/clock/mt8173-clk.h   |  3 ++-
  5 files changed, 37 insertions(+), 7 deletions(-)


Who will take this patchset ? I can take the patch 2 if needed.


--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] devicetree: Add led-backlight binding

2015-08-26 Thread Jacek Anaszewski


On 08/26/2015 11:11 AM, Tomi Valkeinen wrote:



On 26/08/15 10:07, Jacek Anaszewski wrote:

On 08/25/2015 05:41 PM, Tomi Valkeinen wrote:



On 25/08/15 16:39, Jacek Anaszewski wrote:


+Example:
+
+backlight {
+compatible = led-backlight;
+leds = backlight_led;
+
+brightness-levels = 0 4 8 16 32 64 128 255;


brightness level is not a suitable unit for describing LED brightness
in a Device Tree, as it is not a physical unit. We have led-max-microamp
property for this, expressed in microamperes, please refer to [0] from
linux-next.


Hmm, ok, but what should the driver do with microamperes? As far as I
see, enum led_brightness (which is between 0-255) is used to set the
brightness to LEDs. I don't see any function accepting microamperes.


This is implementation detail. You can convert microamperes to
enum led_brightness in the driver. Please refer to the discussion [1].


The led_set_brightness() takes enum led_brightness, so I don't
understand what this driver would do with the microampere value. It
could, of course, do an arbitrary conversion, say, direct mapping of the
mA value to brightness, but that would just confuse things further.


OK, I was looking at the problem from LED-centric perspective. Indeed,
backlight subsystem has no other way to pass brightness to the LED
subsystem than in the form of levels. However, the last word belongs
to DT maintainer in this matter.

Cc'ing devicetree@vger.kernel.org.


If there was a led_set_microampere(), supported by all led devices, then
yes, the above should be microamperes.

Or are you saying that I should have the binding use microamperes, and
just do a naive microampere - brightness conversion in this driver, and
hope that in the future this driver can be changes to pass the
micrompere value directly to the underlying LED driver?

And speaking of microamperes for LED drivers, what's a meaningful
microampere conversion for LED drivers that don't deal with microamperes
at all? For example, the LED chip we're using, TLC59108, is basically a
PWM chip. Can we somehow calculate microamperes if we know duty cycle
and period?


For this type of drivers we have to resort to levels in DT.
It shouldn't serve as an excuse for not describing the rest of
hardware in a better way, though.

--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/irq: export of_get_irq_byname()

2015-08-26 Thread Wolfram Sang

On Wed, Aug 26, 2015 at 10:24:25AM +1000, Stephen Rothwell wrote:
 Hi Dmitry,
 
 On Tue, 25 Aug 2015 17:04:02 -0700 Dmitry Torokhov 
 dmitry.torok...@gmail.com wrote:
 
  Similarly to of_get_irq(), let's export of_irq_get_byname(), so if a bus 
  core
  can be compiled as a module (such as I2C) it can have access to the symbol.
  
  Reported-by: Stephen Rothwell s...@canb.auug.org.au
  Reported-by: kbuild test robot fengguang...@intel.com
  Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
 
 I applied that to linux-next today.  Pelase get it applied to the i2c
 tree (with appropriate acks).

Waiting for Rob's Ack, then I'll pick it up...



signature.asc
Description: Digital signature

Re: [PATCH 2/3] ARM: DT: STi: STiH407: Add c8sectpfe LinuxDVB DT node.