Re: [PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

[Stephen Boyd]

On 12/02, Archit Taneja wrote:
> On 12/02/2015 01:50 PM, Stephen Boyd wrote:
> >
> >My only thought there would be to make of_clk_set_defaults() wait
> >until both clocks are registered before it does any parent
> >setting. But only in the case where the assigned parents contains
> >a clock that is provided by the node being processed. I suppose
> >the simplest thing to do would be to skip it during the device
> >driver probe and handle it when the clk provider is registered.
> >
> 
> The assigned-clock-parents stuff you mentioned is needed to set a
> default link between the one of the DSI PLLs and the RCG, right? I
> just wanted to make clear if we were still discussing the same
> issue.

Yes.

> 
> From what I understand, we don't need the assigned-clock-parents stuff
> to establish a link between byte_clk_src(RCG clock) and
> byte_clk(branch clock). That's a fixed link set up by the clock
> structs provided in the gcc driver and doesn't need to be specially
> assigned, and just a
> clk_get_parent in the driver does the job there.

There's only one parent of the byte_clk and that's byte_clk_src.
So yes, there's no need to describe that in DT and
clk_get_parent() works fine.

> 
> About assigning a parent to the RCG, wouldn't that be xo by default, and
> changed by the drm/msm driver to one of the PLLs when the need arrives?
> I didn't get why we need to establish that beforehand in DT?
> 

Yes, it would be XO out of reset, but we have no idea what the
bootloader is doing. I thought the problem was that byte_clk_src
is not actually an input to the DSI device. The proposal was to
have DT specify byte_clk_src and byte_clk in the clocks array so
that byte_clk_src could be reparented to the PLL and the byte_clk
could be enabled/disabled. If we use DT to do the parent
configuring then the DSI node doesn't have the byte_clk_src in
its clocks array and thus DT is reflecting reality.

If we want to dynamically switch the parent of byte_clk_src to be
different PLLs at runtime, then yes we'll need to get the parent
of the byte_clk (which is byte_clk_src) and set the PLL as the
parent. Or we'll need to make clk_set_parent() on the byte_clk
transparently set the grand-parent to be the PLL. In that case we
may need to introduce some sort of flag like
CLK_SET_PARENT_GRANDPARENT to add this type of behavior.

I don't have a huge problem with

clk_set_parent(clk_get_parent(byte_clk), PLL)

except that this fails the abstraction test. It leaks information
about the clock tree into a driver that shouldn't need to know
that on this particular SoC there's a clock in between the PLL
and the byte_clk. Future designs may not have the intermediate
clock and then we'll need to update the driver to handle the
difference, when we could have added the flag and things would
work the same.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 2/2] ARM: dts: uniphier: factor out common nodes to uniphier-common32.dtsi

[Masahiro Yamada]

UniPhier SoCs (except PH1-sLD3) have several nodes in common.
Factor out them into uniphier-common32.dtsi.  This improves the code
maintainability.

PH1-sLD3 is so old that it has more or less different register maps
than the others.  So, it cannot be included in this refactoring.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-common32.dtsi| 135 +
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 265 +
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 288 ++--
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 274 +-
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 266 +
 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 269 +-
 6 files changed, 605 insertions(+), 892 deletions(-)
 create mode 100644 arch/arm/boot/dts/uniphier-common32.dtsi

diff --git a/arch/arm/boot/dts/uniphier-common32.dtsi 
b/arch/arm/boot/dts/uniphier-common32.dtsi
new file mode 100644
index 000..ea9301a
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-common32.dtsi
@@ -0,0 +1,135 @@
+/*
+ * Device Tree Source commonly used by UniPhier ARM SoCs
+ *
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * 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.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+   soc: soc {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   interrupt-parent = <&intc>;
+
+   extbus: extbus {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <1>;
+   };
+
+   serial0: serial@54006800 {
+   compatible = "socionext,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006800 0x40>;
+   interrupts = <0 33 4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart0>;
+   clocks = <&uart_clk>;
+   };
+
+   serial1: serial@54006900 {
+   compatible = "socionext,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006900 0x40>;
+   interrupts = <0 35 4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart1>;
+   clocks = <&uart_clk>;
+   };
+
+   serial2: serial@54006a00 {
+   compatible = "socionext,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006a00 0x40>;
+   interrupts = <0 37 4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart2>;
+   clocks = <&uart_clk>;
+   };
+
+   serial3: serial@54006b00 {
+   compatible = "socionext,uniphier-uart";
+  

[PATCH 0/2] ARM: dts: uniphier: clean up DTSIs by factoring the common parts out

[Masahiro Yamada]

Masahiro Yamada (2):
  ARM: dts: uniphier: change IRQ number of UART3 of PH1-Pro4 SoC
  ARM: dts: uniphier: factor out common nodes to uniphier-common32.dtsi

 arch/arm/boot/dts/uniphier-common32.dtsi| 135 +
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 265 +
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 288 ++--
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 274 +-
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 266 +
 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 269 +-
 6 files changed, 605 insertions(+), 892 deletions(-)
 create mode 100644 arch/arm/boot/dts/uniphier-common32.dtsi

-- 
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 1/2] ARM: dts: uniphier: change IRQ number of UART3 of PH1-Pro4 SoC

[Masahiro Yamada]

The UART3 is assigned with IRQ 29 for old SoCs, IRQ 177 for new ones,
and PH1-Pro4 is on the boundary.

  PH1-sLD3: UART3 is unavailable
  PH1-LD4, PH1-sLD8: only IRQ 29 is supported
  PH1-Pro4: both IRQ 29 and 177 are supported
  PH1-Pro5, ProXstream2, PH1-LD6b: only IRQ 177 is supported

This SoC can choose either IRQ 29 or IRQ 177, but the former is shared
with another hardware (low speed serial0).  The latter is dedicated
for this hardware and more recommended.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index 254642f..bbf3727 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -151,7 +151,7 @@
reg = <0x54006b00 0x40>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart3>;
-   interrupts = <0 29 4>;
+   interrupts = <0 177 4>;
clocks = <&uart_clk>;
fifo-size = <64>;
};
-- 
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

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi,

On Thu, Dec 03, 2015 at 11:38:14AM +0530, Roger Quadros wrote:
> On 03/12/15 10:39, Brian Norris wrote:
> > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
> >> We do a couple of things in this series which result in
> >> cleaner device tree implementation, faster perfomance and
> >> multi-platform support. As an added bonus we get new GPI/Interrupt pins
> >> for use in the system.
> >>
> >> - Establish a custom interface between NAND and GPMC driver. This is
> >> needed because all of the NAND registers sit in the GPMC register space.
> >> Some bits like NAND IRQ are even shared with GPMC.
> >>
> >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> >> This causes performance increase when using prefetch-irq mode.
> >> 30% increase in read, 17% increase in write in prefetch-irq mode.
> >>
> >> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
> >> driver can be used on non-OMAP platforms. e.g. Keystone.
> >>
> >> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
> >> 2 to 4 of these and most of them would be unused otherwise. It also
> >> allows a cleaner implementation of NAND Ready pin status for the NAND 
> >> driver.
> >>
> >> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
> >>
> >> This series is available at
> >> g...@github.com:rogerq/linux.git
> >> in branch
> >> for-v4.4/gpmc-v3
> >>
> >> cheers,
> >> -roger
> >>
> >> Changelog:
> >> v3:
> >> -Fixed and tested NAND using legacy boot on omap3-beagle.
> >> -Support rising and falling edge interrupts on WAITpins.
> >> -Update DT node of all gpmc users.
> > 
> > The MTD stuff looks mostly good to me know. I've made all my comments
> > for now, but I'm not sure how you're going to end up rebasing/splitting
> > and what you're going to do with the irqchip removal, so I'll refrain
> > from ack's for now. Hopefully I can either ack or merge v4.
> 
> I'll retain the irqchip model for now and send a v4 with all comments
> addressed and better subsystem wise patch split.
> 
> > 
> > I brought it up on one other patch, but it's not really clear to me what
> > the split is on board file vs. device tree handling, since you seem to
> > have a combination of both (i.e., platform data that passes along device
> > nodes). What's the plan on that?
> 
> Platform data no longer passes device nodes. We're either true device tree
> or plain legacy. The deprecated fields are no longer used once the series is
> applied.

Well, they're still sorta used (you assign info->of_node =
pdata->of_node, for instance). As dicussed in the other thread, I think
we can avoid the deprecation part and just kill the fields though, and
that would make things clearer.

> > And of course, there's the question of how exactly to merge this, given
> > the:
> > (1) conflicts already existing in the MTD dev tree
> 
> I'll rebase the series on top of MTD dev tree.

OK. FWIW, we so far only need to base them on commit a61ae81a1907 ("mtd:
nand: drop unnecessary partition parser data"). Maybe when queueing up a
branch, that'd be the best starting point for Tony, so he doesn't need
to have all of MTD's stuff in his tree too? I can set up a signed tag or
something, if that would be helpful.

But for sending patches, the latest l2-mtd.git is fine too.

> > (2) this touches several trees, often in the same patch and
> 
> I'll try my best to split the patches but not sure if this could be 100%
> clean split without functional breakage.
> 
> > (3) even if the patches were split out a little better into MTD and
> > non-MTD stuff, I think there would still be dependencies such that
> > we'd need at least 1 (probably 2) cross merges to get it all
> > straight
> 
> That is correct.
> Is it OK if functionality breaks if for example only MTD changes are 
> considered?

I think I may have misunderstood the branch proposal. If Tony queues up:

  l2-mtd.git (or just up to commit a61ae81a1907)
  +
  your patches

and I pull that back into l2-mtd.git as well, then we don't need to
worry about patches that touch multiple "trees". Just do whatever makes
things clearest, including disregarding some of my comments along the
line of (3).

Sorry for any confusion.

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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Brian,

On 03/12/15 10:39, Brian Norris wrote:
> Hi,
> 
> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> We do a couple of things in this series which result in
>> cleaner device tree implementation, faster perfomance and
>> multi-platform support. As an added bonus we get new GPI/Interrupt pins
>> for use in the system.
>>
>> - Establish a custom interface between NAND and GPMC driver. This is
>> needed because all of the NAND registers sit in the GPMC register space.
>> Some bits like NAND IRQ are even shared with GPMC.
>>
>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>> This causes performance increase when using prefetch-irq mode.
>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>
>> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
>> driver can be used on non-OMAP platforms. e.g. Keystone.
>>
>> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
>> 2 to 4 of these and most of them would be unused otherwise. It also
>> allows a cleaner implementation of NAND Ready pin status for the NAND driver.
>>
>> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
>>
>> This series is available at
>> g...@github.com:rogerq/linux.git
>> in branch
>> for-v4.4/gpmc-v3
>>
>> cheers,
>> -roger
>>
>> Changelog:
>> v3:
>> -Fixed and tested NAND using legacy boot on omap3-beagle.
>> -Support rising and falling edge interrupts on WAITpins.
>> -Update DT node of all gpmc users.
> 
> The MTD stuff looks mostly good to me know. I've made all my comments
> for now, but I'm not sure how you're going to end up rebasing/splitting
> and what you're going to do with the irqchip removal, so I'll refrain
> from ack's for now. Hopefully I can either ack or merge v4.

I'll retain the irqchip model for now and send a v4 with all comments
addressed and better subsystem wise patch split.

> 
> I brought it up on one other patch, but it's not really clear to me what
> the split is on board file vs. device tree handling, since you seem to
> have a combination of both (i.e., platform data that passes along device
> nodes). What's the plan on that?

Platform data no longer passes device nodes. We're either true device tree
or plain legacy. The deprecated fields are no longer used once the series is
applied.

> 
> And of course, there's the question of how exactly to merge this, given
> the:
> (1) conflicts already existing in the MTD dev tree

I'll rebase the series on top of MTD dev tree.

> (2) this touches several trees, often in the same patch and

I'll try my best to split the patches but not sure if this could be 100%
clean split without functional breakage.

> (3) even if the patches were split out a little better into MTD and
> non-MTD stuff, I think there would still be dependencies such that
> we'd need at least 1 (probably 2) cross merges to get it all
> straight

That is correct.
Is it OK if functionality breaks if for example only MTD changes are considered?

cheers,
-roger
--
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 v4 11/27] mtd: nand: omap: Clean up device tree support

[Brian Norris]

On Thu, Dec 03, 2015 at 11:27:13AM +0530, Roger Quadros wrote:
> On 03/12/15 09:59, Brian Norris wrote:
> > On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
> >>  arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
> >>  drivers/memory/omap-gpmc.c   | 143 
> >> +++
> >>  drivers/mtd/nand/omap2.c | 136 
> >> +
> >>  include/linux/platform_data/mtd-nand-omap2.h |   3 +-
> >>  4 files changed, 155 insertions(+), 132 deletions(-)
> > 
> > Also, this is going to be hard to manage across trees, as you touch
> > three drivers all at once. Is it not possible to split any of this apart
> > better?
> 
> Will need some more effort and I can do it. Butm if we're going to start
> an with immutable branch with everything in, is it worth the effort?

I don't think I noticed the "everything in it" part. I was assuming
you'd have non-MTD changes in the immutable branch, and MTD stuff on
top. But that is indeed more difficult. I'm fine with everything going
in one branch, and pulling that all into MTD.

Then the hangup is that you'll need to have some of l2-mtd.git in that
branch as a prerequisite, if you're going to rebase. Or else I have to
fix it up when merging back into l2-mtd.git...

...

> >> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
> >> b/include/linux/platform_data/mtd-nand-omap2.h
> >> index a067f58..ff27e5a 100644
> >> --- a/include/linux/platform_data/mtd-nand-omap2.h
> >> +++ b/include/linux/platform_data/mtd-nand-omap2.h
> >> @@ -76,11 +76,10 @@ struct omap_nand_platform_data {
> >>int devsize;
> >>enum omap_ecc   ecc_opt;
> >>  
> >> -  /* for passing the partitions */
> >> -  struct device_node  *of_node;
> >>struct device_node  *elm_of_node;
> >>  
> >>/* deprecated */
> >>struct gpmc_nand_regs   reg;
> >> +  struct device_node  *of_node;
> > 
> > I'm a little confused here. Do you have a mixed platform data / device
> > tree setup here? That's odd. (It also seems if that was really
> > necessary, you could have the board file set pdev->dev.of_node before
> > registering it, then you don't need this field.) But really, if you're
> > partly using device tree, can't you just convert completely? Or is this
> > a two-phase process, and you're planning to convert omap2 to full device
> > tree?
> 
> The existing device tree implementation for omap2-nand was like this:
> omap-gpmc.c driver was creating a platform device for the nand device and
> passing the device node via platform data.
> 
> After this series we no longer do this and that's why of_node is marked
> deprecated in platform data. I might as well could just get rid of it
> but wasn't sure of how we're going to integrate the changes into the
> subsystem trees so just marked it deprecated.

Whoops, sorry I didn't read the "deprecated" header there this time. I
thought the movement was odd. *facepalm*

But yes, especially if we're putting everything in one branch, it'd be
more clear to simply kill off things instead of marking things
deprecated. It's especially confusing, since you're actually still using
the field.

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 v4 11/27] mtd: nand: omap: Clean up device tree support

[Roger Quadros]

Brian,

On 03/12/15 09:59, Brian Norris wrote:
> Hi Roger,
> 
> On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
>> Move NAND specific device tree parsing to NAND driver.
>>
>> The NAND controller node must have a compatible id, register space
>> resource and interrupt resource.
>>
>> Signed-off-by: Roger Quadros 
> 
> This one's going to need rebased, as there are some conflicting of_node
> changes in l2-mtd.git.

Al right. I'll rebase on top of l2-mtd.git
> 
>> ---
>> v4: Warn if using older incompatible DT i.e. compatible property not present
>> in nand node.
>>
>>  arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
>>  drivers/memory/omap-gpmc.c   | 143 
>> +++
>>  drivers/mtd/nand/omap2.c | 136 +
>>  include/linux/platform_data/mtd-nand-omap2.h |   3 +-
>>  4 files changed, 155 insertions(+), 132 deletions(-)
> 
> Also, this is going to be hard to manage across trees, as you touch
> three drivers all at once. Is it not possible to split any of this apart
> better?

Will need some more effort and I can do it. Butm if we're going to start
an with immutable branch with everything in, is it worth the effort?
> 
>>
>> diff --git a/arch/arm/mach-omap2/gpmc-nand.c 
>> b/arch/arm/mach-omap2/gpmc-nand.c
>> index ffe646a..e07ca27 100644
>> --- a/arch/arm/mach-omap2/gpmc-nand.c
>> +++ b/arch/arm/mach-omap2/gpmc-nand.c
>> @@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
>> *gpmc_nand_data,
>>  gpmc_nand_res[1].start = gpmc_get_irq();
>>  
>>  memset(&s, 0, sizeof(struct gpmc_settings));
>> -if (gpmc_nand_data->of_node)
>> -gpmc_read_settings_dt(gpmc_nand_data->of_node, &s);
>> -else
>> -gpmc_set_legacy(gpmc_nand_data, &s);
>> +gpmc_set_legacy(gpmc_nand_data, &s);
>>  
>>  s.device_nand = true;
>>  
>> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
>> index e75226d..318c187 100644
>> --- a/drivers/memory/omap-gpmc.c
>> +++ b/drivers/memory/omap-gpmc.c
>> @@ -29,7 +29,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  



>>  
>> -ppdata.of_node = pdata->of_node;
>> -mtd_device_parse_register(mtd, NULL, &ppdata, pdata->parts,
>> -  pdata->nr_parts);
>> +if (dev->of_node) {
>> +ppdata.of_node = dev->of_node;
> 
> The latest l2-mtd.git changed how the partitions' of_node is passed. Now
> this is handled by nand_set_flash_node().

OK.
> 
>> +mtd_device_parse_register(mtd, NULL, &ppdata, NULL, 0);
>> +
>> +} else {
>> +mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
>> +}
>>  
>>  platform_set_drvdata(pdev, mtd);
>>  
>> @@ -2083,11 +2173,17 @@ static int omap_nand_remove(struct platform_device 
>> *pdev)
>>  return 0;
>>  }
>>  
>> +static const struct of_device_id omap_nand_ids[] = {
>> +{ .compatible = "ti,omap2-nand", },
>> +{},
>> +};
>> +
>>  static struct platform_driver omap_nand_driver = {
>>  .probe  = omap_nand_probe,
>>  .remove = omap_nand_remove,
>>  .driver = {
>>  .name   = DRIVER_NAME,
>> +.of_match_table = of_match_ptr(omap_nand_ids),
>>  },
>>  };
>>  
>> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
>> b/include/linux/platform_data/mtd-nand-omap2.h
>> index a067f58..ff27e5a 100644
>> --- a/include/linux/platform_data/mtd-nand-omap2.h
>> +++ b/include/linux/platform_data/mtd-nand-omap2.h
>> @@ -76,11 +76,10 @@ struct omap_nand_platform_data {
>>  int devsize;
>>  enum omap_ecc   ecc_opt;
>>  
>> -/* for passing the partitions */
>> -struct device_node  *of_node;
>>  struct device_node  *elm_of_node;
>>  
>>  /* deprecated */
>>  struct gpmc_nand_regs   reg;
>> +struct device_node  *of_node;
> 
> I'm a little confused here. Do you have a mixed platform data / device
> tree setup here? That's odd. (It also seems if that was really
> necessary, you could have the board file set pdev->dev.of_node before
> registering it, then you don't need this field.) But really, if you're
> partly using device tree, can't you just convert completely? Or is this
> a two-phase process, and you're planning to convert omap2 to full device
> tree?

The existing device tree implementation for omap2-nand was like this:
omap-gpmc.c driver was creating a platform device for the nand device and
passing the device node via platform data.

After this series we no longer do this and that's why of_node is marked
deprecated in platform data. I might as well could just get rid of it
but wasn't sure of how we're going to integrate the changes into the
subsystem trees so just marked it deprecated.

cheers,
-roger
--
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:

Re: [PATCH v3 04/27] mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers

[Brian Norris]

On Fri, Sep 18, 2015 at 05:53:26PM +0300, Roger Quadros wrote:
> Deprecate nand register passing via platform data and use
> gpmc_omap_get_nand_ops() instead.
> 
> Signed-off-by: Roger Quadros 
> ---
>  arch/arm/mach-omap2/gpmc-nand.c  | 2 --
>  drivers/mtd/nand/omap2.c | 9 -
>  include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
>  3 files changed, 11 insertions(+), 4 deletions(-)

This one also seems a bit oddly-split, if you're trying to allow
bringing these into different trees. The nand/omap2.c changes seem like
they can be done completely on their own (after the previous patches),
and the arch/arm/mach-omap2/gpmc-nand.c and
include/linux/platform_data/mtd-nand-omap2.h changes can come in their
own patch afterward.

That does still make things a little complicated for applying to
different trees, though, as we have some arch/arm -> drivers/mtd ->
arch/arm dependencies.

If it helps, I can try to provide Tony with a stable v4.4-rc1-based
piece of the MTD tree, and just take everything through there (with
acks). (FWIW, everything in l2-mtd.git can be considered stable,
git-wise. I've been keeping a clean history. But it'd be best to
coordinate what points to cross-merge.)

Then if we do that, we'd have to keep a close eye to make sure I don't
take any more conflicting changes to drivers/mtd/nand/omap2.c, or else
do another cross-merge...

Any better suggestions?

Brian

> 
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> index 72918c4..04e6998 100644
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -121,8 +121,6 @@ int gpmc_nand_init(struct omap_nand_platform_data 
> *gpmc_nand_data,
>   if (err < 0)
>   goto out_free_cs;
>  
> - gpmc_update_nand_reg(&gpmc_nand_data->reg, gpmc_nand_data->cs);
> -
>   if (!gpmc_hwecc_bch_capable(gpmc_nand_data->ecc_opt)) {
>   pr_err("omap2-nand: Unsupported NAND ECC scheme selected\n");
>   err = -EINVAL;
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 60fa899..f214fe2 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  
>  #define  DRIVER_NAME "omap2-nand"
> @@ -169,7 +170,9 @@ struct omap_nand_info {
>   } iomode;
>   u_char  *buf;
>   int buf_len;
> + /* Interface to GPMC */
>   struct gpmc_nand_regs   reg;
> + struct gpmc_nand_ops*ops;
>   /* generated at runtime depending on ECC algorithm and layout selected 
> */
>   struct nand_ecclayout   oobinfo;
>   /* fields specific for BCHx_HW ECC scheme */
> @@ -1677,9 +1680,13 @@ static int omap_nand_probe(struct platform_device 
> *pdev)
>  
>   platform_set_drvdata(pdev, info);
>  
> + info->ops = gpmc_omap_get_nand_ops(&info->reg, info->gpmc_cs);
> + if (!info->ops) {
> + dev_err(&pdev->dev, "Failed to get GPMC->NAND interface\n");
> + return -ENODEV;
> + }
>   info->pdev  = pdev;
>   info->gpmc_cs   = pdata->cs;
> - info->reg   = pdata->reg;
>   info->of_node   = pdata->of_node;
>   info->ecc_opt   = pdata->ecc_opt;
>   mtd = &info->mtd;
> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
> b/include/linux/platform_data/mtd-nand-omap2.h
> index 090bbab..a067f58 100644
> --- a/include/linux/platform_data/mtd-nand-omap2.h
> +++ b/include/linux/platform_data/mtd-nand-omap2.h
> @@ -75,10 +75,12 @@ struct omap_nand_platform_data {
>   enum nand_ioxfer_type;
>   int devsize;
>   enum omap_ecc   ecc_opt;
> - struct gpmc_nand_regs   reg;
>  
>   /* for passing the partitions */
>   struct device_node  *of_node;
>   struct device_node  *elm_of_node;
> +
> + /* deprecated */
> + struct gpmc_nand_regs   reg;
>  };
>  #endif
> -- 
> 2.1.4
> 
--
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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi,

On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
> Hi,
> 
> We do a couple of things in this series which result in
> cleaner device tree implementation, faster perfomance and
> multi-platform support. As an added bonus we get new GPI/Interrupt pins
> for use in the system.
> 
> - Establish a custom interface between NAND and GPMC driver. This is
> needed because all of the NAND registers sit in the GPMC register space.
> Some bits like NAND IRQ are even shared with GPMC.
> 
> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> This causes performance increase when using prefetch-irq mode.
> 30% increase in read, 17% increase in write in prefetch-irq mode.
> 
> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
> driver can be used on non-OMAP platforms. e.g. Keystone.
> 
> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
> 2 to 4 of these and most of them would be unused otherwise. It also
> allows a cleaner implementation of NAND Ready pin status for the NAND driver.
> 
> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
> 
> This series is available at
> g...@github.com:rogerq/linux.git
> in branch
> for-v4.4/gpmc-v3
> 
> cheers,
> -roger
> 
> Changelog:
> v3:
> -Fixed and tested NAND using legacy boot on omap3-beagle.
> -Support rising and falling edge interrupts on WAITpins.
> -Update DT node of all gpmc users.

The MTD stuff looks mostly good to me know. I've made all my comments
for now, but I'm not sure how you're going to end up rebasing/splitting
and what you're going to do with the irqchip removal, so I'll refrain
from ack's for now. Hopefully I can either ack or merge v4.

I brought it up on one other patch, but it's not really clear to me what
the split is on board file vs. device tree handling, since you seem to
have a combination of both (i.e., platform data that passes along device
nodes). What's the plan on that?

And of course, there's the question of how exactly to merge this, given
the:
(1) conflicts already existing in the MTD dev tree
(2) this touches several trees, often in the same patch and
(3) even if the patches were split out a little better into MTD and
non-MTD stuff, I think there would still be dependencies such that
we'd need at least 1 (probably 2) cross merges to get it all
straight

I'd be happy to hear your thoughts.

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: [PATCHv7 2/2] mailbox: Adding driver for Xilinx LogiCORE IP mailbox.

[Jassi Brar]

On 2 December 2015 at 22:56, Moritz Fischer  wrote:
> Hi Jassi,
>
> thanks for your feedback.
>
> On Mon, Aug 10, 2015 at 1:05 AM, Jassi Brar  wrote:
>> On Wed, Jul 15, 2015 at 6:30 AM, Moritz Fischer
>>  wrote:
>>
>>> +
>>> +static void xilinx_mbox_rx_data(struct mbox_chan *chan)
>>> +{
>>> +   struct xilinx_mbox *mbox = mbox_chan_to_xilinx_mbox(chan);
>>> +   u32 data;
>>> +
>>> +   if (xilinx_mbox_pending(mbox)) {
>>> +   data = readl_relaxed(mbox->mbox_base + MAILBOX_REG_RDDATA);
>>> +   mbox_chan_received_data(chan, (void *)data);
>>>
>> If RDDATA is a FIFO, then above seems wrong - you are assuming
>> messages are always going to be exactly 32-bits for every protocol.
>> Ideally you should empty the fifo fully, at least when RX has an
>> interrupt.
>
> From my understanding it's hard to tell how much actually is in the fifo,
> you can tell if it's full for send direction, or empty for read direction.
>
Simply read the whole FIFO and leave it to the client driver to parse
that data according to the protocol it drives.

> Maybe the STI / RTI can be setup in a smart way to work with multiple message
> sizes.
>>
>>> +
>>> +static int xilinx_mbox_irq_send_data(struct mbox_chan *chan, void *data)
>>> +{
>>> +   struct xilinx_mbox *mbox = mbox_chan_to_xilinx_mbox(chan);
>>> +   u32 *udata = data;
>>> +
>>> +   if (xilinx_mbox_full(mbox))
>>> +   return -EBUSY;
>>>
>> This check is redundant. last_tx_done already makes sure this is always true.
>
> Good to know. I'll fix it.
>>
>>> +   /* enable interrupt before send */
>>> +   xilinx_mbox_tx_intmask(mbox, true);
>>> +
>>> +   writel_relaxed(*udata, mbox->mbox_base + MAILBOX_REG_WRDATA);
>>> +
>> From status EMPTY and FULL, it seems WRDATA is a FIFO. So here also
>> you should expect messages to be <= fifo depth. And not assume exactly
>> 32bit messages always.
>
> How do I determine the message size?
>
Always expect any write request is exactly the size of FIFO depth.

> Doesn't
> drivers/mailbox/bcm2835-mailbox.c or
>
Well I did point it out
http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-June/001902.html
 ... but developer assumes there will _never_ be need to pass a
message bigger than 32-bits. Sadly overlooking the possibility that
some protocol might have simple, say, 64-bits wide commands and
responses that could avoid using any Shared-Memory at all.

> mailbox-altera.c make the same assumption?
>
There are 2 registers, for CMD and PRT each, that make up 1 message.
It doesn't seem like a fifo.

>>
>>> +
>>> +static bool xilinx_mbox_last_tx_done(struct mbox_chan *chan)
>>> +{
>>> +   struct xilinx_mbox *mbox = mbox_chan_to_xilinx_mbox(chan);
>>> +
>>> +   /* return false if mailbox is full */
>>> +   return !xilinx_mbox_full(mbox);
>>>
>> Instead of FULL, I think it should check for stricter EMPTY status ...
>> mbox api submits only 1 message at a time.
>
> The EMPTY status applies to the receive direction only, I could check
> the STI status
> bit though I suppose.
>
I don't know the h/w but you get my idea. So whatever is in the next revision.

> [...]
>>> +
>>> +   mbox->irq = platform_get_irq(pdev, 0);
>>> +   /* if irq is present, we can use it, otherwise, poll */
>>> +   if (mbox->irq > 0) {
>>> +   mbox->controller.txdone_irq = true;
>>> +   mbox->controller.ops = &xilinx_mbox_irq_ops;
>>> +   } else {
>>> +   dev_info(&pdev->dev, "IRQ not found, fallback to 
>>> polling.\n");
>>> +   mbox->controller.txdone_poll = true;
>>> +   mbox->controller.txpoll_period = MBOX_POLLING_MS;
>>> +   mbox->controller.ops = &xilinx_mbox_poll_ops;
>>> +
>>> +   setup_timer(&mbox->rxpoll_timer, xilinx_mbox_poll_rx,
>>> +   (unsigned long)&mbox->chan);
>>>
>> I believe there is indeed some platform that doesn't have RX-Interrupt?
>>  If no, please remove this.
>>  If yes, you may want to get some hint from platform about the size of
>> messages and do mbox_chan_received_data() only upon reading those many
>> bytes.
>
> I'd be fine to drop the polling use case for the moment, on my
> platform I can wire up the IRQ.
> We can always add it back in in a follow up use case.
>

Thanks.
--
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 v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Brian Norris]

(to be clear, this branch of discussion isn't directly regarding the TI
changes; we can handle any generic handling afterward, as long as we get
the DT binding right now)

On Tue, Oct 27, 2015 at 09:28:32AM +0100, Boris Brezillon wrote:
> On Mon, 26 Oct 2015 13:49:00 -0700
> Brian Norris  wrote:
> > On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
> > > @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device 
> > > *pdev)
> > >   info->reg = pdata->reg;
> > >   info->of_node = pdata->of_node;
> > >   info->ecc_opt = pdata->ecc_opt;
> > > - info->dev_ready = pdata->dev_ready;
> > > + if (pdata->dev_ready)
> > > + dev_info(&pdev->dev, "pdata->dev_ready is 
> > > deprecated\n");
> > > +
> > >   info->xfer_type = pdata->xfer_type;
> > >   info->devsize = pdata->devsize;
> > >   info->elm_of_node = pdata->elm_of_node;
> > > @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device 
> > > *pdev)
> > >   nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
> > >   nand_chip->cmd_ctrl  = omap_hwcontrol;
> > >  
> > > + info->ready_gpiod = devm_gpiod_get_optional(&pdev->dev, "ready",
> > > + GPIOD_IN);
> > 
> > Others have been looking at using GPIOs for the ready/busy pin too. At a
> > minimum, we need an updated DT binding doc for this, since I see you're
> > adding this via device tree in a later patch (I don't see any DT binding
> > patch for this; but I could just be overlooking it). It'd also be great
> > if this support was moved to nand_dt_init() so other platforms can
> > benefit, but I won't require that.
> 
> Actually I started to work on a generic solution parsing the DT and
> creating CS, WP and RB gpios when they are provided, but I think it's a
> bit more complicated than just moving the rb-gpios parsing into
> nand_dt_init().
> First you'll need something to store your gpio_desc pointers, which
> means you'll have to allocate a table of gpio_desc pointers (or a table
> of struct embedding a gpio_desc pointer).

I'm not sure what you mean by table. It seems like we would just have a
few gpio_desc pointers in struct nand_chip, no?

> The other blocking point is that when nand_scan_ident() is called, the
> caller is supposed to have filled the ->dev_ready() or ->waitfunc()
> fields, and to choose how to implement it he may need to know
> which kind of RB handler should be used (this is the case in the sunxi
> driver, where the user can either use a GPIO or native R/B pin directly
> connected to the controller).

Right, I was thinking about this one.

> All this makes me think that maybe nand_dt_init() should be called
> separately or in a different helper (nand_init() ?) taking care of the
> basic nand_chip initializations/allocations without interacting with
> the NAND itself.

Yeah, I feel like there have been other good reasons for something like
this before, and we just have worked around them so far. Maybe something
more like the alloc/add split in many other subsystems? e.g.,
platform_device_{alloc,add}, spi_{alloc,add}_device. Now we might want
nand_alloc()?

On a slight tangent, it seems silly that nand_scan_tail() doesn't
register the MTD, but nand_release() unregisters it. That shouldn't be.

> Another solution would be to add an ->init() function to nand_chip
> and call it after the generic initialization has been done (but before
> NAND chip detection). This way the NAND controller driver could adapt
> some fields and parse controller specific properties.

That could work too, I guess.

> What do you think?

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 v4 11/27] mtd: nand: omap: Clean up device tree support

[Brian Norris]

Hi Roger,

On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
> Move NAND specific device tree parsing to NAND driver.
> 
> The NAND controller node must have a compatible id, register space
> resource and interrupt resource.
> 
> Signed-off-by: Roger Quadros 

This one's going to need rebased, as there are some conflicting of_node
changes in l2-mtd.git.

> ---
> v4: Warn if using older incompatible DT i.e. compatible property not present
> in nand node.
> 
>  arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
>  drivers/memory/omap-gpmc.c   | 143 
> +++
>  drivers/mtd/nand/omap2.c | 136 +
>  include/linux/platform_data/mtd-nand-omap2.h |   3 +-
>  4 files changed, 155 insertions(+), 132 deletions(-)

Also, this is going to be hard to manage across trees, as you touch
three drivers all at once. Is it not possible to split any of this apart
better?

> 
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> index ffe646a..e07ca27 100644
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
> *gpmc_nand_data,
>   gpmc_nand_res[1].start = gpmc_get_irq();
>  
>   memset(&s, 0, sizeof(struct gpmc_settings));
> - if (gpmc_nand_data->of_node)
> - gpmc_read_settings_dt(gpmc_nand_data->of_node, &s);
> - else
> - gpmc_set_legacy(gpmc_nand_data, &s);
> + gpmc_set_legacy(gpmc_nand_data, &s);
>  
>   s.device_nand = true;
>  
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index e75226d..318c187 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -29,7 +29,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> @@ -1716,105 +1715,6 @@ static void __maybe_unused 
> gpmc_read_timings_dt(struct device_node *np,
>   of_property_read_bool(np, "gpmc,time-para-granularity");
>  }
>  
> -#if IS_ENABLED(CONFIG_MTD_NAND)
> -
> -static const char * const nand_xfer_types[] = {
> - [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
> - [NAND_OMAP_POLLED]  = "polled",
> - [NAND_OMAP_PREFETCH_DMA]= "prefetch-dma",
> - [NAND_OMAP_PREFETCH_IRQ]= "prefetch-irq",
> -};
> -
> -static int gpmc_probe_nand_child(struct platform_device *pdev,
> -  struct device_node *child)
> -{
> - u32 val;
> - const char *s;
> - struct gpmc_timings gpmc_t;
> - struct omap_nand_platform_data *gpmc_nand_data;
> -
> - if (of_property_read_u32(child, "reg", &val) < 0) {
> - dev_err(&pdev->dev, "%s has no 'reg' property\n",
> - child->full_name);
> - return -ENODEV;
> - }
> -
> - gpmc_nand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_nand_data),
> -   GFP_KERNEL);
> - if (!gpmc_nand_data)
> - return -ENOMEM;
> -
> - gpmc_nand_data->cs = val;
> - gpmc_nand_data->of_node = child;
> -
> - /* Detect availability of ELM module */
> - gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
> - if (gpmc_nand_data->elm_of_node == NULL)
> - gpmc_nand_data->elm_of_node =
> - of_parse_phandle(child, "elm_id", 0);
> -
> - /* select ecc-scheme for NAND */
> - if (of_property_read_string(child, "ti,nand-ecc-opt", &s)) {
> - pr_err("%s: ti,nand-ecc-opt not found\n", __func__);
> - return -ENODEV;
> - }
> -
> - if (!strcmp(s, "sw"))
> - gpmc_nand_data->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
> - else if (!strcmp(s, "ham1") ||
> -  !strcmp(s, "hw") || !strcmp(s, "hw-romcode"))
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_HAM1_CODE_HW;
> - else if (!strcmp(s, "bch4"))
> - if (gpmc_nand_data->elm_of_node)
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH4_CODE_HW;
> - else
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
> - else if (!strcmp(s, "bch8"))
> - if (gpmc_nand_data->elm_of_node)
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH8_CODE_HW;
> - else
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
> - else if (!strcmp(s, "bch16"))
> - if (gpmc_nand_data->elm_of_node)
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH16_CODE_HW;
> - else
> - pr_err("%s: BCH16 requires ELM support\n", __func__);
> - else
> - pr_err("%s: ti,na

[PATCH v2 4/9] ARM: dts: add dts files for hi3519-demb board

[Jiancheng Xue]

add dts files for hi3519-demb board

Signed-off-by: Jiancheng Xue 
---
 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/hi3519-demb.dts |  55 
 arch/arm/boot/dts/hi3519.dtsi | 129 ++
 3 files changed, 186 insertions(+)
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..39ad947 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -133,6 +133,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb \
exynos5800-peach-pi.dtb
+dtb-$(CONFIG_ARCH_HI3519) += \
+   hi3519-demb.dtb
 dtb-$(CONFIG_ARCH_HI3xxx) += \
hi3620-hi4511.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += \
diff --git a/arch/arm/boot/dts/hi3519-demb.dts 
b/arch/arm/boot/dts/hi3519-demb.dts
new file mode 100644
index 000..c7a1720
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -0,0 +1,55 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * 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, or (at your
+ * option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ */
+
+/dts-v1/;
+#include "hi3519.dtsi"
+
+/ {
+   model = "HiSilicon HI3519 DEMO Board";
+   compatible = "hisilicon,hi3519";
+
+   chosen {
+   bootargs = "mem=64M console=ttyAMA0,115200 early_printk \
+root=/dev/mtdblock2 rootfstype=jffs2 \
+mtdparts=hi_sfc:1M(boot),4M(kernel),11M(rootfs)";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0>;
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>;
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
+&dual_timer0 {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
new file mode 100644
index 000..32f08e6
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -0,0 +1,129 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * 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, or (at your
+ * option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ */
+
+#include "skeleton.dtsi"
+#include 
+/ {
+   aliases {
+   serial0 = &uart0;
+   };
+
+   gic: interrupt-controller@1030 {
+   compatible = "arm,cortex-a7-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   interrupt-parent = <&gic>;
+   ranges;
+
+   amba {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "arm,amba-bus";
+   ranges;
+
+   uart0: uart@1210 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x1210 0x1000>;
+   interrupts = <0 4 4>;
+   clocks = <&crg HI3519_UART0_CLK>;
+   clock-names = "apb_pclk";
+   status = "disable";
+   };
+
+   uart1: uart@12101000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x12101000 0x1000>;
+   interrupts = <0 5 4>;
+   clocks 

[PATCH v2 7/9] ARM: hisi: rename ARCH_HI3xxx to ARCH_HI36xx

[Jiancheng Xue]

ARCH_HI3xxx just represents hi36xx soc family.

Signed-off-by: Jiancheng Xue 
---
 arch/arm/Kconfig.debug  | 4 ++--
 arch/arm/boot/dts/Makefile  | 2 +-
 arch/arm/configs/hisi_defconfig | 2 +-
 arch/arm/configs/multi_v7_defconfig | 2 +-
 arch/arm/mach-hisi/Kconfig  | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 4d2ae2a..27d97c8 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -280,7 +280,7 @@ choice
 
config DEBUG_HI3620_UART
bool "Hisilicon HI3620 Debug UART"
-   depends on ARCH_HI3xxx
+   depends on ARCH_HI36xx
select DEBUG_UART_PL01X
help
  Say Y here if you want kernel low-level debugging support
@@ -288,7 +288,7 @@ choice
 
config DEBUG_HI3716_UART
bool "Hisilicon Hi3716 Debug UART"
-   depends on ARCH_HI3xxx
+   depends on ARCH_HI36xx
select DEBUG_UART_PL01X
help
  Say Y here if you want kernel low-level debugging support
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 39ad947..9a7ba0b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -135,7 +135,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5800-peach-pi.dtb
 dtb-$(CONFIG_ARCH_HI3519) += \
hi3519-demb.dtb
-dtb-$(CONFIG_ARCH_HI3xxx) += \
+dtb-$(CONFIG_ARCH_HI36xx) += \
hi3620-hi4511.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += \
hisi-x5hd2-dkb.dtb
diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index 321d020..3162709 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -4,7 +4,7 @@ CONFIG_HIGH_RES_TIMERS=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_RD_LZMA=y
 CONFIG_ARCH_HISI=y
-CONFIG_ARCH_HI3xxx=y
+CONFIG_ARCH_HI36xx=y
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_CMDLINE_PARTITION=y
 CONFIG_ARCH_HIX5HD2=y
diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..ddc28ce 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -38,7 +38,7 @@ CONFIG_MACH_BERLIN_BG2Q=y
 CONFIG_ARCH_DIGICOLOR=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_HISI=y
-CONFIG_ARCH_HI3xxx=y
+CONFIG_ARCH_HI36xx=y
 CONFIG_ARCH_HIX5HD2=y
 CONFIG_ARCH_HIP01=y
 CONFIG_ARCH_HIP04=y
diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index bc5b873..15f23ed 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -20,7 +20,7 @@ config ARCH_HI3519
help
  Support for Hisilicon Hi3519 Soc
 
-config ARCH_HI3xxx
+config ARCH_HI36xx
bool "Hisilicon Hi36xx family" if ARCH_MULTI_V7
select CACHE_L2X0
select HAVE_ARM_SCU if SMP
-- 
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/9] clk: hi3519: add dt-binding document and header file

[Jiancheng Xue]

add dt-binding document and header file for hi3519 clock

Signed-off-by: Jiancheng Xue 
---
 .../devicetree/bindings/clock/hi3519-crg.txt   | 46 +++
 include/dt-bindings/clock/hi3519-clock.h   | 51 ++
 2 files changed, 97 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt 
b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
new file mode 100644
index 000..e0d30a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
@@ -0,0 +1,46 @@
+* Hisilicon Hi3519 Clock and Reset Generator(CRG)
+
+The Hi3519 CRG module provides clock and reset signals to various
+controllers within the SoC.
+
+This binding uses the following bindings:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+Documentation/devicetree/bindings/reset/reset.txt
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in .
+
+- #reset-cells: should be 2.
+
+A reset signal can be controlled by writing a bit register in the CRG module.
+The reset specifier consists of two cells. The first cell represents the
+register offset relative to the base address. The second cell represents the
+bit index in the register.
+
+Example: CRG nodes
+CRG: clock-reset-controller {
+   compatible = "hisilicon,hi3519-crg";
+reg = <0x1201 0x1>;
+#clock-cells = <1>;
+#reset-cells = <2>;
+};
+
+Example: consumer nodes
+i2c0: i2c@0x1211 {
+   compatible = "hisilicon,hi3519-i2c";
+reg = <0x1211 0x1000>;
+clocks = <&CRG HI3519_I2C0_RST>;*/
+resets = <&CRG 0xE4 0>;
+};
diff --git a/include/dt-bindings/clock/hi3519-clock.h 
b/include/dt-bindings/clock/hi3519-clock.h
new file mode 100644
index 000..89c0d5e
--- /dev/null
+++ b/include/dt-bindings/clock/hi3519-clock.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * 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, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#ifndef __DTS_HI3519_CLOCK_H
+#define __DTS_HI3519_CLOCK_H
+
+/* fixed rate */
+#define HI3519_FIXED_400M  1
+#define HI3519_FIXED_200M  2
+#define HI3519_FIXED_125M  3
+#define HI3519_FIXED_150M  4
+#define HI3519_FIXED_75M   5
+#define HI3519_FIXED_300M  6
+#define HI3519_FIXED_50M   7
+#define HI3519_FIXED_24M   8
+#define HI3519_FIXED_3M9
+
+/* mux clocks */
+#define HI3519_FMC_MUX 32
+#define HI3519_I2C_MUX 33
+#define HI3519_UART_MUX34
+#define HI3519_SYSAXI_MUX  35
+
+/*fixed factor clocks*/
+#define HI3519_SYSAPB_CLK  64
+
+/* gate clocks */
+#define HI3519_FMC_CLK 129
+#define HI3519_UART0_CLK   153
+#define HI3519_UART1_CLK   154
+#define HI3519_UART2_CLK   155
+#define HI3519_UART3_CLK   156
+#define HI3519_UART4_CLK   157
+
+#define HI3519_NR_CLKS 256
+#define HI3519_NR_RSTS 256
+#endif /* __DTS_HI3519_CLOCK_H */
-- 
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 0/9] ARM: hisi: enable hi3519 soc

[Jiancheng Xue]

Hello,

Hi3519 soc is mainly used for ip camera and sport DV solutions. This patchset 
adds initial support
for Hi3519 soc. It includes clock driver, arch configuration, device tree and 
debug uart configuration.
It has been tested on hi3519 reference board.

Spi-nor flash driver and other peripheral drivers will be submitted later.

Any comments will be appreciated!

Thanks!

Change Log
--
v2:
-Rebase to v4.4-rc3
-Put dt-binding doc and header file in a separate patch.
-Delete unused clocks definitions.
-Adjust the ARCH_xxx order in Kconfig file
-Rename ARCH_HI3xxx to ARCH_36xx

Jiancheng Xue (9):
  clk: hi3519: add dt-binding document and header file
  clk: hi3519: add CRG driver for hisilicon hi3519 soc
  ARM: hisi: enable Hi3519 soc
  ARM: dts: add dts files for hi3519-demb board
  ARM: config: enable ARCH_HI3519
  ARM: debug: add Hi3519 debug uart
  ARM: hisi: rename ARCH_HI3xxx to ARCH_HI36xx
  clk: hisilicon: rename ARCH_HI3xxx to ARCH_HI36xx
  dmaengine: Kconfig: rename ARCH_HI3xxx to ARCH_HI36xx

 .../devicetree/bindings/clock/hi3519-crg.txt   |  46 +++
 arch/arm/Kconfig.debug |  14 +-
 arch/arm/boot/dts/Makefile |   4 +-
 arch/arm/boot/dts/hi3519-demb.dts  |  55 
 arch/arm/boot/dts/hi3519.dtsi  | 129 ++
 arch/arm/configs/hisi_defconfig|   3 +-
 arch/arm/configs/multi_v7_defconfig|   2 +-
 arch/arm/mach-hisi/Kconfig |  11 +-
 arch/arm/mach-hisi/hisilicon.c |   9 ++
 drivers/clk/hisilicon/Makefile |   3 +-
 drivers/clk/hisilicon/clk-hi3519.c | 100 ++
 drivers/clk/hisilicon/reset.c  | 149 +
 drivers/clk/hisilicon/reset.h  |  25 
 drivers/dma/Kconfig|   2 +-
 include/dt-bindings/clock/hi3519-clock.h   |  51 +++
 15 files changed, 595 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

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

Re: [PATCH 2/3] mtd: brcmnand: Request and enable the clock if present

[Brian Norris]

Hi Simon,

On Wed, Dec 02, 2015 at 11:42:44PM +, Simon Arlott wrote:
> Attempt to enable a clock named "nand" as some SoCs have a clock for the
> controller that needs to be enabled.
> 
> Signed-off-by: Simon Arlott 
> ---
>  drivers/mtd/nand/brcmnand/brcmnand.c | 69 
> 
>  1 file changed, 54 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index 2c8f67f..0a9cccf 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -11,6 +11,7 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -122,6 +123,9 @@ struct brcmnand_controller {
>   /* Some SoCs provide custom interrupt status register(s) */
>   struct brcmnand_soc *soc;
>  
> + /* Some SoCs have a gateable clock for the controller */
> + struct clk  *clk;
> +
>   int cmd_pending;
>   booldma_pending;
>   struct completion   done;
> @@ -2136,10 +2140,24 @@ int brcmnand_probe(struct platform_device *pdev, 
> struct brcmnand_soc *soc)
>   if (IS_ERR(ctrl->nand_base))
>   return PTR_ERR(ctrl->nand_base);
>  
> + /* Enable clock before using NAND registers */
> + ctrl->clk = devm_clk_get(dev, "nand");
> + if (!IS_ERR(ctrl->clk)) {
> + ret = clk_prepare_enable(ctrl->clk);
> + if (ret)
> + return ret;
> + } else {
> + ret = PTR_ERR(ctrl->clk);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
> + ctrl->clk = NULL;
> + }
> +
>   /* Initialize NAND revision */
>   ret = brcmnand_revision_init(ctrl);
>   if (ret)
> - return ret;
> + goto err;
>  
>   /*
>* Most chips have this cache at a fixed offset within 'nand' block.
> @@ -2148,8 +2166,10 @@ int brcmnand_probe(struct platform_device *pdev, 
> struct brcmnand_soc *soc)
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand-cache");
>   if (res) {
>   ctrl->nand_fc = devm_ioremap_resource(dev, res);
> - if (IS_ERR(ctrl->nand_fc))
> - return PTR_ERR(ctrl->nand_fc);
> + if (IS_ERR(ctrl->nand_fc)) {
> + ret = PTR_ERR(ctrl->nand_fc);
> + goto err;
> + }
>   } else {
>   ctrl->nand_fc = ctrl->nand_base +
>   ctrl->reg_offsets[BRCMNAND_FC_BASE];
> @@ -2159,8 +2179,10 @@ int brcmnand_probe(struct platform_device *pdev, 
> struct brcmnand_soc *soc)
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "flash-dma");
>   if (res) {
>   ctrl->flash_dma_base = devm_ioremap_resource(dev, res);
> - if (IS_ERR(ctrl->flash_dma_base))
> - return PTR_ERR(ctrl->flash_dma_base);
> + if (IS_ERR(ctrl->flash_dma_base)) {
> + ret = PTR_ERR(ctrl->flash_dma_base);
> + goto err;
> + }
>  
>   flash_dma_writel(ctrl, FLASH_DMA_MODE, 1); /* linked-list */
>   flash_dma_writel(ctrl, FLASH_DMA_ERROR_STATUS, 0);
> @@ -2169,13 +2191,16 @@ int brcmnand_probe(struct platform_device *pdev, 
> struct brcmnand_soc *soc)
>   ctrl->dma_desc = dmam_alloc_coherent(dev,
>sizeof(*ctrl->dma_desc),
>&ctrl->dma_pa, GFP_KERNEL);
> - if (!ctrl->dma_desc)
> - return -ENOMEM;
> + if (!ctrl->dma_desc) {
> + ret = -ENOMEM;
> + goto err;
> + }
>  
>   ctrl->dma_irq = platform_get_irq(pdev, 1);
>   if ((int)ctrl->dma_irq < 0) {
>   dev_err(dev, "missing FLASH_DMA IRQ\n");
> - return -ENODEV;
> + ret = -ENODEV;
> + goto err;
>   }
>  
>   ret = devm_request_irq(dev, ctrl->dma_irq,
> @@ -2184,7 +2209,7 @@ int brcmnand_probe(struct platform_device *pdev, struct 
> brcmnand_soc *soc)
>   if (ret < 0) {
>   dev_err(dev, "can't allocate IRQ %d: error %d\n",
>   ctrl->dma_irq, ret);
> - return ret;
> + goto err;
>   }
>  
>   dev_info(dev, "enabling FLASH_DMA\n");
> @@ -2208,7 +2233,8 @@ int brcmnand_probe(struct platform_device *pdev, struct 
> brcmnand_soc *soc)
>   ctrl->irq = platform_get_irq(pdev, 0);
>   if ((int)ctrl->irq < 0) {
>   dev_err(dev, "no IRQ defined\n");
> - return -ENODEV;
> + ret = -ENODEV;
> + goto err;
>   }
>  
>   /

Re: [PATCH 3/3] Addition of binding for firmware signals on peach-pi

[Krzysztof Kozlowski]

On 02.12.2015 18:36, Martyn Welch wrote:
> 
> 
> On 01/12/15 23:51, Krzysztof Kozlowski wrote:
>> On 02.12.2015 04:12, Martyn Welch wrote:
>>> The peach pi has a GPIO connected to the firmware write protect,
>>> developer
>>> mode and recovery mode lines. This patch adds the required nodes to the
>>> device tree to configure the pinmuxing and allow these to be read from
>>> user space.
>>>
>>> Cc: Rob Herring 
>>> Cc: Pawel Moll 
>>> Cc: Mark Rutland 
>>> Cc: Ian Campbell 
>>> Cc: Kumar Gala 
>>> Cc: Russell King 
>>> Cc: Kukjin Kim 
>>> Cc: Krzysztof Kozlowski 
>>> Cc: devicetree@vger.kernel.org
>>> Cc: linux-arm-ker...@lists.infradead.org
>>> Cc: linux-samsung-...@vger.kernel.org
>>> Signed-off-by: Martyn Welch 
>>> ---
>>>   arch/arm/boot/dts/exynos5800-peach-pi.dts | 40
>>> +++
>>>   1 file changed, 40 insertions(+)
>>
>> Hi,
>>
>> Thanks for the patch.
>>
>> Few points from my side:
>> 1. Please add a prefix to the subject: "ARM: dts:".
>>
> 
> Ok, sorry.
> 
>> 2. There is no need of such huge CC-list in the body of commit. This
>> CC-list comes from get_maintainer so there is no benefit of duplicating
>> it here. The CC is usually used to notify other people who might be
>> interested but get_maintainer does not point them.
>>
> 
> Ok, yes these were pulled from get_maintainer.
> 
>> 3. I received only this third patch. I did not receive cover letter
>> explaining possible dependencies so I am not sure how to deal with the
>> patch. It looks like there are no dependencies... but maybe there are?
>> Is this is a new binding or no? Please provide a cover letter (if it
>> exists already be sure to send it to all interested parties) or send
>> entire patchset so the big picture could be seen.
>>
> 
> I'll make sure I do that next time.
> 
> The cover letter read:
> 
> Some Chromebooks have gpio attached to signals used to cause the
> firmware to enter alternative modes of operation and/or control other
> device characteristics (such as write protection on flash devices). This
> patch adds a driver that exposes a read-only interface to allow these
> signals to be read from user space.
> 
> In addition this patch series provides the required bindings for this to
> the peach-pi Chromebook.
> 
> 
> This is a new binding, but the driver is based on functionality in the
> kernel shipped on Chromebooks. The binding has been modified based on
> the form of existing bindings in the mainline kernel.
> 
> Does that help?

Yes, that helps. With the changes above (subject and reduced CC-line in
commit message):
Reviewed-by: Krzysztof Kozlowski 

As there are no dependencies this should go through samsung-soc. Just
let us know about DT bindings being accepted/applied.

Best regards,
Krzysztof


> 
> Martyn
> 
>> The patch itself looks good but I'll wait with a review tag for #3.
>>
>> Best regards,
>> Krzysztof
>>
>>
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> index 49a4f43..485c18f 100644
>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> @@ -53,6 +53,25 @@
>>>   };
>>>   };
>>>
>>> +chromeos-firmware {
>>> +compatible = "google,gpio-firmware";
>>> +
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <&wp_gpio &dev_mode &rec_mode>;
>>> +
>>> +write-protect {
>>> +gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
>>> +};
>>> +
>>> +developer-switch {
>>> +gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
>>> +};
>>> +
>>> +recovery-switch {
>>> +gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
>>> +};
>>> +};
>>> +
>>>   gpio-keys {
>>>   compatible = "gpio-keys";
>>>
>>> @@ -731,6 +750,13 @@
>>>   samsung,pin-val = <0>;
>>>   };
>>>
>>> +rec_mode: rec-mode {
>>> +samsung,pins = "gpx0-7";
>>> +samsung,pin-function = <0>;
>>> +samsung,pin-pud = <0>;
>>> +samsung,pin-drv = <0>;
>>> +};
>>> +
>>>   tpm_irq: tpm-irq {
>>>   samsung,pins = "gpx1-0";
>>>   samsung,pin-function = <0>;
>>> @@ -752,6 +778,13 @@
>>>   samsung,pin-drv = <0>;
>>>   };
>>>
>>> +dev_mode: dev-mode {
>>> +samsung,pins = "gpx1-3";
>>> +samsung,pin-function = <0>;
>>> +samsung,pin-pud = <3>;
>>> +samsung,pin-drv = <0>;
>>> +};
>>> +
>>>   ec_irq: ec-irq {
>>>   samsung,pins = "gpx1-5";
>>>   samsung,pin-function = <0>;
>>> @@ -773,6 +806,13 @@
>>>   samsung,pin-drv = <0>;
>>>   };
>>>
>>> +wp_gpio: wp_gpio {
>>> +samsung,pins = "gpx3-0";
>>> +samsung,pin-function = <0>;
>>> +samsung,pin-pud = <0>;
>>> +samsung,pin-drv = <0>;
>>> +};
>>> +
>>>   max77802_irq: max77802-irq {
>>>   samsung,pins = "gpx3-1";
>>>   samsung,pin-function = <0>;
>>>
>>
> 
> 

--
To unsubscribe from this list: send the 

Re: [PATCH 1/2] regulator: Add brcm,bcm63xx-regulator device tree binding

[Mark Brown]

On Wed, Dec 02, 2015 at 08:26:36PM +, Simon Arlott wrote:
> On 02/12/15 12:53, Mark Brown wrote:

> > This is the sort of thing you can pick up from the SoC compatible
> > strings.  As things stand there is zero content in this driver that
> > relates to this SoC.

> There's always going to be very little content in the driver that
> relates to this SoC, given that a single bit flip enables/disables
> power.

> All other device tree drivers allow a register address to be specified
> for the device, how is an offset in the regmap any different?

It's not that it's an offset in regmap, it's that you're trying to make
a device driver with literally *no* content that is specific to the
actual device.  If you're making a driver for a specific device like
this it should know at least something about how to control the device
from the compatible string.  If you're making a generic driver it should
not make reference to specific devices.

In general I would prefer to have a driver with a SoC specific
compatible string and the data tables in the kernel, that way we keep
the device trees stable and our ABI more robust.

> >> The mask is used as there's one bit per regulator in the register, but
> >> there's more than one way to express this in the DT:

> > I wouldn't expect to see it in the device tree at all for a device
> > specific driver.

> If there isn't an individual entry in DT for each regulator, how is it
> supposed to work? There's no #regulator-cells property.

There could be one if it would help, but we do normally manage to do
this without - look at how other regulator drivers work.


signature.asc
Description: PGP signature

[PATCH 3/3] mtd: brcmnand: Add support for the BCM6368

[Simon Arlott]

The BCM6368 has a NAND interrupt register with combined status and enable
registers.

As the BCM6328, BCM6362 and BCM6368 all use v2.1 controllers, the first
variant that will work with this driver is the BCM63268 using a v4.0
controller.

Set up the device by disabling and acking all interrupts, then handle
the CTRL_READY interrupt.

Signed-off-by: Simon Arlott 
---
Renamed from BCM63268, moved clock to brcmnand.

 drivers/mtd/nand/brcmnand/Makefile   |   1 +
 drivers/mtd/nand/brcmnand/bcm6368_nand.c | 145 +++
 2 files changed, 146 insertions(+)
 create mode 100644 drivers/mtd/nand/brcmnand/bcm6368_nand.c

diff --git a/drivers/mtd/nand/brcmnand/Makefile 
b/drivers/mtd/nand/brcmnand/Makefile
index 3b1fbfd..b28ffb59 100644
--- a/drivers/mtd/nand/brcmnand/Makefile
+++ b/drivers/mtd/nand/brcmnand/Makefile
@@ -2,5 +2,6 @@
 # more specific iproc_nand.o, for instance
 obj-$(CONFIG_MTD_NAND_BRCMNAND)+= iproc_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMNAND)+= bcm63138_nand.o
+obj-$(CONFIG_MTD_NAND_BRCMNAND)+= bcm6368_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmstb_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand.o
diff --git a/drivers/mtd/nand/brcmnand/bcm6368_nand.c 
b/drivers/mtd/nand/brcmnand/bcm6368_nand.c
new file mode 100644
index 000..c347ea5
--- /dev/null
+++ b/drivers/mtd/nand/brcmnand/bcm6368_nand.c
@@ -0,0 +1,145 @@
+/*
+ * Copyright 2015 Simon Arlott
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * Derived from bcm63138_nand.c:
+ * Copyright © 2015 Broadcom Corporation
+ *
+ * Derived from 
bcm963xx_4.12L.06B_consumer/shared/opensource/include/bcm963xx/63268_map_part.h:
+ * Copyright 2000-2010 Broadcom Corporation
+ *
+ * Derived from 
bcm963xx_4.12L.06B_consumer/shared/opensource/flash/nandflash.c:
+ * Copyright 2000-2010 Broadcom Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "brcmnand.h"
+
+struct bcm6368_nand_soc {
+   struct brcmnand_soc soc;
+   void __iomem *base;
+};
+
+#define BCM6368_NAND_INT   0x00
+#define  BCM6368_NAND_STATUS_SHIFT 0
+#define  BCM6368_NAND_STATUS_MASK  (0xfff << BCM6368_NAND_STATUS_SHIFT)
+#define  BCM6368_NAND_ENABLE_SHIFT 16
+#define  BCM6368_NAND_ENABLE_MASK  (0x << BCM6368_NAND_ENABLE_SHIFT)
+#define BCM6368_NAND_BASE_ADDR00x04
+#define BCM6368_NAND_BASE_ADDR10x0c
+
+enum {
+   BCM6368_NP_READ = BIT(0),
+   BCM6368_BLOCK_ERASE = BIT(1),
+   BCM6368_COPY_BACK   = BIT(2),
+   BCM6368_PAGE_PGM= BIT(3),
+   BCM6368_CTRL_READY  = BIT(4),
+   BCM6368_DEV_RBPIN   = BIT(5),
+   BCM6368_ECC_ERR_UNC = BIT(6),
+   BCM6368_ECC_ERR_CORR= BIT(7),
+};
+
+static bool bcm6368_nand_intc_ack(struct brcmnand_soc *soc)
+{
+   struct bcm6368_nand_soc *priv =
+   container_of(soc, struct bcm6368_nand_soc, soc);
+   void __iomem *mmio = priv->base + BCM6368_NAND_INT;
+   u32 val = brcmnand_readl(mmio);
+
+   if (val & (BCM6368_CTRL_READY << BCM6368_NAND_STATUS_SHIFT)) {
+   /* Ack interrupt */
+   val &= ~BCM6368_NAND_STATUS_MASK;
+   val |= BCM6368_CTRL_READY << BCM6368_NAND_STATUS_SHIFT;
+   brcmnand_writel(val, mmio);
+   return true;
+   }
+
+   return false;
+}
+
+static void bcm6368_nand_intc_set(struct brcmnand_soc *soc, bool en)
+{
+   struct bcm6368_nand_soc *priv =
+   container_of(soc, struct bcm6368_nand_soc, soc);
+   void __iomem *mmio = priv->base + BCM6368_NAND_INT;
+   u32 val = brcmnand_readl(mmio);
+
+   /* Don't ack any interrupts */
+   val &= ~BCM6368_NAND_STATUS_MASK;
+
+   if (en)
+   val |= BCM6368_CTRL_READY << BCM6368_NAND_ENABLE_SHIFT;
+   else
+   val &= ~(BCM6368_CTRL_READY << BCM6368_NAND_ENABLE_SHIFT);
+
+   brcmnand_writel(val, mmio);
+}
+
+static int bcm6368_nand_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct bcm6368_nand_soc *priv;
+   struct brcmnand_soc *soc;
+   struct resource *res;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+   soc = &priv->soc;
+
+   res = platform_get_resource_byname(pdev,
+   IORESOURCE_MEM, "nand-intr-base");
+   if (!res)
+   return -EINVAL;
+
+   priv->base = devm_ioremap_resource(dev, r

[PATCH 2/3] mtd: brcmnand: Request and enable the clock if present

[Simon Arlott]

Attempt to enable a clock named "nand" as some SoCs have a clock for the
controller that needs to be enabled.

Signed-off-by: Simon Arlott 
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 69 
 1 file changed, 54 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 2c8f67f..0a9cccf 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -11,6 +11,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -122,6 +123,9 @@ struct brcmnand_controller {
/* Some SoCs provide custom interrupt status register(s) */
struct brcmnand_soc *soc;
 
+   /* Some SoCs have a gateable clock for the controller */
+   struct clk  *clk;
+
int cmd_pending;
booldma_pending;
struct completion   done;
@@ -2136,10 +2140,24 @@ int brcmnand_probe(struct platform_device *pdev, struct 
brcmnand_soc *soc)
if (IS_ERR(ctrl->nand_base))
return PTR_ERR(ctrl->nand_base);
 
+   /* Enable clock before using NAND registers */
+   ctrl->clk = devm_clk_get(dev, "nand");
+   if (!IS_ERR(ctrl->clk)) {
+   ret = clk_prepare_enable(ctrl->clk);
+   if (ret)
+   return ret;
+   } else {
+   ret = PTR_ERR(ctrl->clk);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+
+   ctrl->clk = NULL;
+   }
+
/* Initialize NAND revision */
ret = brcmnand_revision_init(ctrl);
if (ret)
-   return ret;
+   goto err;
 
/*
 * Most chips have this cache at a fixed offset within 'nand' block.
@@ -2148,8 +2166,10 @@ int brcmnand_probe(struct platform_device *pdev, struct 
brcmnand_soc *soc)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand-cache");
if (res) {
ctrl->nand_fc = devm_ioremap_resource(dev, res);
-   if (IS_ERR(ctrl->nand_fc))
-   return PTR_ERR(ctrl->nand_fc);
+   if (IS_ERR(ctrl->nand_fc)) {
+   ret = PTR_ERR(ctrl->nand_fc);
+   goto err;
+   }
} else {
ctrl->nand_fc = ctrl->nand_base +
ctrl->reg_offsets[BRCMNAND_FC_BASE];
@@ -2159,8 +2179,10 @@ int brcmnand_probe(struct platform_device *pdev, struct 
brcmnand_soc *soc)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "flash-dma");
if (res) {
ctrl->flash_dma_base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(ctrl->flash_dma_base))
-   return PTR_ERR(ctrl->flash_dma_base);
+   if (IS_ERR(ctrl->flash_dma_base)) {
+   ret = PTR_ERR(ctrl->flash_dma_base);
+   goto err;
+   }
 
flash_dma_writel(ctrl, FLASH_DMA_MODE, 1); /* linked-list */
flash_dma_writel(ctrl, FLASH_DMA_ERROR_STATUS, 0);
@@ -2169,13 +2191,16 @@ int brcmnand_probe(struct platform_device *pdev, struct 
brcmnand_soc *soc)
ctrl->dma_desc = dmam_alloc_coherent(dev,
 sizeof(*ctrl->dma_desc),
 &ctrl->dma_pa, GFP_KERNEL);
-   if (!ctrl->dma_desc)
-   return -ENOMEM;
+   if (!ctrl->dma_desc) {
+   ret = -ENOMEM;
+   goto err;
+   }
 
ctrl->dma_irq = platform_get_irq(pdev, 1);
if ((int)ctrl->dma_irq < 0) {
dev_err(dev, "missing FLASH_DMA IRQ\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto err;
}
 
ret = devm_request_irq(dev, ctrl->dma_irq,
@@ -2184,7 +2209,7 @@ int brcmnand_probe(struct platform_device *pdev, struct 
brcmnand_soc *soc)
if (ret < 0) {
dev_err(dev, "can't allocate IRQ %d: error %d\n",
ctrl->dma_irq, ret);
-   return ret;
+   goto err;
}
 
dev_info(dev, "enabling FLASH_DMA\n");
@@ -2208,7 +2233,8 @@ int brcmnand_probe(struct platform_device *pdev, struct 
brcmnand_soc *soc)
ctrl->irq = platform_get_irq(pdev, 0);
if ((int)ctrl->irq < 0) {
dev_err(dev, "no IRQ defined\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto err;
}
 
/*
@@ -2232,7 +2258,7 @@ int brcmnand_probe(struct platform_device *pdev, struct 
brcmnand_soc *soc)
if (ret < 0) {
dev_err(dev, "can't allocat

[PATCH 1/3] mtd: brcmnand: Add brcm,bcm6368-nand device tree binding

[Simon Arlott]

Add device tree binding for NAND on the BCM6368.

The BCM6368 has a NAND interrupt register with combined status and enable
registers. It also requires a clock, so add an optional clock to the
common brcmnand binding.

Signed-off-by: Simon Arlott 
---
Renamed from BCM63268, made clock a generic property.

 .../devicetree/bindings/mtd/brcm,brcmnand.txt  | 32 ++
 1 file changed, 32 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt 
b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
index 4ff7128..16d7835 100644
--- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
+++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
@@ -45,6 +45,8 @@ Required properties:
 - #size-cells  : <0>
 
 Optional properties:
+- clock : reference to the clock for the NAND controller
+- clock-names   : "nand" (required for the above clock)
 - brcm,nand-has-wp  : Some versions of this IP include a write-protect
   (WP) control bit. It is always available on >=
   v7.0. Use this property to describe the rare
@@ -72,6 +74,12 @@ we define additional 'compatible' properties and associated 
register resources w
and enable registers
  - reg-names: (required) "nand-int-base"
 
+   * "brcm,nand-bcm6368"
+ - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm6368"
+ - reg: (required) the 'NAND_INTR_BASE' register range, with combined 
status
+   and enable registers, and boot address registers
+ - reg-names: (required) "nand-intr-base"
+
* "brcm,nand-iproc"
  - reg: (required) the "IDM" register range, for interrupt enable and APB
bus access endianness configuration, and the "EXT" register range,
@@ -148,3 +156,27 @@ nand@f0442800 {
};
};
 };
+
+nand@1200 {
+   compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368",
+   "brcm,brcmnand-v4.0", "brcm,brcmnand";
+   reg = <0x1200 0x180>,
+ <0x1600 0x200>,
+ <0x10b0 0x10>;
+   reg-names = "nand", "nand-cache", "nand-intr-base";
+   interrupt-parent = <&periph_intc>;
+   interrupts = <50>;
+   clocks = <&periph_clk 20>;
+   clock-names = "nand";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   nand0: nandcs@0 {
+   compatible = "brcm,nandcs";
+   reg = <0>;
+   nand-on-flash-bbt;
+   nand-ecc-strength = <1>;
+   nand-ecc-step-size = <512>;
+   };
+};
-- 
2.1.4

-- 
Simon Arlott
--
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 01/28] serial: earlycon: allow MEM32 I/O for DT earlycon

[Peter Hurley]

On 11/30/2015 05:52 PM, Rob Herring wrote:
> On Mon, Nov 30, 2015 at 10:21 AM, Paul Burton  wrote:
>> Read the reg-io-width property when earlycon is setup via device tree,
>> and set the I/O type to UPIO_MEM32 when 4 is read. This behaviour
>> matches that of the of_serial driver, and is needed for DT configured
>> earlycon on the MIPS Boston board.
>>
>> Note that this is only possible when CONFIG_LIBFDT is enabled, but
>> enabling it everywhere seems like overkill. Thus systems that need this
>> functionality should select CONFIG_LIBFDT for themselves.
> 
> libfdt is enabled if you are booting from DT, so checking this
> property should not add anything.
> 
>>
>> Signed-off-by: Paul Burton 
>> ---
>>
>>  drivers/of/fdt.c  |  2 +-
>>  drivers/tty/serial/Makefile   |  1 +
>>  drivers/tty/serial/earlycon.c | 15 ++-
>>  include/linux/serial_core.h   |  2 +-
>>  4 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index d243029..71c7f0d 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -833,7 +833,7 @@ static int __init early_init_dt_scan_chosen_serial(void)
>> if (addr == OF_BAD_ADDR)
>> return -ENXIO;
>>
>> -   of_setup_earlycon(addr, match->data);
>> +   of_setup_earlycon(fdt, offset, addr, match->data);
>> return 0;
>> }
>> return -ENODEV;
>> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
>> index 5ab4111..1d290d6 100644
>> --- a/drivers/tty/serial/Makefile
>> +++ b/drivers/tty/serial/Makefile
>> @@ -7,6 +7,7 @@ obj-$(CONFIG_SERIAL_21285) += 21285.o
>>
>>  obj-$(CONFIG_SERIAL_EARLYCON) += earlycon.o
>>  obj-$(CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST) += earlycon-arm-semihost.o
>> +CFLAGS_earlycon.o += -I$(srctree)/scripts/dtc/libfdt
> 
> This is no longer necessary.
> 
>>
>>  # These Sparc drivers have to appear before others such as 8250
>>  # which share ttySx minor node space.  Otherwise console device
>> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
>> index f096360..2b936a7 100644
>> --- a/drivers/tty/serial/earlycon.c
>> +++ b/drivers/tty/serial/earlycon.c
>> @@ -17,6 +17,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -196,17 +197,29 @@ static int __init param_setup_earlycon(char *buf)
>>  }
>>  early_param("earlycon", param_setup_earlycon);
>>
>> -int __init of_setup_earlycon(unsigned long addr,
>> +int __init of_setup_earlycon(const void *fdt, int offset, unsigned long 
>> addr,
> 
> I would add iotype as a parameter instead, and then...
> 
>>  int (*setup)(struct earlycon_device *, const 
>> char *))
>>  {
>> int err;
>> struct uart_port *port = &early_console_dev.port;
>> +   const __be32 *prop;
>>
>> port->iotype = UPIO_MEM;
>> port->mapbase = addr;
>> port->uartclk = BASE_BAUD * 16;
>> port->membase = earlycon_map(addr, SZ_4K);
>>
>> +   if (config_enabled(CONFIG_LIBFDT)) {
>> +   prop = fdt_getprop(fdt, offset, "reg-io-width", NULL);
>> +   if (prop) {
>> +   switch (be32_to_cpup(prop)) {
>> +   case 4:
>> +   port->iotype = UPIO_MEM32;
>> +   break;
>> +   }
>> +   }
> 
> ...move this parsing into fdt.c where we parse the address.

FWIW, all of of_setup_earlycon() should only be #ifdef CONFIG_OF_EARLY_FLATTREE

Regards,
Peter Hurley


--
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 v7 2/6] mfd: syscon: add a DT property to set value width

[Damien Riegel]

Lee, Arnd,

I had to make changes in this patch to address Rob's comments.
reg-io-width is now in bytes while bus-width was a value in bits. Could
you please review this patch ?

Thanks,
Damien

On Mon, Nov 30, 2015 at 01:00:15PM -0600, Rob Herring wrote:
> On Mon, Nov 30, 2015 at 10:59:47AM -0500, Damien Riegel wrote:
> > Currently syscon has a fixed configuration of 32 bits for register and
> > values widths. In some cases, it would be desirable to be able to
> > customize the value width.
> > 
> > For example, certain boards (like the ones manufactured by Technologic
> > Systems) have a FPGA that is memory-mapped, but its registers are only
> > 16-bit wide.
> > 
> > This patch adds an optional "reg-io-width" DT binding for syscon that
> > allows to change the width for the data bus (i.e. val_bits). If this
> > property is provided, it will also set the register stride to
> > reg-io-width's value. If not provided, the default configuration is
> > used.
> > 
> > Signed-off-by: Damien Riegel 
> 
> Acked-by: Rob Herring 
> 
> > ---
> >  Documentation/devicetree/bindings/mfd/syscon.txt |  4 
> >  drivers/mfd/syscon.c | 13 +
> >  2 files changed, 17 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt 
> > b/Documentation/devicetree/bindings/mfd/syscon.txt
> > index fe8150b..408f768 100644
> > --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> > +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> > @@ -13,6 +13,10 @@ Required properties:
> >  - compatible: Should contain "syscon".
> >  - reg: the register region can be accessed from syscon
> >  
> > +Optional property:
> > +- reg-io-width: the size (in bytes) of the IO accesses that should be
> > +  performed on the device.
> > +
> >  Examples:
> >  gpr: iomuxc-gpr@020e {
> > compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> > diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> > index 176bf0f..b7aabee 100644
> > --- a/drivers/mfd/syscon.c
> > +++ b/drivers/mfd/syscon.c
> > @@ -47,6 +47,7 @@ static struct syscon *of_syscon_register(struct 
> > device_node *np)
> > struct syscon *syscon;
> > struct regmap *regmap;
> > void __iomem *base;
> > +   u32 reg_io_width;
> > int ret;
> > struct regmap_config syscon_config = syscon_regmap_config;
> >  
> > @@ -69,6 +70,18 @@ static struct syscon *of_syscon_register(struct 
> > device_node *np)
> >  else if (of_property_read_bool(np, "little-endian"))
> > syscon_config.val_format_endian = REGMAP_ENDIAN_LITTLE;
> >  
> > +   /*
> > +* search for reg-io-width property in DT. If it is not provided,
> > +* default to 4 bytes. regmap_init_mmio will return an error if values
> > +* are invalid so there is no need to check them here.
> > +*/
> > +   ret = of_property_read_u32(np, "reg-io-width", ®_io_width);
> > +   if (ret)
> > +   reg_io_width = 4;
> > +
> > +   syscon_config.reg_stride = reg_io_width;
> > +   syscon_config.val_bits = reg_io_width * 8;
> > +
> > regmap = regmap_init_mmio(NULL, base, &syscon_config);
> > if (IS_ERR(regmap)) {
> > pr_err("regmap init failed\n");
> > -- 
> > 2.5.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

[PATCH v2 3/4] PCI: rcar: add gen2 fallback compatibility string

[Simon Horman]

Add fallback compatibility string for R-Car Gen 2 family.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman 

---
v2
* Include "rcar-" in new compatibility string
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 13 ++---
 drivers/pci/host/pcie-rcar.c   |  1 +
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt 
b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 29d3b989d3b0..6b4d2f798386 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -1,8 +1,15 @@
 * Renesas RCar PCIe interface
 
 Required properties:
-- compatible: should contain one of the following
-   "renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791"
+compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
+   "renesas,pcie-r8a7790" for the R8A7790 SoC;
+   "renesas,pcie-r8a7791" for the R8A7791 SoC;
+   "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first
+   followed by the generic version.
+
 - reg: base address and length of the pcie controller registers.
 - #address-cells: set to <3>
 - #size-cells: set to <2>
@@ -25,7 +32,7 @@ Example:
 SoC specific DT Entry:
 
pcie: pcie@fe00 {
-   compatible = "renesas,pcie-r8a7791";
+   compatible = "renesas,pcie-r8a7791", "renesas,pcie-rcar-gen2";
reg = <0 0xfe00 0 0x8>;
#address-cells = <3>;
#size-cells = <2>;
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index f4fa6c537448..047279bdc3fe 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -917,6 +917,7 @@ static int rcar_pcie_parse_map_dma_ranges(struct rcar_pcie 
*pcie,
 
 static const struct of_device_id rcar_pcie_of_match[] = {
{ .compatible = "renesas,pcie-r8a7779", .data = rcar_pcie_hw_init_h1 },
+   { .compatible = "renesas,pcie-rcar-gen2", .data = rcar_pcie_hw_init },
{ .compatible = "renesas,pcie-r8a7790", .data = rcar_pcie_hw_init },
{ .compatible = "renesas,pcie-r8a7791", .data = rcar_pcie_hw_init },
{},
-- 
2.1.4

--
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/4] PCI: rcar-gen2: add device tree support for r8a7793

[Simon Horman]

Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.

Signed-off-by: Simon Horman 

---
* The r8a7792 is omitted from this change as the hardware in question
  does not appear to be present on that SoC.

v2
* No change
---
 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt 
b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
index 089a99dcdf10..9c50e0c9d6da 100644
--- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
+++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -8,6 +8,7 @@ OHCI and EHCI controllers.
 Required properties:
 - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
  "renesas,pci-r8a7791" for the R8A7791 SoC;
+ "renesas,pci-r8a7793" for the R8A7793 SoC;
  "renesas,pci-r8a7794" for the R8A7794 SoC;
  "renesas,pci-rcar-gen2" for a generic R-Car Gen2 compatible 
device.
 
-- 
2.1.4

--
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/4] PCI: rcar-gen2: add gen2 fallback compatibility string

[Simon Horman]

Add fallback compatibility string for R-Car Gen 2 family.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman 

---
v2
* Include "rcar-" in new compatibility string
---
 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 11 +--
 drivers/pci/host/pci-rcar-gen2.c|  1 +
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt 
b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
index 891463cb09c2..089a99dcdf10 100644
--- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
+++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -8,7 +8,14 @@ OHCI and EHCI controllers.
 Required properties:
 - compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
  "renesas,pci-r8a7791" for the R8A7791 SoC;
- "renesas,pci-r8a7794" for the R8A7794 SoC.
+ "renesas,pci-r8a7794" for the R8A7794 SoC;
+ "renesas,pci-rcar-gen2" for a generic R-Car Gen2 compatible 
device.
+
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first
+ followed by the generic version.
+
 - reg: A list of physical regions to access the device: the first is
the operational registers for the OHCI/EHCI controllers and the
second is for the bridge configuration and control registers.
@@ -32,7 +39,7 @@ Optional properties:
 Example SoC configuration:
 
pci0: pci@ee09  {
-   compatible = "renesas,pci-r8a7790";
+   compatible = "renesas,pci-r8a7790", "renesas,pci-rcar-gen2";
clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
reg = <0x0 0xee09 0x0 0xc00>,
  <0x0 0xee08 0x0 0x1100>;
diff --git a/drivers/pci/host/pci-rcar-gen2.c b/drivers/pci/host/pci-rcar-gen2.c
index 62951165dcbb..9980a4bdae7e 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -430,6 +430,7 @@ static int rcar_pci_probe(struct platform_device *pdev)
 }
 
 static struct of_device_id rcar_pci_of_match[] = {
+   { .compatible = "renesas,pci-rcar-gen2", },
{ .compatible = "renesas,pci-r8a7790", },
{ .compatible = "renesas,pci-r8a7791", },
{ .compatible = "renesas,pci-r8a7794", },
-- 
2.1.4

--
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 4/4] PCI: rcar: add device tree support for r8a7793

[Simon Horman]

Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.

Signed-off-by: Simon Horman 

---
* The r8a7792 and r8a7794 are omitted from this change as the
  hardware in question does not appear to be present on those SoCs.

v2
* No change
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt 
b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 6b4d2f798386..d529530b27d2 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -4,6 +4,7 @@ Required properties:
 compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
"renesas,pcie-r8a7790" for the R8A7790 SoC;
"renesas,pcie-r8a7791" for the R8A7791 SoC;
+   "renesas,pcie-r8a7793" for the R8A7793 SoC;
"renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
 
When compatible with the generic version, nodes must list the
-- 
2.1.4

--
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 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings

[Simon Horman]

Hi,

this short series adds generic gen2 and SoC-specific r8a7793 compatibility
strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to
provide a complete set of compatibility strings for known Gen2 SoCs.

Key Changes in v2:
* Include "rcar-" in generic bindings

Simon Horman (4):
  PCI: rcar-gen2: add gen2 fallback compatibility string
  PCI: rcar-gen2: add device tree support for r8a7793
  PCI: rcar: add gen2 fallback compatibility string
  PCI: rcar: add device tree support for r8a7793

 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 12 ++--
 Documentation/devicetree/bindings/pci/rcar-pci.txt  | 14 +++---
 drivers/pci/host/pci-rcar-gen2.c|  1 +
 drivers/pci/host/pcie-rcar.c|  1 +
 4 files changed, 23 insertions(+), 5 deletions(-)

-- 
2.1.4

--
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 2/2] ARM: shmobile: r8a7791: add EtherAVB DT support

[Sergei Shtylyov]

Define the generic R8A7791 part of the EtherAVB device node. 

Based on the commit f25d6b977240 ("ARM: shmobile: r8a7790: add EtherAVB DT
support").

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7791.dtsi |   12 
 1 file changed, 12 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -785,6 +785,18 @@
status = "disabled";
};
 
+   avb: ethernet@e680 {
+   compatible = "renesas,etheravb-r8a7791",
+"renesas,etheravb-rcar-gen2";
+   reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
+   interrupts = <0 163 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&mstp8_clks R8A7791_CLK_ETHERAVB>;
+   power-domains = <&cpg_clocks>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
sata0: sata@ee30 {
compatible = "renesas,sata-r8a7791";
reg = <0 0xee30 0 0x2000>;

--
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 1/2] ARM: shmobile: r8a7791: add EtherAVB clock

[Sergei Shtylyov]

Add the EtherAVB clock to the R8A7791 device tree.

Based on the commit 63d2d750c902 ("ARM: shmobile: r8a7790: add EtherAVB
clocks").

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7791.dtsi|   10 ++
 include/dt-bindings/clock/r8a7791-clock.h |1 +
 2 files changed, 7 insertions(+), 4 deletions(-)

Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -1329,16 +1329,18 @@
compatible = "renesas,r8a7791-mstp-clocks", 
"renesas,cpg-mstp-clocks";
reg = <0 0xe6150990 0 4>, <0 0xe61509a0 0 4>;
clocks = <&zx_clk>, <&hp_clk>, <&zg_clk>, <&zg_clk>,
-<&zg_clk>, <&p_clk>, <&zs_clk>, <&zs_clk>;
+<&zg_clk>, <&hp_clk>, <&p_clk>, <&zs_clk>,
+<&zs_clk>;
#clock-cells = <1>;
clock-indices = <
R8A7791_CLK_IPMMU_SGX R8A7791_CLK_MLB
R8A7791_CLK_VIN2 R8A7791_CLK_VIN1 
R8A7791_CLK_VIN0
-   R8A7791_CLK_ETHER R8A7791_CLK_SATA1 
R8A7791_CLK_SATA0
+   R8A7791_CLK_ETHERAVB R8A7791_CLK_ETHER
+   R8A7791_CLK_SATA1 R8A7791_CLK_SATA0
>;
clock-output-names =
-   "ipmmu_sgx", "mlb", "vin2", "vin1", "vin0", 
"ether",
-   "sata1", "sata0";
+   "ipmmu_sgx", "mlb", "vin2", "vin1", "vin0",
+   "etheravb", "ether", "sata1", "sata0";
};
mstp9_clks: mstp9_clks@e6150994 {
compatible = "renesas,r8a7791-mstp-clocks", 
"renesas,cpg-mstp-clocks";
Index: renesas/include/dt-bindings/clock/r8a7791-clock.h
===
--- renesas.orig/include/dt-bindings/clock/r8a7791-clock.h
+++ renesas/include/dt-bindings/clock/r8a7791-clock.h
@@ -102,6 +102,7 @@
 #define R8A7791_CLK_VIN2   9
 #define R8A7791_CLK_VIN1   10
 #define R8A7791_CLK_VIN0   11
+#define R8A7791_CLK_ETHERAVB   12
 #define R8A7791_CLK_ETHER  13
 #define R8A7791_CLK_SATA1  14
 #define R8A7791_CLK_SATA0  15

--
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 0/2] Add R8A7791 EtherAVB DT support

[Sergei Shtylyov]

Hello.

   Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20151201-v4.4-rc3' tag. Here we add the EtherAVB device tree
support for the R8A7791 SoC. The 2nd patch depends on the Simon's recent
EtherAVB driver patches in order to work...

[1/2] ARM: shmobile: r8a7791: add EtherAVB clock
[2/2] ARM: shmobile: r8a7791: add EtherAVB DT support

WBR, Sergei

--
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: Preprocessor arithmetic in dtsi files (base + offset)

[Mason]

On 26/11/2015 17:23, Geert Uytterhoeven wrote:

> I guess this would work, too?
> 
> scu_container@2000 {
> compatible = "simple-bus";
> 
> ranges = <0x0 0x2000 0x1>;
> #address-cells = <1>;
> #size-cells = <1>;
> 
> scu: scu@0 {
> compatible = "arm,cortex-a9-scu";
> reg = <0x 0x100>;
> 
> gic: interrupt-controller@1000 {
> compatible = "arm,cortex-a9-gic";
> reg = <0x1000 0x1000>, <0x0100 0x0100>;
> 
> twd-timer@0600 {
> compatible = "arm,cortex-a9-twd-timer";
> reg = <0x0600 0x10>;
> };
> 
> No more explicit arithmetic needed, just substitute "2000".

I like it! Only one address to change in the next chip.
Minimizes the risk of missing something.

(I see that armada did something similar, but they also grouped
unrelated stuff. And bcm5301x did exactly what you suggested.)

Wondering if there are macro definitions for the intra-SCU offsets?
So I could have symbolic names, such as

  twd-timer@0600 {
reg = 

Didn't see anything appropriate in include and arch/arm.
Should I include my own definitions at the top of the dtsi?

Regards.

--
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 2/2] ARM: dts: vf-colibri: add CAN support

[Stefan Agner]

Add Colibri standard pinmux for FlexCAN controller instances. CAN
is not a standard Colibri feature, but the datasheet predefines
pins which provide CAN (compatible across some modules). Hence,
add the pinmux on module level.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 924b660..4f798a8 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -23,6 +23,18 @@
status = "okay";
 };
 
+&can0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_flexcan0>;
+   status = "disabled";
+};
+
+&can1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_flexcan1>;
+   status = "disabled";
+};
+
 &dspi1 {
bus-num = <1>;
pinctrl-names = "default";
@@ -125,6 +137,20 @@
 
 &iomuxc {
vf610-colibri {
+   pinctrl_flexcan0: can0grp {
+   fsl,pins = <
+   VF610_PAD_PTB14__CAN0_RX0x31F1
+   VF610_PAD_PTB15__CAN0_TX0x31F2
+   >;
+   };
+
+   pinctrl_flexcan1: can1grp {
+   fsl,pins = <
+   VF610_PAD_PTB16__CAN1_RX0x31F1
+   VF610_PAD_PTB17__CAN1_TX0x31F2
+   >;
+   };
+
pinctrl_gpio_ext: gpio_ext {
fsl,pins = <
VF610_PAD_PTD10__GPIO_890x22ed /* 
EXT_IO_0 */
-- 
2.6.2

--
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 1/2] ARM: dts: vf-colibri: split PWM pinctrl

[Stefan Agner]

Split PWM pins into separate pinctrl nodes to allow overrides which
select pins individually. This is useful for carrier boards which use
only one pin for PWM and would like to use the other pin for a
different purpose.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index e5949b9..924b660 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -74,12 +74,12 @@
 
 &pwm0 {
pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_pwm0>;
+   pinctrl-0 = <&pinctrl_pwm0_a &pinctrl_pwm0_c>;
 };
 
 &pwm1 {
pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_pwm1>;
+   pinctrl-0 = <&pinctrl_pwm1_b &pinctrl_pwm1_d>;
 };
 
 &uart0 {
@@ -195,16 +195,26 @@
>;
};
 
-   pinctrl_pwm0: pwm0grp {
+   pinctrl_pwm0_a: pwm0agrp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
+   >;
+   };
+
+   pinctrl_pwm0_c: pwm0cgrp {
+   fsl,pins = <
VF610_PAD_PTB1__FTM0_CH10x1182
>;
};
 
-   pinctrl_pwm1: pwm1grp {
+   pinctrl_pwm1_b: pwm1bgrp {
fsl,pins = <
VF610_PAD_PTB8__FTM1_CH00x1182
+   >;
+   };
+
+   pinctrl_pwm1_d: pwm1dgrp {
+   fsl,pins = <
VF610_PAD_PTB9__FTM1_CH10x1182
>;
};
-- 
2.6.2

--
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/4] ARM: dts: vf610: relicense the device trees under GPLv2/X11

[Stefan Agner]

Hi,

[added latest email address of Matt Porter]

There are only a few Acks missing.

I still miss an answer from a Freescale developer. Yuan, Cosmin or
Frank, any chance to get an ack on this?

--
Stefan


On 2015-11-23 15:57, Stefan Agner wrote:
> The GPLv2 license makes it impractical for other software components
> licensed under another license to use our device trees. To fix this,
> and make our device tree usable by other software components, relicense
> them under a GPLv2/X11 dual-license.
> 
> In order to get this accepted, we *need* all contributors to the Vybrid
> device tree files to send an ack to the patches applying on a file they
> contributed on.
> 
> I think some Freescale email addresses are not valid anymore, can someone
> from Freescale make an ack on their behalf?
> 
> The needed Acked-by by device tree are:
> 
> vf???.dtsi:
>   Bhuvanchandra DV 
>   Chao Fu 
>   Cory Tusar 
>   Cosmin Stoica 
>   Frank Li 
>   Fugang Duan 
>   Huang Shijie 
>   Jingchang Lu 
>   Lucas Stach 
>   Sanchayan Maity 
>   Shawn Guo 
>   Stephen Warren 
>   Xiubo Li 
>   Yuan Yao 
> 
> vf610-colibri:
>   Bhuvanchandra DV 
>   Cory Tusar 
>   Sanchayan Maity 
> 
> vf610-cosmic:
>   Cory Tusar 
>   Matt Porter 
>   Olof Johansson 
>   Shawn Guo 
> 
> vf610-twr:
>   Bill Pringlemeir 
>   Chao Fu 
>   Cory Tusar 
>   Cosmin Stoica 
>   Fugang Duan 
>   Jingchang Lu 
>   Shawn Guo 
>   Xiubo Li 
> 
> CC: Bhuvanchandra DV 
> CC: Bill Pringlemeir 
> CC: Chao Fu 
> CC: Cory Tusar 
> CC: Cosmin Stoica 
> CC: Frank Li 
> CC: Fugang Duan 
> CC: Huang Shijie 
> CC: Jingchang Lu 
> CC: Jingchang Lu 
> CC: Lucas Stach 
> CC: Matt Porter 
> CC: Olof Johansson 
> CC: Sanchayan Maity 
> CC: Shawn Guo 
> CC: Stephen Warren 
> CC: Xiubo Li 
> CC: Yuan Yao 
> 
> Stefan Agner (4):
>   ARM: dts: vf610: relicense vf???.dtsi under GPLv2/X11
>   ARM: dts: vf610-colibri: relicense vf*colibri* under GPLv2/X11
>   ARM: dts: vf610-cosmic: relicense vf610-cosmic.dts under GPLv2/X11
>   ARM: dts: vf610-twr: relicense vf610-twr.dts under GPLv2/X11
> 
>  arch/arm/boot/dts/vf-colibri-eval-v3.dtsi   | 40 ---
>  arch/arm/boot/dts/vf-colibri.dtsi   | 40 ---
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 40 ---
>  arch/arm/boot/dts/vf500-colibri.dtsi| 40 ---
>  arch/arm/boot/dts/vf500.dtsi| 40 ---
>  arch/arm/boot/dts/vf610-colibri-eval-v3.dts | 42 
> +
>  arch/arm/boot/dts/vf610-colibri.dtsi| 40 ---
>  arch/arm/boot/dts/vf610-cosmic.dts  | 40 ---
>  arch/arm/boot/dts/vf610-twr.dts | 40 ---
>  arch/arm/boot/dts/vf610.dtsi| 40 ---
>  arch/arm/boot/dts/vfxxx.dtsi| 40 ---
>  11 files changed, 397 insertions(+), 45 deletions(-)
--
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/3] Device tree binding documentation for chromeos-firmware

[Martyn Welch]

On 02/12/15 18:44, Rob Herring wrote:

On Wed, Dec 2, 2015 at 10:49 AM, Martyn Welch
 wrote:



On 02/12/15 15:15, Rob Herring wrote:


On Tue, Dec 01, 2015 at 07:12:49PM +, Martyn Welch wrote:


This patch adds documentation for the chromeos-firmware binding.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: devicetree@vger.kernel.org
Signed-off-by: Martyn Welch 
---
   .../devicetree/bindings/misc/chromeos-firmware.txt | 27
++



bindings/firmware/ please.



OK.


   1 file changed, 27 insertions(+)
   create mode 100644
Documentation/devicetree/bindings/misc/chromeos-firmware.txt

diff --git a/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
new file mode 100644
index 000..8240611
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
@@ -0,0 +1,27 @@
+Device-Tree bindings for chromeos-firmware.c.



Perhaps a bit more description what this is.

What aspect of this is firmware? How does this relate to the EC?



With respect to write-protect, this line is the write protection for the
flash which holds the bootloader.


What is driving the write-protect? Are trying to assign ownership of
the SOC GPIOs to the bootloader/firmware? If so, I think this is all
wrong.



The lines are typically driven by a debugging board plugged into a 
socket on the Chromebooks motherboard, not by the device it's self. The 
driver exposes a read-only interface to these signals.


Martyn
--
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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Florian Fainelli]

On 02/12/15 12:02, Simon Arlott wrote:
> On 02/12/15 19:38, Florian Fainelli wrote:
>> 2015-12-02 11:05 GMT-08:00 Brian Norris :
>>> + Broadcom list + Kamal
>>>
>>> On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote:
 Add device tree binding for NAND on the BCM63268.

 The BCM63268 has a NAND interrupt register with combined status and enable
 registers.

 Signed-off-by: Simon Arlott 
 ---
  .../devicetree/bindings/mtd/brcm,brcmnand.txt  | 35 
 ++
  1 file changed, 35 insertions(+)

 diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
 b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
 index 4ff7128..f2a71c8 100644
 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
 +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
 @@ -72,6 +72,14 @@ we define additional 'compatible' properties and 
 associated register resources w
 and enable registers
   - reg-names: (required) "nand-int-base"

 +   * "brcm,nand-bcm63268"
 + - compatible: should contain "brcm,nand-bcm", 
 "brcm,nand-bcm63268"
>>>
>>> Looks like you're aiming to support bcm63168? Is bcm63268 the first
>>> chip to include this style of register then? The numbering seems
>>> backwards, but that may just be reality.
>>
>> 6362 (NAND rev 2.1, ann. Sep 8, 2009), 6368 (v0.1?!?, ann. Jan 7,
>> 2009) and 6328 (v2.1, can't find release date) are earlier chips that
>> have an identical combined interrupt enable + status register and a
>> NAND controller within the same 32-bits word, so these would qualify
>> as a better compatible string for this specific addition integration
>> stub here. I would gowith 6368 here then?
>>
> 
> I could change it to 6368 but there's no documented NAND_INTR_BASE for
> it. Only the 63268 and 6818 have a #define for NAND_INTR_BASE.
> 

It looks exactly the same as the 63268 layout, and double checking, this
appears to be a v2.1 controller as well, it was not just properly
documented as such.
-- 
Florian
--
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/2] reset: Add brcm,bcm6345-reset device tree binding

[Simon Arlott]

Add device tree binding for the BCM6345 soft reset controller.

The BCM6345 contains a soft-reset controller activated by setting
a bit (that must previously have cleared).

Signed-off-by: Simon Arlott 
---
Renamed to bcm6345, removed "mask" property.

 .../bindings/reset/brcm,bcm6345-reset.txt  | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt

diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt 
b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
new file mode 100644
index 000..bb9ca6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
@@ -0,0 +1,33 @@
+Broadcom BCM6345 reset controller
+
+The BCM6345 contains a basic soft reset controller in the perf register
+set which resets components using a bit in a register.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible:  Should be "brcm,bcm-reset", "brcm,bcm6345-reset"
+- regmap:  The register map phandle
+- offset:  Offset in the register map for the reset register (in bytes)
+- #reset-cells:Must be set to 1
+
+Example:
+
+periph_soft_rst: reset-controller {
+   compatible = "brcm,bcm63168-reset", "brcm,bcm6345-reset";
+   regmap = <&periph_cntl>;
+   offset = <0x10>;
+
+   #reset-cells = <1>;
+};
+
+usbh: usbphy@10002700 {
+   compatible = "brcm,bcm63168-usbh";
+   reg = <0x10002700 0x38>;
+   clocks = <&periph_clk 13>, <&timer_clk 18>;
+   resets = <&periph_soft_rst 6>;
+   power-supply = <&power_usbh>;
+   #phy-cells = <0>;
+};
+
-- 
2.1.4

-- 
Simon Arlott
--
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/2] reset: bcm6345: Add support for the BCM6345 soft-reset controller

[Simon Arlott]

The BCM6345 contains a soft-reset controller activated by setting
a bit (that must previously have cleared).

Signed-off-by: Simon Arlott 
---
 MAINTAINERS   |   1 +
 drivers/reset/Kconfig |   1 +
 drivers/reset/Makefile|  17 +++---
 drivers/reset/bcm/Kconfig |  10 
 drivers/reset/bcm/Makefile|   1 +
 drivers/reset/bcm/reset-bcm6345.c | 109 ++
 6 files changed, 131 insertions(+), 8 deletions(-)
 create mode 100644 drivers/reset/bcm/Kconfig
 create mode 100644 drivers/reset/bcm/Makefile
 create mode 100644 drivers/reset/bcm/reset-bcm6345.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 07613dd..a20cecf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2378,6 +2378,7 @@ F:drivers/irqchip/irq-bcm63*
 F: drivers/irqchip/irq-bcm7*
 F: drivers/irqchip/irq-brcmstb*
 F: drivers/regulator/bcm63*
+F: drivers/reset/bcm/reset-bcm6345*
 F: include/linux/bcm63xx_wdt.h
 
 BROADCOM TG3 GIGABIT ETHERNET DRIVER
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..ee73f5f 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -12,4 +12,5 @@ menuconfig RESET_CONTROLLER
 
  If unsure, say no.
 
+source "drivers/reset/bcm/Kconfig"
 source "drivers/reset/sti/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 85d5904..a34f469 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,8 +1,9 @@
-obj-$(CONFIG_RESET_CONTROLLER) += core.o
-obj-$(CONFIG_ARCH_LPC18XX) += reset-lpc18xx.o
-obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
-obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
-obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
-obj-$(CONFIG_ARCH_STI) += sti/
-obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
-obj-$(CONFIG_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_CONTROLLER) += core.o
+obj-$(CONFIG_ARCH_LPC18XX) += reset-lpc18xx.o
+obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
+obj-$(CONFIG_ARCH_BERLIN)  += reset-berlin.o
+obj-$(CONFIG_ARCH_SUNXI)   += reset-sunxi.o
+obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_ARCH_ZYNQ)+= reset-zynq.o
+obj-$(CONFIG_ATH79)+= reset-ath79.o
+obj-y  += bcm/
diff --git a/drivers/reset/bcm/Kconfig b/drivers/reset/bcm/Kconfig
new file mode 100644
index 000..85931c9
--- /dev/null
+++ b/drivers/reset/bcm/Kconfig
@@ -0,0 +1,10 @@
+if RESET_CONTROLLER
+
+config RESET_BCM6345
+   bool "BCM6345 Reset Controller"
+   depends on BMIPS_GENERIC
+   default BMIPS_GENERIC
+   help
+ Support resetting of devices on BCM6345 boards.
+
+endif
diff --git a/drivers/reset/bcm/Makefile b/drivers/reset/bcm/Makefile
new file mode 100644
index 000..3d004bd
--- /dev/null
+++ b/drivers/reset/bcm/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_RESET_BCM6345)+= reset-bcm6345.o
diff --git a/drivers/reset/bcm/reset-bcm6345.c 
b/drivers/reset/bcm/reset-bcm6345.c
new file mode 100644
index 000..a95433d
--- /dev/null
+++ b/drivers/reset/bcm/reset-bcm6345.c
@@ -0,0 +1,109 @@
+/*
+ * Copyright 2015 Simon Arlott
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Derived from reset-berlin.c:
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Tenart 
+ * Sebastian Hesselbarth 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define to_bcm6345_reset_priv(p) \
+   container_of((p), struct bcm6345_reset_priv, rcdev)
+
+struct bcm6345_reset_priv {
+   struct regmap *map;
+   u32 offset;
+   struct reset_controller_dev rcdev;
+   struct mutex mutex;
+};
+
+static int bcm6345_reset_reset(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   struct bcm6345_reset_priv *priv = to_bcm6345_reset_priv(rcdev);
+
+   mutex_lock(&priv->mutex);
+   regmap_write_bits(priv->map, priv->offset, BIT(id), 0);
+   usleep_range(1, 2);
+   regmap_write_bits(priv->map, priv->offset, BIT(id), BIT(id));
+   usleep_range(1, 2);
+   mutex_unlock(&priv->mutex);
+
+   return 0;
+}
+
+static struct reset_control_ops bcm6345_reset_ops = {
+   .reset = bcm6345_reset_reset,
+};
+
+static int __init bcm6345_reset_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct bcm6345_reset_priv *priv;
+   int ret;
+
+   priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   mutex_init(&priv->mutex);
+
+   priv->map = syscon_regmap_lookup_by_phandle(np, "regmap");
+   if (IS_ERR(priv->map))
+   return PTR_ERR(priv->map);
+
+   if (of_property_read_u32(np, "offset", &priv->offset))
+   return -EIN

Re: [PATCH v4 3/7] ARM: dts: imx: Add Advantech BA-16 Qseven module

[Akshay Bhat]

On 12/02/2015 02:36 PM, Arnd Bergmann wrote:

On Wednesday 02 December 2015 13:16:16 Akshay Bhat wrote:

+   brightness-levels = <  0   1   2   3   4   5   6   7   8   9
+ 10  11  12  13  14  15  16  17  18  19
+ 20  21  22  23  24  25  26  27  28  29
+ 30  31  32  33  34  35  36  37  38  39
+ 40  41  42  43  44  45  46  47  48  49
+ 50  51  52  53  54  55  56  57  58  59
+ 60  61  62  63  64  65  66  67  68  69
+ 70  71  72  73  74  75  76  77  78  79
+ 80  81  82  83  84  85  86  87  88  89
+ 90  91  92  93  94  95  96  97  98  99
+100 101 102 103 104 105 106 107 108 109
+110 111 112 113 114 115 116 117 118 119
+120 121 122 123 124 125 126 127 128 129
+130 131 132 133 134 135 136 137 138 139
+140 141 142 143 144 145 146 147 148 149
+150 151 152 153 154 155 156 157 158 159
+160 161 162 163 164 165 166 167 168 169
+170 171 172 173 174 175 176 177 178 179
+180 181 182 183 184 185 186 187 188 189
+190 191 192 193 194 195 196 197 198 199
+200 201 202 203 204 205 206 207 208 209
+210 211 212 213 214 215 216 217 218 219
+220 221 222 223 224 225 226 227 228 229
+230 231 232 233 234 235 236 237 238 239
+240 241 242 243 244 245 246 247 248 249
+250 251 252 253 254 255>;



That is a lot of brightness levels. Why do you need so many of them?

Arnd


Hi Arnd,

The product allows for a fine grained selection of the LCD brightness 
(analogy might be a laptop brightness slider), hence all possible levels 
have been included.


Thanks,
Akshay
--
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 v4 1/2] watchdog: imx2_wdt: add external reset support via 'ext-reset-output' dt prop

[Tim Harvey]

On Wed, Dec 2, 2015 at 11:11 AM, Akshay Bhat  wrote:
>
>
> On 11/06/2015 05:02 PM, Guenter Roeck wrote:
>>
>> On Fri, Nov 06, 2015 at 11:53:42AM -0800, Tim Harvey wrote:
>>>
>>> On Thu, Nov 5, 2015 at 2:23 PM, Guenter Roeck  wrote:

 On Thu, Nov 05, 2015 at 04:19:21PM -0500, Akshay Bhat wrote:
>
> From: Tim Harvey 
>
> The IMX6 watchdog supports assertion of a signal (WDOG_B) which
> can be pinmux'd to an external pin. This is typically used for boards
> that
> have PMIC's in control of the IMX6 power rails. In fact, failure to use
> such an external reset on boards with external PMIC's can result in
> various
> hangs due to the IMX6 not being fully reset [1] as well as the board
> failing
> to reset because its PMIC has not been reset to provide adequate
> voltage for
> the CPU when coming out of reset at 800Mhz.
>
> This uses a new device-tree property 'ext-reset-output' to indicate the
> board has such a reset and to cause the watchdog to be configured to
> assert
> WDOG_B instead of an internal reset both on a watchdog timeout and in
> system_restart.
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html
>
> Cc: Lucas Stach 
> Signed-off-by: Tim Harvey 
> ---
>   .../devicetree/bindings/watchdog/fsl-imx-wdt.txt |  2 ++
>   drivers/watchdog/imx2_wdt.c  | 20
> ++--
>   2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> index 8dab6fd..9b89b3a 100644
> --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> @@ -9,6 +9,8 @@ Optional property:


 properties ?

>   - big-endian: If present the watchdog device's registers are
> implemented
> in big endian mode, otherwise in native mode(same with CPU), for
> more
> detail please see:
> Documentation/devicetree/bindings/regmap/regmap.txt.
> +- ext-reset-output: If present the watchdog device is configured to
> assert its


 Should that have a vendor prefix ? Also, not sure if "-output"
 has any real value in the property name. "fsl,external-reset", maybe ?
>>>
>>>
>>> Hi Guenter,
>>>
>>> I don't see why a vendor prefix is necessary - its a feature of the
>>> IMX6 watchdog supported by this driver to be able to trigger an
>>> internal chip-level reset and/or an external signal that can be hooked
>>> to additional hardware.
>>>
>> Sounded like vendor specific to me, but then I am not a devicetree
>> maintainer,
>> so I am not an authority on the subject.
>
>
> Devicetree maintainers,
>
> Any thoughts?
>
> Tim,
>
> After looking at all the other watchdog drivers, it does not appear that
> there is any other processor which uses a similar feature. Since imx is the
> only processor that appears to support this feature, it might make sense in
> making this vendor specific. If in the future it is found more processors
> support a similar functionality, it can be revisited and moved out from
> being vendor specific?
>

I'm certainly no expert on device-tree policy. I understand your
point, but realize that the driver in question is imx2_wdt.c
(compatible = "fsl,imx21-wdt"). This is an IP block inside the silicon
of only Freescale chips, so its not like a future omap chip would be
using this driver - only fsl devices. So why would it need a 'vendor'
property any more than its other properties?

Regards,

Tim
--
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] ARM: dts: vf610: use reset values for L2 cache latencies

[Stefan Agner]

On 2015-12-02 00:13, Shawn Guo wrote:
> On Mon, Nov 30, 2015 at 05:59:26PM -0800, Stefan Agner wrote:
>> Linux on Vybrid used several different L2 latencies so far, none
>> of them seem to be the right ones. According to the application note
>> AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
>> on CPU clock and is inside the L2 cache controller, whereas the data
>> portion is stored in the external SRAM running on platform clock.
>> Hence it is likely that the correct value requires a higher data
>> latency then tag latency.
>> 
>> These are the values which have been used so far:
>> - The mainline values:
>>   arm,data-latency = <1 1 1>;
>>   arm,tag-latency = <2 2 2>;
>>   Those values have lead to problems on higher clocks. They look
>>   like a poor translation from the reset values (missing +1 offset
>>   and a mix up between tag/latency values).
>> - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
>>   arm,data-latency = <4 2 3>
>>   arm,tag-latency = <4 2 3>
>>   The cache initialization function along with the value matches the
>>   i.MX6 code from the same kernel, so it seems that those values have
>>   just been copied.
>> - The Colibri values:
>>   arm,data-latency = <2 1 2>;
>>   arm,tag-latency = <3 2 3>;
>>   Those were a mix between the values of the Linux 3.0 based BSP and
>>   the mainline values above.
>> - The SoC Reset values (converted to DT notation):
>>   arm,data-latency = <3 3 3>;
>>   arm,tag-latency = <2 2 2>;
>> 
>> So far there is no official statement on what the correct values are.
>> See also the related Freescale community thread:
>> https://community.freescale.com/message/579785#579785
>> 
>> For now, the reset values seem to be the best bet. Remove all other
>> "bogus" values and use the reset value on vf610.dtsi level.
>> 
>> Signed-off-by: Stefan Agner 
>> ---
>> Hi Shawn,
>> 
>> Any chance to get this into 4.4?
> 
> I can try.  Generally, upstream maintainers are becoming more strict for
> -rc inclusion after -rc3 phase.  Do you have any user stories about why
> this is a critical/urgent fix?  If we send this a critical fix for 4.4-rc
> inclusion, do we need to Cc stable?

It came up a while ago on Freescale community, but I think that user
used downstream BSP's:
https://community.freescale.com/thread/332326

The Colibri VF61 board overwrites the latency, so it is not really
critical for this board.

The Freescale Tower runs at 400MHz by default, but has a CPU which would
support up to 500MHz. I am pretty sure with 500MHz CPU clock, things
will go south with current settings.

Regarding stable: Would probably be consistent...

--
Stefan


> 
> Shawn
> 
>> 
>> --
>> Stefan
>> 
>>  arch/arm/boot/dts/vf610-colibri.dtsi | 5 -
>>  arch/arm/boot/dts/vf610.dtsi | 2 +-
>>  2 files changed, 1 insertion(+), 6 deletions(-)
>> 
>> diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi 
>> b/arch/arm/boot/dts/vf610-colibri.dtsi
>> index 19fe045..2d7eab7 100644
>> --- a/arch/arm/boot/dts/vf610-colibri.dtsi
>> +++ b/arch/arm/boot/dts/vf610-colibri.dtsi
>> @@ -18,8 +18,3 @@
>>  reg = <0x8000 0x1000>;
>>  };
>>  };
>> -
>> -&L2 {
>> -arm,data-latency = <2 1 2>;
>> -arm,tag-latency = <3 2 3>;
>> -};
>> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
>> index 5f8eb1b..58bc6e4 100644
>> --- a/arch/arm/boot/dts/vf610.dtsi
>> +++ b/arch/arm/boot/dts/vf610.dtsi
>> @@ -19,7 +19,7 @@
>>  reg = <0x40006000 0x1000>;
>>  cache-unified;
>>  cache-level = <2>;
>> -arm,data-latency = <1 1 1>;
>> +arm,data-latency = <3 3 3>;
>>  arm,tag-latency = <2 2 2>;
>>  };
>>  };
>> --
>> 2.6.2
>> 
>> 
--
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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Brian Norris]

On Wed, Dec 02, 2015 at 08:34:38PM +, Simon Arlott wrote:
> On 02/12/15 20:21, Brian Norris wrote:
> > On Wed, Dec 02, 2015 at 08:12:32PM +, Simon Arlott wrote:
> >> On 02/12/15 20:00, Brian Norris wrote:
> >> > On Wed, Dec 02, 2015 at 07:41:07PM +, Simon Arlott wrote:
> >> >> I've created a bcm963268part driver so there won't need to be any
> >> >> partitions in DT for bcm63268.
> >> > 
> >> > Just curious, do you plan to submit this driver? We're working on
> >> 
> >> Yes, it's just the most recent one I've been working on. I still have
> >> USBH and IUDMA to submit
> >> 
> >> > matching up partition parsers to flash devices via device tree
> >> > of_match_table's, so you could do something like this:
> >> > 
> >> >  nand0: nandcs@0 {
> >> >  compatible = "brcm,nandcs";
> >> >  ...
> >> > 
> >> >  partitions {
> >> >  compatible = "brcm,bcm963268-partitions";
> >> >  ...
> >> >  };
> >> >  };
> >> 
> >> I modified brcmnand to look for a machine matching "brcm,bcm963268", but
> > 
> > Like this?
> > 
> > http://patchwork.ozlabs.org/patch/473180/
> > 
> > I'd like to avoid that (hence the "Rejected" status).
> 
> I exported default_mtd_part_types, copied it, and then added to it:
> + for (i = 0; i < nr_types; i++)
> + part_types[i] = default_mtd_part_types[i];
> +
> + /* Add partition type based on machine */
> + if (of_machine_is_compatible("brcm,bcm963268"))
> + part_types[i++] = "bcm963268part";
> + else
> + part_types[i++] = NULL;
> +
> + part_types[i++] = NULL;

OK, so even uglier :)

> >> that way is ok with me. Presumably "ofpart" defers to another matching
> >> partition parser?
> > 
> > Yes, "ofpart" is for specifying the entire partition table in the device
> > tree as subnodes of either the flash node or of the flash's "partitions"
> > subnode. It's not the most flexible, but it does work generically.
> > 
> >> Is there a patch for that method of parser detection available?
> > 
> > I have something working here, but I haven't had time to finish cleaning
> > it up and submitting it. There's an older patch that works similarly,
> > though it has some deficiencies:
> > 
> > http://patchwork.ozlabs.org/patch/475988/
> > 
> > The main difference between that and my (yet-to-be-submitted) proposal
> > is that I'd like parsers to opt in by adding a proper of_match_table
> > with non-Linux-specific DT bindings, and then we can drop the
> > "linux,..." naming and make it a reasonably generic property.
> 
> I'll submit my parser without any means of using it,

Sounds fine.

> let me know if you
> want me to work on a patch for a match table.

If you're interested, I may CC you on my patches for testing/review.

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 2/2] reset: bcm63xx: Add support for the BCM63xx soft-reset controller

[Simon Arlott]

On 02/12/15 18:03, Florian Fainelli wrote:
> 2015-11-30 12:58 GMT-08:00 Simon Arlott :
>> The BCM63xx contains a soft-reset controller activated by setting
>> a bit (that must previously have cleared).
>>
>> Signed-off-by: Simon Arlott 
>> ---
>>  MAINTAINERS   |   1 +
>>  drivers/reset/Kconfig |   9 +++
>>  drivers/reset/Makefile|   1 +
>>  drivers/reset/reset-bcm63xx.c | 134 
>> ++
>>  4 files changed, 145 insertions(+)
>>  create mode 100644 drivers/reset/reset-bcm63xx.c
> 
> 
> Could you create a bcm directory and then add your reset-bcm63xx.c
> file there? I have a pending submission for the BCM63138 reset
> controller which is not at all using the same structure and will share
> nothing with your driver.
> 

Ok, I'll call it reset-bcm6345.c to avoid confusion.

> 
>> +static int bcm63xx_reset_xlate(struct reset_controller_dev *rcdev,
>> +   const struct of_phandle_args *reset_spec)
>> +{
>> +   struct bcm63xx_reset_priv *priv = to_bcm63xx_reset_priv(rcdev);
>> +
>> +   if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
>> +   return -EINVAL;
>> +
>> +   if (reset_spec->args[0] >= rcdev->nr_resets)
>> +   return -EINVAL;
> 
> Should not these two things be moved to the core reset controller code
> based on the #reset-cells value?
> 

This has already been removed from the next version of the patch.

> 
>> +   if (of_property_read_u32(np, "offset", &priv->offset))
>> +   return -EINVAL;
>> +
>> +   /* valid reset bits */
>> +   if (of_property_read_u32(np, "mask", &priv->mask))
>> +   priv->mask = 0x;
>> +
>> +   priv->rcdev.owner = THIS_MODULE;
>> +   priv->rcdev.ops = &bcm63xx_reset_ops;
>> +   priv->rcdev.nr_resets = 32;
> 
> Should not that come from Device Tree, or be computed based on the
> mask property, like hweight_long() or something along these lines?

The "mask" property has been removed. It will assume 32 resets and rely
on the rest of the DT to only refer to valid bits.

-- 
Simon Arlott
--
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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Simon Arlott]

On 02/12/15 20:21, Brian Norris wrote:
> Hi Simon,
> 
> On Wed, Dec 02, 2015 at 08:12:32PM +, Simon Arlott wrote:
>> On 02/12/15 20:00, Brian Norris wrote:
>> > On Wed, Dec 02, 2015 at 07:41:07PM +, Simon Arlott wrote:
>> >> I've created a bcm963268part driver so there won't need to be any
>> >> partitions in DT for bcm63268.
>> > 
>> > Just curious, do you plan to submit this driver? We're working on
>> 
>> Yes, it's just the most recent one I've been working on. I still have
>> USBH and IUDMA to submit
>> 
>> > matching up partition parsers to flash devices via device tree
>> > of_match_table's, so you could do something like this:
>> > 
>> >nand0: nandcs@0 {
>> >compatible = "brcm,nandcs";
>> >...
>> > 
>> >partitions {
>> >compatible = "brcm,bcm963268-partitions";
>> >...
>> >};
>> >};
>> 
>> I modified brcmnand to look for a machine matching "brcm,bcm963268", but
> 
> Like this?
> 
> http://patchwork.ozlabs.org/patch/473180/
> 
> I'd like to avoid that (hence the "Rejected" status).

I exported default_mtd_part_types, copied it, and then added to it:
+   for (i = 0; i < nr_types; i++)
+   part_types[i] = default_mtd_part_types[i];
+
+   /* Add partition type based on machine */
+   if (of_machine_is_compatible("brcm,bcm963268"))
+   part_types[i++] = "bcm963268part";
+   else
+   part_types[i++] = NULL;
+
+   part_types[i++] = NULL;

>> that way is ok with me. Presumably "ofpart" defers to another matching
>> partition parser?
> 
> Yes, "ofpart" is for specifying the entire partition table in the device
> tree as subnodes of either the flash node or of the flash's "partitions"
> subnode. It's not the most flexible, but it does work generically.
> 
>> Is there a patch for that method of parser detection available?
> 
> I have something working here, but I haven't had time to finish cleaning
> it up and submitting it. There's an older patch that works similarly,
> though it has some deficiencies:
> 
> http://patchwork.ozlabs.org/patch/475988/
> 
> The main difference between that and my (yet-to-be-submitted) proposal
> is that I'd like parsers to opt in by adding a proper of_match_table
> with non-Linux-specific DT bindings, and then we can drop the
> "linux,..." naming and make it a reasonably generic property.

I'll submit my parser without any means of using it, let me know if you
want me to work on a patch for a match table.

> Regards,
> Brian
> 


-- 
Simon Arlott
--
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 v3 0/3] soc: ti: Introduce wkup_m3_ipc driver

[Dave Gerlach]

Hi,
On 10/20/2015 11:18 AM, Tony Lindgren wrote:

Hi all,

* Dave Gerlach  [150922 17:20]:

Hi,
This series is version 3 of the code to introduce a wkup_m3_ipc driver
to handle communication between the MPU and Cortex M3 present on TI AM335x
and AM437x SoCs. v2 of this series can be found at [1]. Only patch 3
has been changed based on a request from Tony and a few cleanups:

- Rather than exporting all of the functionality of the driver, added
   wkup_m3_ipc_get and wkup_m3_ipc_put to allow users to just get a handle
   containing an ops structure for use.

- Changed all ops (previously exported functions) to take pointer to
   struct wkup_m3_ipc as an argument now that user code will get this
   from wkup_m3_ipc_get.

- General cleanup to probe function

- Added MODULE_DEVICE_TABLE so driver can probe automatically.

The series containing the DT nodes can be found here [2]. The actual dt
nodes for wkup_m3_ipc (last two patches) have been merged but discussion
is still open for the ti,mbox-send-noirq flag patches and depends on the
comments provided for the omap-mailbox change presented in patch 1 of
this series.

A full branch containing all necessary PM code for both am335x and am437x
has been pushed here [3] to provide a big picture view of the plan for
this series.

This driver relies on the firmware at [4] in the next-upstream branch
being present in /lib/firmware in the rootfs or built in to the kernel.


Anybody got comments on this one? Should I pick up this series or
what's the plan?


Now that Patch 1 has been merged [1] can patch 2 and 3 be picked up? 
These apply cleanly on v4.4-rc3.


Regards,
Dave

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8e3c5952144f045a0c81bf674d3f5e1d9aafceb7




Regards,

Tony



[1] https://lkml.org/lkml/2015/7/17/797
[2] https://lkml.org/lkml/2015/7/17/813
[3] https://github.com/dgerlach/linux-pm/tree/pm-v4.3-rc1-amx3-suspend
[4] https://git.ti.com/ti-cm3-pm-firmware

Dave Gerlach (3):
   mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
   Documentation: dt: add bindings for TI Wakeup M3 IPC device
   soc: ti: Add wkup_m3_ipc driver

  .../devicetree/bindings/mailbox/omap-mailbox.txt   |   8 +
  .../devicetree/bindings/soc/ti/wkup_m3_ipc.txt |  57 +++
  drivers/mailbox/omap-mailbox.c |  49 +-
  drivers/soc/ti/Kconfig |  10 +
  drivers/soc/ti/Makefile|   1 +
  drivers/soc/ti/wkup_m3_ipc.c   | 508 +
  include/linux/wkup_m3_ipc.h|  55 +++
  7 files changed, 684 insertions(+), 4 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
  create mode 100644 drivers/soc/ti/wkup_m3_ipc.c
  create mode 100644 include/linux/wkup_m3_ipc.h

--
2.4.6



--
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/2] regulator: Add brcm,bcm63xx-regulator device tree binding

[Simon Arlott]

On 02/12/15 12:53, Mark Brown wrote:
> On Wed, Dec 02, 2015 at 12:45:50PM -, Simon Arlott wrote:
>> On Tue, December 1, 2015 22:16, Mark Brown wrote:
> 
>> > Why are these in the DT, I would expect that if this is a driver for a
>> > specific SoC all these properties would be known as a result of that.
> 
>> This is a driver for multiple SoCs with the same regulator control in
>> different places on different SoCs, so the location of it within the misc
>> register needs to be provided in the DT:
> 
>> BCM6362:
>>   #define MISC_BASE 0xb0001800 /* Miscellaneous Registers */
>>   uint32 miscIddqCtrl; /* 0x48 */
> 
> This is the sort of thing you can pick up from the SoC compatible
> strings.  As things stand there is zero content in this driver that
> relates to this SoC.

There's always going to be very little content in the driver that
relates to this SoC, given that a single bit flip enables/disables
power.

All other device tree drivers allow a register address to be specified
for the device, how is an offset in the regmap any different?

>> The mask is used as there's one bit per regulator in the register, but
>> there's more than one way to express this in the DT:
> 
> I wouldn't expect to see it in the device tree at all for a device
> specific driver.

If there isn't an individual entry in DT for each regulator, how is it
supposed to work? There's no #regulator-cells property.

-- 
Simon Arlott
--
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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Brian Norris]

On Wed, Dec 02, 2015 at 12:21:27PM -0800, Brian Norris wrote:
> On Wed, Dec 02, 2015 at 08:12:32PM +, Simon Arlott wrote:
> > Is there a patch for that method of parser detection available?
> 
> I have something working here, but I haven't had time to finish cleaning
> it up and submitting it. There's an older patch that works similarly,
> though it has some deficiencies:
> 
> http://patchwork.ozlabs.org/patch/475988/
> 
> The main difference between that and my (yet-to-be-submitted) proposal
> is that I'd like parsers to opt in by adding a proper of_match_table
> with non-Linux-specific DT bindings, and then we can drop the
> "linux,..." naming and make it a reasonably generic property.

For other related work: Linus Walleij attempted something similar here:

http://lists.infradead.org/pipermail/linux-mtd/2015-October/062899.html
--
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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Brian Norris]

Hi Simon,

On Wed, Dec 02, 2015 at 08:12:32PM +, Simon Arlott wrote:
> On 02/12/15 20:00, Brian Norris wrote:
> > On Wed, Dec 02, 2015 at 07:41:07PM +, Simon Arlott wrote:
> >> I've created a bcm963268part driver so there won't need to be any
> >> partitions in DT for bcm63268.
> > 
> > Just curious, do you plan to submit this driver? We're working on
> 
> Yes, it's just the most recent one I've been working on. I still have
> USBH and IUDMA to submit
> 
> > matching up partition parsers to flash devices via device tree
> > of_match_table's, so you could do something like this:
> > 
> > nand0: nandcs@0 {
> > compatible = "brcm,nandcs";
> > ...
> > 
> > partitions {
> > compatible = "brcm,bcm963268-partitions";
> > ...
> > };
> > };
> 
> I modified brcmnand to look for a machine matching "brcm,bcm963268", but

Like this?

http://patchwork.ozlabs.org/patch/473180/

I'd like to avoid that (hence the "Rejected" status).

> that way is ok with me. Presumably "ofpart" defers to another matching
> partition parser?

Yes, "ofpart" is for specifying the entire partition table in the device
tree as subnodes of either the flash node or of the flash's "partitions"
subnode. It's not the most flexible, but it does work generically.

> Is there a patch for that method of parser detection available?

I have something working here, but I haven't had time to finish cleaning
it up and submitting it. There's an older patch that works similarly,
though it has some deficiencies:

http://patchwork.ozlabs.org/patch/475988/

The main difference between that and my (yet-to-be-submitted) proposal
is that I'd like parsers to opt in by adding a proper of_match_table
with non-Linux-specific DT bindings, and then we can drop the
"linux,..." naming and make it a reasonably generic property.

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] dts/ls2080a: Update PCIe compatible

[Li Yang]

On Tue, Nov 24, 2015 at 11:01 PM, Hu Vincent  wrote:
>
>
>> -Original Message-
>> From: Rob Herring [mailto:r...@kernel.org]
>> Sent: Wednesday, November 25, 2015 4:22 AM
>> To: Hu Mingkai-B21284
>> Cc: a...@kernel.org; linux-arm-ker...@lists.infradead.org;
>> devicetree@vger.kernel.org; Li Yang-Leo-R58472; Lian Minghuan-B31939
>> Subject: Re: [PATCH] dts/ls2080a: Update PCIe compatible
>>
>> On Tue, Nov 24, 2015 at 02:04:35PM +0800, Mingkai Hu wrote:
>> > From: Minghuan Lian 
>> >
>> > The patch adds LS2085a to PCIe compatible to fix the compatibility
>> > issue when using firmware with LS2085a compatible property.
>> >
>> > Signed-off-by: Minghuan Lian 
>> > Signed-off-by: Mingkai Hu 
>> > ---
>> >  Documentation/devicetree/bindings/pci/layerscape-pci.txt |  1 +
>> >  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi   | 12
>> 
>> >  2 files changed, 9 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>> > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>> > index e376785..467 100644
>> > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>> > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>> > @@ -15,6 +15,7 @@ Required properties:
>> >  - compatible: should contain the platform identifier such as:
>> >  "fsl,ls1021a-pcie", "snps,dw-pcie"
>> >  "fsl,ls2080a-pcie", "snps,dw-pcie"
>> > +"fsl,ls2085a-pcie", "snps,dw-pcie"
>> >  - reg: base addresses and lengths of the PCIe controller
>> >  - interrupts: A list of interrupt outputs of the controller. Must
>> contain an
>> >entry for each entry in the interrupt-names property.
>> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
>> > b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
>> > index e81cd48..3821bb1 100644
>> > --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
>> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
>> > @@ -383,7 +383,8 @@
>> > };
>> >
>> > pcie@340 {
>> > -   compatible = "fsl,ls2080a-pcie", "snps,dw-pcie";
>> > +   compatible = "fsl,ls2080a-pcie", "fsl,ls2085a-pcie",
>> > +"snps,dw-pcie";
>>
>> This doesn't match the doc as to what are valid combinations. The order
>> here seems backwards too. ls2085a is older?
>>
>
> Yes, ls2085a was released earlier. You mean the older one comes first? Like:
>
> compatible = "fsl,ls2085a-pcie", "fsl,ls2080a-pcie",
>  "snps,dw-pcie";

No.  The original order should be good.  We should put newer/more
specific compatible first and older/more generic compatible later.  I
think the issue is that the binding document.  We don't need to list
the combinations.  Just list all the possible compatible strings
specific to layerscape.  You can add a special note about "snps,
dw-pcie" separately.

Regards,
Leo
--
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 (v7) 2/2] mtd: brcmnand: Add support for the BCM63268

[Brian Norris]

Hi,

On Wed, Dec 02, 2015 at 07:54:49PM +, Simon Arlott wrote:
> On 02/12/15 19:18, Brian Norris wrote:
> > On Wed, Nov 25, 2015 at 07:49:13PM +, Simon Arlott wrote:
> >> +static int bcm63268_nand_probe(struct platform_device *pdev)
> >> +{
> >> +  struct device *dev = &pdev->dev;
> >> +  struct bcm63268_nand_soc *priv;
> >> +  struct brcmnand_soc *soc;
> >> +  struct resource *res;
> >> +  int ret;
> >> +
> >> +  priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> >> +  if (!priv)
> >> +  return -ENOMEM;
> >> +  soc = &priv->soc;
> >> +
> >> +  res = platform_get_resource_byname(pdev,
> >> +  IORESOURCE_MEM, "nand-intr-base");
> >> +  if (!res)
> >> +  return -EINVAL;
> >> +
> >> +  priv->base = devm_ioremap_resource(dev, res);
> >> +  if (IS_ERR(priv->base))
> >> +  return PTR_ERR(priv->base);
> >> +
> >> +  priv->clk = devm_clk_get(&pdev->dev, "nand");
> >> +  if (IS_ERR(priv->clk))
> >> +  return PTR_ERR(priv->clk);
> > 
> > Perhaps we should put this clock handling in brcmnand.c? Just have it
> > treat the clock as optional (i.e., ignore errors except for
> > EPROBE_DEFER?), so we don't fail if no clock was provided? This could
> > help other platforms too, if they gain clock support.
> 
> Unless most soc variants have clocks I'd prefer to leave it in this
> module.

I'm quite confident your SoC is not the only one with clocks.

> > If we do this, you'll want to document the clock in the common binding,
> > not the bcm63268-specific part.
> > 
> > Also, could it help to disable/enable the clock during suspend/resume?
> > If you move it to brcmnand.c, this would also be pretty simple.
> 
> Alternatively, it could proxy the brcmnand_pm_ops functions. I don't
> have any way to test suspend/resume.

OK, no need to add it now then. It can be added if/when it's needed.

> >> +
> >> +  ret = clk_prepare_enable(priv->clk);
> >> +  if (ret)
> >> +  return ret;
> >> +
> >> +  soc->ctlrdy_ack = bcm63268_nand_intc_ack;
> >> +  soc->ctlrdy_set_enabled = bcm63268_nand_intc_set;
> >> +
> >> +  /* Disable and ack all interrupts  */
> >> +  brcmnand_writel(0, priv->base + BCM63268_NAND_INT);
> >> +  brcmnand_writel(BCM63268_NAND_STATUS_MASK,
> >> +  priv->base + BCM63268_NAND_INT);
> >> +
> >> +  ret = brcmnand_probe(pdev, soc);
> >> +  if (ret)
> >> +  clk_disable_unprepare(priv->clk);
> >> +
> >> +  return ret;
> >> +}

> >> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
> >> b/drivers/mtd/nand/brcmnand/brcmnand.c
> >> index 2c8f67f..5f26b8a 100644
> >> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> >> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> >> @@ -2262,6 +2262,14 @@ int brcmnand_probe(struct platform_device *pdev, 
> >> struct brcmnand_soc *soc)
> >>  }
> >>  EXPORT_SYMBOL_GPL(brcmnand_probe);
> >>  
> >> +struct brcmnand_soc *brcmnand_get_socdata(struct platform_device *pdev)
> >> +{
> >> +  struct brcmnand_controller *ctrl = dev_get_drvdata(&pdev->dev);
> >> +
> >> +  return ctrl ? ctrl->soc : NULL;
> >> +}
> >> +EXPORT_SYMBOL_GPL(brcmnand_get_socdata);
> > 
> > If you move the clk handling to the core brcmnand.c, then you won't need
> > this still.
> 
> Would you prefer a clock name in the soc data structure that is used to
> call devm_clk_get()?

Not really. If we specify a clock name now, we can suggest other SoC's
to use the same name (where possible). So we wouldn't need any new code
or documentation, and we definitely don't need each snowflake sub-driver
to pass a new name.

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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Simon Arlott]

On 02/12/15 20:00, Brian Norris wrote:
> Hi,
> 
> On Wed, Dec 02, 2015 at 07:41:07PM +, Simon Arlott wrote:
>> >> + nand0: nandcs@0 {
>> >> + compatible = "brcm,nandcs";
>> >> +
>> >> + #address-cells = <0>;
>> >> + #size-cells = <0>;
> 
>> I think they're also implicit so you can just remove those two lines.
> 
> From ePAPR: "The #address-cells and #size-cells properties are not
> inherited from ancestors in the device tree. They shall be explicitly
> defined."
> 
> But we don't want to define them. I'd drop them, at least from the
> example, as they're not relevant.

Ok.

>> I've created a bcm963268part driver so there won't need to be any
>> partitions in DT for bcm63268.
> 
> Just curious, do you plan to submit this driver? We're working on

Yes, it's just the most recent one I've been working on. I still have
USBH and IUDMA to submit

> matching up partition parsers to flash devices via device tree
> of_match_table's, so you could do something like this:
> 
>   nand0: nandcs@0 {
>   compatible = "brcm,nandcs";
>   ...
> 
>   partitions {
>   compatible = "brcm,bcm963268-partitions";
>   ...
>   };
>   };

I modified brcmnand to look for a machine matching "brcm,bcm963268", but
that way is ok with me. Presumably "ofpart" defers to another matching
partition parser?

Is there a patch for that method of parser detection available?

-- 
Simon Arlott
--
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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* Brian Norris  [151202 10:14]:
> On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote:
> > * Roger Quadros  [151201 21:13]:
> > > On 02/12/15 08:56, Brian Norris wrote:
> > > > 
> > > > I'll take another pass over your patch set, but if things are looking
> > > > better, how do you expect to merge this? There are significant portions
> > > > that touch at least 2 or 3 different subsystem trees, AFAICT.
> > > 
> > > Tony could create an immutable branch with all the dts and memory changes.
> > > You could base the mtd changes on top of that?
> > 
> > If we all agree on that it will be immutable Roger can set up the branch
> > with our acks and we can all merge it in as needed. I believe v4.4-rc1
> > should work as a base for us all?
> 
> There are oustanding comments about the NAND ready/busy GPIO naming in
> patch 18, which I'd like addressed. I'll re-review the rest before the
> end of the day (West Coast U.S.A.). I'm not sure my acks are worth much
> beyond the MTD stuff.

OK, I'm happy with the gpmc related parts.

> Regarding branches, 4.4-rc1 is fine with me.

OK

Thanks,

Tony
--
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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Simon Arlott]

On 02/12/15 19:38, Florian Fainelli wrote:
> 2015-12-02 11:05 GMT-08:00 Brian Norris :
>> + Broadcom list + Kamal
>>
>> On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote:
>>> Add device tree binding for NAND on the BCM63268.
>>>
>>> The BCM63268 has a NAND interrupt register with combined status and enable
>>> registers.
>>>
>>> Signed-off-by: Simon Arlott 
>>> ---
>>>  .../devicetree/bindings/mtd/brcm,brcmnand.txt  | 35 
>>> ++
>>>  1 file changed, 35 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>>> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>>> index 4ff7128..f2a71c8 100644
>>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>>> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and 
>>> associated register resources w
>>> and enable registers
>>>   - reg-names: (required) "nand-int-base"
>>>
>>> +   * "brcm,nand-bcm63268"
>>> + - compatible: should contain "brcm,nand-bcm", 
>>> "brcm,nand-bcm63268"
>>
>> Looks like you're aiming to support bcm63168? Is bcm63268 the first
>> chip to include this style of register then? The numbering seems
>> backwards, but that may just be reality.
> 
> 6362 (NAND rev 2.1, ann. Sep 8, 2009), 6368 (v0.1?!?, ann. Jan 7,
> 2009) and 6328 (v2.1, can't find release date) are earlier chips that
> have an identical combined interrupt enable + status register and a
> NAND controller within the same 32-bits word, so these would qualify
> as a better compatible string for this specific addition integration
> stub here. I would gowith 6368 here then?
> 

I could change it to 6368 but there's no documented NAND_INTR_BASE for
it. Only the 63268 and 6818 have a #define for NAND_INTR_BASE.

-- 
Simon Arlott
--
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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Brian Norris]

Hi,

On Wed, Dec 02, 2015 at 07:41:07PM +, Simon Arlott wrote:
> >> +  nand0: nandcs@0 {
> >> +  compatible = "brcm,nandcs";
> >> +  reg = <0>;
> >> +  nand-on-flash-bbt;
> >> +  nand-ecc-strength = <1>;
> >> +  nand-ecc-step-size = <512>;
> >> +
> >> +  #address-cells = <0>;
> >> +  #size-cells = <0>;
> > 
> > What are these {address,size}-cells for? If you need them for
> > partitioning, then those are wrong -- they shouldn't be zero. Maybe just
> > drop them? (I can cut them out when applying, if that's the only change
> > to make.)
> 
> This is the correct way to do partitioning, there would be a
> "partitions" block with no address/size that contains the partitions as
> child nodes. [Documentation/devicetree/bindings/mtd/partition.txt]

That doc says nothing about {address,size}-cells = 0. When using the new
binding with a 'partitions' subnode, I'm not sure the address
translation specification really matters anyway; the flash space is a
new address space unrelated to the parents, and we don't do any
translation from the 'flash' node to the 'partitions' node. So you don't
need #{address,size}-cells in the flash node, but you do in the
'partitions' node.

> I think they're also implicit so you can just remove those two lines.

>From ePAPR: "The #address-cells and #size-cells properties are not
inherited from ancestors in the device tree. They shall be explicitly
defined."

But we don't want to define them. I'd drop them, at least from the
example, as they're not relevant.

> I've created a bcm963268part driver so there won't need to be any
> partitions in DT for bcm63268.

Just curious, do you plan to submit this driver? We're working on
matching up partition parsers to flash devices via device tree
of_match_table's, so you could do something like this:

nand0: nandcs@0 {
compatible = "brcm,nandcs";
...

partitions {
compatible = "brcm,bcm963268-partitions";
...
};
};

FYI.

> >> +  };
> >> +};

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 (v7) 2/2] mtd: brcmnand: Add support for the BCM63268

[Simon Arlott]

On 02/12/15 19:18, Brian Norris wrote:
> + Broadcom list + Kamal
> 
> Hi Simon,
> 
> On Wed, Nov 25, 2015 at 07:49:13PM +, Simon Arlott wrote:
>> The BCM63268 has a NAND interrupt register with combined status and enable
>> registers. It also has a clock for the NAND controller that needs to be
>> enabled.
>> 
>> Set up the device by enabling the clock, disabling and acking all
>> interrupts, then handle the CTRL_READY interrupt.
>> 
>> Add a brcmnand_get_socdata() function so that bcm63268_nand can obtain its
>> data and disable the clock when the device is removed.
>> 
>> Signed-off-by: Simon Arlott 
>> ---
>> Added EXPORT_SYMBOL_GPL(brcmnand_get_socdata)
>> 
>> (As the brcmnand module must be loaded first its compatible string will
>> apply to any existing devices before the soc-specific module can be
>> loaded.)
> 
> What's this comment supposed to mean? The brcmnand module will not
> directly probe any devices. It doesn't register any driver structs by
> itself.

I didn't notice that it didn't actually probe devices. In that case the
documentation should not require "brcm,brcmnand" for soc-specific
variants because the hardware's not really compatible with it.

> (BTW given that, it probably doesn't need its MODULE_DEVICE_TABLE.)
> 
>>  drivers/mtd/nand/brcmnand/Makefile|   1 +
>>  drivers/mtd/nand/brcmnand/bcm63268_nand.c | 179 
>> ++
>>  drivers/mtd/nand/brcmnand/brcmnand.c  |   8 ++
>>  drivers/mtd/nand/brcmnand/brcmnand.h  |   1 +
>>  4 files changed, 189 insertions(+)
>>  create mode 100644 drivers/mtd/nand/brcmnand/bcm63268_nand.c
>> 
>> diff --git a/drivers/mtd/nand/brcmnand/Makefile 
>> b/drivers/mtd/nand/brcmnand/Makefile
>> index 3b1fbfd..b83a9ae 100644
>> --- a/drivers/mtd/nand/brcmnand/Makefile
>> +++ b/drivers/mtd/nand/brcmnand/Makefile
>> @@ -2,5 +2,6 @@
>>  # more specific iproc_nand.o, for instance
>>  obj-$(CONFIG_MTD_NAND_BRCMNAND) += iproc_nand.o
>>  obj-$(CONFIG_MTD_NAND_BRCMNAND) += bcm63138_nand.o
>> +obj-$(CONFIG_MTD_NAND_BRCMNAND) += bcm63268_nand.o
>>  obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmstb_nand.o
>>  obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand.o
>> diff --git a/drivers/mtd/nand/brcmnand/bcm63268_nand.c 
>> b/drivers/mtd/nand/brcmnand/bcm63268_nand.c
>> new file mode 100644
>> index 000..70ad907
>> --- /dev/null
>> +++ b/drivers/mtd/nand/brcmnand/bcm63268_nand.c
>> @@ -0,0 +1,179 @@
>> +/*
>> + * Copyright 2015 Simon Arlott
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * 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.
>> + *
>> + * Derived from bcm63138_nand.c:
>> + * Copyright © 2015 Broadcom Corporation
>> + *
>> + * Derived from 
>> bcm963xx_4.12L.06B_consumer/shared/opensource/include/bcm963xx/63268_map_part.h:
>> + * Copyright 2000-2010 Broadcom Corporation
>> + *
>> + * Derived from 
>> bcm963xx_4.12L.06B_consumer/shared/opensource/flash/nandflash.c:
>> + * Copyright 2000-2010 Broadcom Corporation
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "brcmnand.h"
>> +
>> +struct bcm63268_nand_soc {
>> +struct brcmnand_soc soc;
>> +void __iomem *base;
>> +struct clk *clk;
>> +};
>> +
>> +#define BCM63268_NAND_INT   0x00
>> +#define  BCM63268_NAND_STATUS_SHIFT 0
>> +#define  BCM63268_NAND_STATUS_MASK  (0xfff << BCM63268_NAND_STATUS_SHIFT)
>> +#define  BCM63268_NAND_ENABLE_SHIFT 16
>> +#define  BCM63268_NAND_ENABLE_MASK  (0x << BCM63268_NAND_ENABLE_SHIFT)
>> +#define BCM63268_NAND_BASE_ADDR00x04
>> +#define BCM63268_NAND_BASE_ADDR10x0c
>> +
>> +enum {
>> +BCM63268_NP_READ= BIT(0),
>> +BCM63268_BLOCK_ERASE= BIT(1),
>> +BCM63268_COPY_BACK  = BIT(2),
>> +BCM63268_PAGE_PGM   = BIT(3),
>> +BCM63268_CTRL_READY = BIT(4),
>> +BCM63268_DEV_RBPIN  = BIT(5),
>> +BCM63268_ECC_ERR_UNC= BIT(6),
>> +BCM63268_ECC_ERR_CORR   = BIT(7),
>> +};
>> +
>> +static bool bcm63268_nand_intc_ack(struct brcmnand_soc *soc)
>> +{
>> +struct bcm63268_nand_soc *priv =
>> +container_of(soc, struct bcm63268_nand_soc, soc);
>> +void __iomem *mmio = priv->base + BCM63268_NAND_INT;
>> +u32 val = brcmnand_readl(mmio);
>> +
>> +if (val & (BCM63268_CTRL_READY << BCM63268_NAND_STATUS_SHIFT)) {
>> +/* Ack interrupt */
>> +val &= ~BCM63268_NAND_STATUS_MASK;
>> +val |= BCM63268_CTRL_READY << BCM63268_NAND_STATUS_SHIFT;
>> +brcmnand_writel(val, mmio);
>> + 

Re: [PATCH V6 net-next 5/5] net:hns: Add the init code to disable Hip06 "Hardware VLAN assist"

[Sergei Shtylyov]

Hello.

On 12/02/2015 07:52 PM, Salil Mehta wrote:


This patch adds the initializzation code to disable the hardware
vlan support for VLAN Tag stripping by default for now.

Proper support of "hardware VLAN assitance" feature would
soon come in the next coming patches.

Signed-off-by: Salil Mehta 
---

PATCH V6:
- No change over the earlier patch

PATCH V5:
- Minor merge/reject change resolved to application of previous patch

PATCH V4/V3/V2:
- No change over the initial floated patch

PATCH V1:
- Initial code to disable the hardware VLAN assist for now
---
  drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c |7 +++
  drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h |1 +
  2 files changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index b5e4c44..f302ef9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -176,6 +176,11 @@ static void hns_ppe_cnt_clr_ce(struct hns_ppe_cb *ppe_cb)
 PPE_CNT_CLR_CE_B, 1);
  }

+static void hns_ppe_set_vlan_strip(struct hns_ppe_cb *ppe_cb, int en)
+{
+   dsaf_write_dev(ppe_cb, PPEV2_VLAN_STRIP_EN_REG, en);


   Why not call it directly?


+}
+
  /**
   * hns_ppe_checksum_hw - set ppe checksum caculate
   * @ppe_device: ppe device
@@ -336,6 +341,8 @@ static void hns_ppe_init_hw(struct hns_ppe_cb *ppe_cb)
hns_ppe_cnt_clr_ce(ppe_cb);

if (!AE_IS_VER1(dsaf_dev->dsaf_ver)) {
+   hns_ppe_set_vlan_strip(ppe_cb, 0);
+
/* set default RSS key in h/w */
hns_ppe_set_rss_key(ppe_cb, ppe_cb->rss_key);

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 98c163e..6c18ca9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -318,6 +318,7 @@
  #define PPE_CFG_PARSE_TAG_REG 0x94
  #define PPE_CFG_PRO_CHECK_EN_REG  0x98
  #define PPEV2_CFG_TSO_EN_REG0xA0
+#define PPEV2_VLAN_STRIP_EN_REG 0xAC


   Please indent with tabs, like all the surrounding #define's are indented 
(except PPEV2_CFG_TSO_EN_REG).



  #define PPE_INTEN_REG 0x100
  #define PPE_RINT_REG  0x104
  #define PPE_INTSTS_REG0x108


MBR, Sergei

--
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 v3 4/8] platform: goldfish: pipe: add devicetree bindings

[Jin Qian]

From: Greg Hackmann 

Add bindings so we don't need to rely on goldfish virtual bus for
probing any more, which means we don't need ARM and MIPS goldfish
board code for instantiating the bus.

In the long term we would like to move towards replacing the Android
pipe with virtio-vsock that is currently under development.

Signed-off-by: Greg Hackmann 
Signed-off-by: Jin Qian 
---
 Documentation/devicetree/bindings/goldfish/pipe.txt | 17 +
 drivers/platform/goldfish/goldfish_pipe.c   | 10 +-
 2 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/goldfish/pipe.txt

diff --git a/Documentation/devicetree/bindings/goldfish/pipe.txt 
b/Documentation/devicetree/bindings/goldfish/pipe.txt
new file mode 100644
index 000..e417a31
--- /dev/null
+++ b/Documentation/devicetree/bindings/goldfish/pipe.txt
@@ -0,0 +1,17 @@
+Android Goldfish QEMU Pipe
+
+Andorid pipe virtual device generated by android emulator.
+
+Required properties:
+
+- compatible : should contain "google,android-pipe" to match emulator
+- reg: 
+- interrupts : 
+
+Example:
+
+   android_pipe@a01 {
+   compatible = "google,android-pipe";
+   reg = ;
+   interrupts = <0x12>;
+   };
diff --git a/drivers/platform/goldfish/goldfish_pipe.c 
b/drivers/platform/goldfish/goldfish_pipe.c
index 20a9337..0b187ff 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -624,11 +624,19 @@ static int goldfish_pipe_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static const struct of_device_id goldfish_pipe_of_match[] = {
+   { .compatible = "google,android-pipe", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, goldfish_pipe_of_match);
+
 static struct platform_driver goldfish_pipe = {
.probe = goldfish_pipe_probe,
.remove = goldfish_pipe_remove,
.driver = {
-   .name = "goldfish_pipe"
+   .name = "goldfish_pipe",
+   .owner = THIS_MODULE,
+   .of_match_table = goldfish_pipe_of_match,
}
 };
 
-- 
2.6.0.rc2.230.g3dd15c0

--
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 v4 1/5] spi: introduce accelerated read support for spi flash devices

[Mark Brown]

On Mon, Nov 30, 2015 at 10:45:11AM +0530, Vignesh R wrote:
> In addition to providing direct access to SPI bus, some spi controller
> hardwares (like ti-qspi) provide special port (like memory mapped port)
> that are optimized to improve SPI flash read performance.

I'm reasonably OK with this from the SPI side but I'd really like to see
people working on MTD say that this makes sense.


signature.asc
Description: PGP signature

Re: [PATCH (v6) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Simon Arlott]

On 02/12/15 19:05, Brian Norris wrote:
> + Broadcom list + Kamal
> 
> On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote:
>> Add device tree binding for NAND on the BCM63268.
>> 
>> The BCM63268 has a NAND interrupt register with combined status and enable
>> registers.
>> 
>> Signed-off-by: Simon Arlott 
>> ---
>>  .../devicetree/bindings/mtd/brcm,brcmnand.txt  | 35 
>> ++
>>  1 file changed, 35 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> index 4ff7128..f2a71c8 100644
>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and 
>> associated register resources w
>> and enable registers
>>   - reg-names: (required) "nand-int-base"
>> 
>> +   * "brcm,nand-bcm63268"
>> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm63268"
> 
> Looks like you're aiming to support bcm63168? Is bcm63268 the first
> chip to include this style of register then? The numbering seems
> backwards, but that may just be reality.

Yes, I have a BCM963168VX (BCM63168) but all the Broadcom code refers to
this SoC as BCM63268. This is the only one with these registers in the
source code of similar MIPS that I have.


https://github.com/lp0/bcm963xx_4.12L.06B_consumer/blob/master/bcmdrivers/opensource/char/board/bcm963xx/impl1/board.c#L6595

int kerSysGetChipId() {
...
/* Force BCM63168, BCM63169, and BCM63269 to be BCM63268) */
if( ( (r & 0xe) == 0x63168 )
  || ( (r & 0xe) == 0x63268 ))
r = 0x63268;

>> + - reg: (required) the 'NAND_INTR_BASE' register range, with combined 
>> status
>> +   and enable registers, and boot address registers
>> + - reg-names: (required) "nand-intr-base"
>> + - clock: (required) reference to the clock for the NAND controller
>> + - clock-names: (required) "nand"
>> +
>> * "brcm,nand-iproc"
>>   - reg: (required) the "IDM" register range, for interrupt enable and 
>> APB
>> bus access endianness configuration, and the "EXT" register range,
>> @@ -148,3 +156,30 @@ nand@f0442800 {
>>  };
>>  };
>>  };
>> +
>> +nand@1200 {
>> +compatible = "brcm,nand-bcm63168", "brcm,nand-bcm63268",
>> +"brcm,brcmnand-v4.0", "brcm,brcmnand";
>> +reg = <0x1200 0x180>,
>> +  <0x1600 0x200>,
>> +  <0x10b0 0x10>;
>> +reg-names = "nand", "nand-cache", "nand-intr-base";
>> +interrupt-parent = <&periph_intc>;
>> +interrupts = <50>;
>> +clocks = <&periph_clk 20>;
>> +clock-names = "nand";
>> +
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +nand0: nandcs@0 {
>> +compatible = "brcm,nandcs";
>> +reg = <0>;
>> +nand-on-flash-bbt;
>> +nand-ecc-strength = <1>;
>> +nand-ecc-step-size = <512>;
>> +
>> +#address-cells = <0>;
>> +#size-cells = <0>;
> 
> What are these {address,size}-cells for? If you need them for
> partitioning, then those are wrong -- they shouldn't be zero. Maybe just
> drop them? (I can cut them out when applying, if that's the only change
> to make.)

This is the correct way to do partitioning, there would be a
"partitions" block with no address/size that contains the partitions as
child nodes. [Documentation/devicetree/bindings/mtd/partition.txt]

I think they're also implicit so you can just remove those two lines.

I've created a bcm963268part driver so there won't need to be any
partitions in DT for bcm63268.

>> +};
>> +};
> 
> Brian
> 


-- 
Simon Arlott
--
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 v2 3/7] clk: Amlogic: Add reset controller for CPU cores for Meson8b

[Arnd Bergmann]

On Wednesday 02 December 2015 18:22:29 Carlo Caione wrote:
>  
> +#define RST_CORE0  0
> +#define RST_CORE1  1
> +#define RST_CORE2  2
> +#define RST_CORE3  3

These defines are rather silly and just cause interdependencies with the header
file. Just drop them and use the numbers directly.

Arnd
--
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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Florian Fainelli]

2015-12-02 11:05 GMT-08:00 Brian Norris :
> + Broadcom list + Kamal
>
> On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote:
>> Add device tree binding for NAND on the BCM63268.
>>
>> The BCM63268 has a NAND interrupt register with combined status and enable
>> registers.
>>
>> Signed-off-by: Simon Arlott 
>> ---
>>  .../devicetree/bindings/mtd/brcm,brcmnand.txt  | 35 
>> ++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> index 4ff7128..f2a71c8 100644
>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and 
>> associated register resources w
>> and enable registers
>>   - reg-names: (required) "nand-int-base"
>>
>> +   * "brcm,nand-bcm63268"
>> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm63268"
>
> Looks like you're aiming to support bcm63168? Is bcm63268 the first
> chip to include this style of register then? The numbering seems
> backwards, but that may just be reality.

6362 (NAND rev 2.1, ann. Sep 8, 2009), 6368 (v0.1?!?, ann. Jan 7,
2009) and 6328 (v2.1, can't find release date) are earlier chips that
have an identical combined interrupt enable + status register and a
NAND controller within the same 32-bits word, so these would qualify
as a better compatible string for this specific addition integration
stub here. I would gowith 6368 here then?
-- 
Florian
--
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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Jonas Gorski]

On Wed, Dec 2, 2015 at 8:05 PM, Brian Norris
 wrote:
> + Broadcom list + Kamal
>
> On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote:
>> Add device tree binding for NAND on the BCM63268.
>>
>> The BCM63268 has a NAND interrupt register with combined status and enable
>> registers.
>>
>> Signed-off-by: Simon Arlott 
>> ---
>>  .../devicetree/bindings/mtd/brcm,brcmnand.txt  | 35 
>> ++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> index 4ff7128..f2a71c8 100644
>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and 
>> associated register resources w
>> and enable registers
>>   - reg-names: (required) "nand-int-base"
>>
>> +   * "brcm,nand-bcm63268"
>> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm63268"
>
> Looks like you're aiming to support bcm63168? Is bcm63268 the first
> chip to include this style of register then? The numbering seems
> backwards, but that may just be reality.

There are four chip variants, bcm63168, bcm63268, bcm63169 and
bcm63269, and they were all introduced at the same time. the *16x have
less features than *26x (IIRC only two rgmii ports instead of four, no
hw crypto, maybe no dect?), and the *9 ones have no xDSL support.

>From a registers location/layout, clocks, etc standpoint, there is no
difference between bcm63168 and bcm63268 (and the x9's).

As a reference, Broadcom uses bcm63268 as the "generic" name for the
chip family in their code, but on their website only advertise the
bcm63168. Both chips do exist though, and at least the bcm63169, I
have devices with these three here.


Jonas
--
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 v4 3/7] ARM: dts: imx: Add Advantech BA-16 Qseven module

[Arnd Bergmann]

On Wednesday 02 December 2015 13:16:16 Akshay Bhat wrote:
> +   brightness-levels = <  0   1   2   3   4   5   6   7   8   9
> + 10  11  12  13  14  15  16  17  18  19
> + 20  21  22  23  24  25  26  27  28  29
> + 30  31  32  33  34  35  36  37  38  39
> + 40  41  42  43  44  45  46  47  48  49
> + 50  51  52  53  54  55  56  57  58  59
> + 60  61  62  63  64  65  66  67  68  69
> + 70  71  72  73  74  75  76  77  78  79
> + 80  81  82  83  84  85  86  87  88  89
> + 90  91  92  93  94  95  96  97  98  99
> +100 101 102 103 104 105 106 107 108 109
> +110 111 112 113 114 115 116 117 118 119
> +120 121 122 123 124 125 126 127 128 129
> +130 131 132 133 134 135 136 137 138 139
> +140 141 142 143 144 145 146 147 148 149
> +150 151 152 153 154 155 156 157 158 159
> +160 161 162 163 164 165 166 167 168 169
> +170 171 172 173 174 175 176 177 178 179
> +180 181 182 183 184 185 186 187 188 189
> +190 191 192 193 194 195 196 197 198 199
> +200 201 202 203 204 205 206 207 208 209
> +210 211 212 213 214 215 216 217 218 219
> +220 221 222 223 224 225 226 227 228 229
> +230 231 232 233 234 235 236 237 238 239
> +240 241 242 243 244 245 246 247 248 249
> +250 251 252 253 254 255>;
> 

That is a lot of brightness levels. Why do you need so many of them?

Arnd
--
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 (v7) 2/2] mtd: brcmnand: Add support for the BCM63268

[Brian Norris]

+ Broadcom list + Kamal

Hi Simon,

On Wed, Nov 25, 2015 at 07:49:13PM +, Simon Arlott wrote:
> The BCM63268 has a NAND interrupt register with combined status and enable
> registers. It also has a clock for the NAND controller that needs to be
> enabled.
> 
> Set up the device by enabling the clock, disabling and acking all
> interrupts, then handle the CTRL_READY interrupt.
> 
> Add a brcmnand_get_socdata() function so that bcm63268_nand can obtain its
> data and disable the clock when the device is removed.
> 
> Signed-off-by: Simon Arlott 
> ---
> Added EXPORT_SYMBOL_GPL(brcmnand_get_socdata)
> 
> (As the brcmnand module must be loaded first its compatible string will
> apply to any existing devices before the soc-specific module can be
> loaded.)

What's this comment supposed to mean? The brcmnand module will not
directly probe any devices. It doesn't register any driver structs by
itself.

(BTW given that, it probably doesn't need its MODULE_DEVICE_TABLE.)

>  drivers/mtd/nand/brcmnand/Makefile|   1 +
>  drivers/mtd/nand/brcmnand/bcm63268_nand.c | 179 
> ++
>  drivers/mtd/nand/brcmnand/brcmnand.c  |   8 ++
>  drivers/mtd/nand/brcmnand/brcmnand.h  |   1 +
>  4 files changed, 189 insertions(+)
>  create mode 100644 drivers/mtd/nand/brcmnand/bcm63268_nand.c
> 
> diff --git a/drivers/mtd/nand/brcmnand/Makefile 
> b/drivers/mtd/nand/brcmnand/Makefile
> index 3b1fbfd..b83a9ae 100644
> --- a/drivers/mtd/nand/brcmnand/Makefile
> +++ b/drivers/mtd/nand/brcmnand/Makefile
> @@ -2,5 +2,6 @@
>  # more specific iproc_nand.o, for instance
>  obj-$(CONFIG_MTD_NAND_BRCMNAND)  += iproc_nand.o
>  obj-$(CONFIG_MTD_NAND_BRCMNAND)  += bcm63138_nand.o
> +obj-$(CONFIG_MTD_NAND_BRCMNAND)  += bcm63268_nand.o
>  obj-$(CONFIG_MTD_NAND_BRCMNAND)  += brcmstb_nand.o
>  obj-$(CONFIG_MTD_NAND_BRCMNAND)  += brcmnand.o
> diff --git a/drivers/mtd/nand/brcmnand/bcm63268_nand.c 
> b/drivers/mtd/nand/brcmnand/bcm63268_nand.c
> new file mode 100644
> index 000..70ad907
> --- /dev/null
> +++ b/drivers/mtd/nand/brcmnand/bcm63268_nand.c
> @@ -0,0 +1,179 @@
> +/*
> + * Copyright 2015 Simon Arlott
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * Derived from bcm63138_nand.c:
> + * Copyright © 2015 Broadcom Corporation
> + *
> + * Derived from 
> bcm963xx_4.12L.06B_consumer/shared/opensource/include/bcm963xx/63268_map_part.h:
> + * Copyright 2000-2010 Broadcom Corporation
> + *
> + * Derived from 
> bcm963xx_4.12L.06B_consumer/shared/opensource/flash/nandflash.c:
> + * Copyright 2000-2010 Broadcom Corporation
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "brcmnand.h"
> +
> +struct bcm63268_nand_soc {
> + struct brcmnand_soc soc;
> + void __iomem *base;
> + struct clk *clk;
> +};
> +
> +#define BCM63268_NAND_INT0x00
> +#define  BCM63268_NAND_STATUS_SHIFT  0
> +#define  BCM63268_NAND_STATUS_MASK   (0xfff << BCM63268_NAND_STATUS_SHIFT)
> +#define  BCM63268_NAND_ENABLE_SHIFT  16
> +#define  BCM63268_NAND_ENABLE_MASK   (0x << BCM63268_NAND_ENABLE_SHIFT)
> +#define BCM63268_NAND_BASE_ADDR0 0x04
> +#define BCM63268_NAND_BASE_ADDR1 0x0c
> +
> +enum {
> + BCM63268_NP_READ= BIT(0),
> + BCM63268_BLOCK_ERASE= BIT(1),
> + BCM63268_COPY_BACK  = BIT(2),
> + BCM63268_PAGE_PGM   = BIT(3),
> + BCM63268_CTRL_READY = BIT(4),
> + BCM63268_DEV_RBPIN  = BIT(5),
> + BCM63268_ECC_ERR_UNC= BIT(6),
> + BCM63268_ECC_ERR_CORR   = BIT(7),
> +};
> +
> +static bool bcm63268_nand_intc_ack(struct brcmnand_soc *soc)
> +{
> + struct bcm63268_nand_soc *priv =
> + container_of(soc, struct bcm63268_nand_soc, soc);
> + void __iomem *mmio = priv->base + BCM63268_NAND_INT;
> + u32 val = brcmnand_readl(mmio);
> +
> + if (val & (BCM63268_CTRL_READY << BCM63268_NAND_STATUS_SHIFT)) {
> + /* Ack interrupt */
> + val &= ~BCM63268_NAND_STATUS_MASK;
> + val |= BCM63268_CTRL_READY << BCM63268_NAND_STATUS_SHIFT;
> + brcmnand_writel(val, mmio);
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static void bcm63268_nand_intc_set(struct brcmnand_soc *soc, bool en)
> +{
> + struct bcm63268_nand_soc *priv =
> + container_of(soc, struct bcm63268_nand_soc, soc);
> + void __iomem *mmio = priv->base + BCM63268_NAND_INT;
> + u32 val = brcmnan

Re: [PATCH v4 1/2] watchdog: imx2_wdt: add external reset support via 'ext-reset-output' dt prop

[Akshay Bhat]

On 11/06/2015 05:02 PM, Guenter Roeck wrote:

On Fri, Nov 06, 2015 at 11:53:42AM -0800, Tim Harvey wrote:

On Thu, Nov 5, 2015 at 2:23 PM, Guenter Roeck  wrote:

On Thu, Nov 05, 2015 at 04:19:21PM -0500, Akshay Bhat wrote:

From: Tim Harvey 

The IMX6 watchdog supports assertion of a signal (WDOG_B) which
can be pinmux'd to an external pin. This is typically used for boards that
have PMIC's in control of the IMX6 power rails. In fact, failure to use
such an external reset on boards with external PMIC's can result in various
hangs due to the IMX6 not being fully reset [1] as well as the board failing
to reset because its PMIC has not been reset to provide adequate voltage for
the CPU when coming out of reset at 800Mhz.

This uses a new device-tree property 'ext-reset-output' to indicate the
board has such a reset and to cause the watchdog to be configured to assert
WDOG_B instead of an internal reset both on a watchdog timeout and in
system_restart.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html

Cc: Lucas Stach 
Signed-off-by: Tim Harvey 
---
  .../devicetree/bindings/watchdog/fsl-imx-wdt.txt |  2 ++
  drivers/watchdog/imx2_wdt.c  | 20 ++--
  2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
index 8dab6fd..9b89b3a 100644
--- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
@@ -9,6 +9,8 @@ Optional property:


properties ?


  - big-endian: If present the watchdog device's registers are implemented
in big endian mode, otherwise in native mode(same with CPU), for more
detail please see: Documentation/devicetree/bindings/regmap/regmap.txt.
+- ext-reset-output: If present the watchdog device is configured to assert its


Should that have a vendor prefix ? Also, not sure if "-output"
has any real value in the property name. "fsl,external-reset", maybe ?


Hi Guenter,

I don't see why a vendor prefix is necessary - its a feature of the
IMX6 watchdog supported by this driver to be able to trigger an
internal chip-level reset and/or an external signal that can be hooked
to additional hardware.


Sounded like vendor specific to me, but then I am not a devicetree maintainer,
so I am not an authority on the subject.


Devicetree maintainers,

Any thoughts?

Tim,

After looking at all the other watchdog drivers, it does not appear that 
there is any other processor which uses a similar feature. Since imx is 
the only processor that appears to support this feature, it might make 
sense in making this vendor specific. If in the future it is found more 
processors support a similar functionality, it can be revisited and 
moved out from being vendor specific?





I started with ext-reset, but it was suggested
(http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/347437.html)
to also make it clear that this is an 'output' and not a reset input.


No problem, as long as you get an Ack from a devicetree maintainer.

Guenter


--
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) 1/2] mtd: brcmnand: Add brcm,bcm63268-nand device tree binding

[Brian Norris]

+ Broadcom list + Kamal

On Tue, Nov 24, 2015 at 08:19:37PM -, Simon Arlott wrote:
> Add device tree binding for NAND on the BCM63268.
> 
> The BCM63268 has a NAND interrupt register with combined status and enable
> registers.
> 
> Signed-off-by: Simon Arlott 
> ---
>  .../devicetree/bindings/mtd/brcm,brcmnand.txt  | 35 
> ++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> index 4ff7128..f2a71c8 100644
> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and 
> associated register resources w
> and enable registers
>   - reg-names: (required) "nand-int-base"
> 
> +   * "brcm,nand-bcm63268"
> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm63268"

Looks like you're aiming to support bcm63168? Is bcm63268 the first
chip to include this style of register then? The numbering seems
backwards, but that may just be reality.

> + - reg: (required) the 'NAND_INTR_BASE' register range, with combined 
> status
> +   and enable registers, and boot address registers
> + - reg-names: (required) "nand-intr-base"
> + - clock: (required) reference to the clock for the NAND controller
> + - clock-names: (required) "nand"
> +
> * "brcm,nand-iproc"
>   - reg: (required) the "IDM" register range, for interrupt enable and APB
> bus access endianness configuration, and the "EXT" register range,
> @@ -148,3 +156,30 @@ nand@f0442800 {
>   };
>   };
>  };
> +
> +nand@1200 {
> + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm63268",
> + "brcm,brcmnand-v4.0", "brcm,brcmnand";
> + reg = <0x1200 0x180>,
> +   <0x1600 0x200>,
> +   <0x10b0 0x10>;
> + reg-names = "nand", "nand-cache", "nand-intr-base";
> + interrupt-parent = <&periph_intc>;
> + interrupts = <50>;
> + clocks = <&periph_clk 20>;
> + clock-names = "nand";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + nand0: nandcs@0 {
> + compatible = "brcm,nandcs";
> + reg = <0>;
> + nand-on-flash-bbt;
> + nand-ecc-strength = <1>;
> + nand-ecc-step-size = <512>;
> +
> + #address-cells = <0>;
> + #size-cells = <0>;

What are these {address,size}-cells for? If you need them for
partitioning, then those are wrong -- they shouldn't be zero. Maybe just
drop them? (I can cut them out when applying, if that's the only change
to make.)

> + };
> +};

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 RFC 0/3] input: rotary_encoder: use more than two gpios as input

[Uwe Kleine-König]

Hello,

On Wed, Dec 02, 2015 at 01:52:58PM +0100, Rojhalat Ibrahim wrote:
> On Wednesday 02 December 2015 11:07:11 Uwe Kleine-König wrote:
> > some time ago I worked on the rotary encoder driver to make it support
> > more than two input lines. This is the (only slightly tested[1]) rebase of
> > this series on top of 4.4-rc2 (from 4.1).
> > 
> > It would be great to get some feedback, especially (but not only) for my
> > change to raumfeld.c.
> > 
> > Before Ezequiel's patch 3a341a4c30d4 ("Input: rotary-encoder - add
> > support for quarter-period mode") we had a dt property
> > "rotary-encoder,half-period" defined. It's presence meant that we had 2
> > indents per period; it's absence that there is only 1. Ezequiel
> > introduced rotary-encoder,steps-per-period instead when adding support
> > for quarter-period mode (which has 4 indents per period).
> > 
> > Up to now (i.e. with two inputs) a period has length 4. Now with (say)
> > four inputs a period has length 16 instead. Now how should this be
> > modeled in dt? This series implements that I have to pass
> > 
> > rotary-encoder,steps-per-period = <16>;
> > 
> > now for "quarter-period mode" (i.e. 4 indents per 4 state changes[2]),
> > but that feels unnatural. I'd prefer to set a property to <1> instead,
> > meaning the device has an indent for each state change[2]. half-period
> > mode would be <2> and full-period mode would be <4>. But I don't have a
> > nice name for such a property and maybe it's easier to live with
> > steps-per-period = <16>? What do you think?
> > 
> > Also note that these patches are not as technically versatile as
> > possible. With 4 (n) input lines we could detect a quick rotation where the
> > machine's latency only allows to sample after 7 (2^(n-1)-1) state
> > changes. Currently this is not implemented, but can be done later.
> > 
> > Best regards
> > Uwe
> > 
> 
> AFAIUI the rotary encoder driver only handles incremental encoders not
> absolute encoders. (So in fact the assumed rotary encoder could also be a

There is a device tree property "rotary-encoder,relative-axis" which
switches between absolute and relative reporting. This is maybe badly
named, but IIUC is there to differenciate between incremental and
absolute encoders.

> linear encoder with an incremental interface.) Those encoders almost always
> have an interface with two outputs (A, B) with a phase shift of 90 degrees
> between them. So in this case we have 4 steps per period. Sometimes there
> is only one line for 1 or 2 steps per period. But I have never seen or

I don't see how using only a single gpio would work for a rotary
encoder. I suspect we use different vocabulary to describe our devices
and so don't understand each other?! At least you cannot detect the
direction of the movement with a single input line, do you?

> heard of a device with more than 2 lines (except for the third output which
> serves as a reference position index marker).
> 
> Do devices wirh more than two outputs actually exist?
> Or is the purpose of supporting more than 2 lines something other than
> connecting an actual encoder to them?

I have a real rotary encoder with 4 input lines and so 16
distinguishable positions. It would be described as:

compatible = "rotary-encoder";
gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>, <&gpio4 11 GPIO_ACTIVE_HIGH>, 
<&gpio4 10 GPIO_ACTIVE_HIGH>, <&gpio4 9 GPIO_ACTIVE_HIGH>;
rotary-encoder,steps = <16>;
rotary-encoder,steps-per-period = <16>;

with the binding implemented in my patches.

The wikipedia article about rotary encoders[1] uses a device with 3
input lines to explain gray encoding. So I didn't consider "my" device
as exotic up to now.

Best regards
Uwe

[1] https://en.wikipedia.org/wiki/Rotary_encoder

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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/3] Device tree binding documentation for chromeos-firmware

[Rob Herring]

On Wed, Dec 2, 2015 at 10:49 AM, Martyn Welch
 wrote:
>
>
> On 02/12/15 15:15, Rob Herring wrote:
>>
>> On Tue, Dec 01, 2015 at 07:12:49PM +, Martyn Welch wrote:
>>>
>>> This patch adds documentation for the chromeos-firmware binding.
>>>
>>> Cc: Rob Herring 
>>> Cc: Pawel Moll 
>>> Cc: Mark Rutland 
>>> Cc: Ian Campbell 
>>> Cc: Kumar Gala 
>>> Cc: devicetree@vger.kernel.org
>>> Signed-off-by: Martyn Welch 
>>> ---
>>>   .../devicetree/bindings/misc/chromeos-firmware.txt | 27
>>> ++
>>
>>
>> bindings/firmware/ please.
>>
>
> OK.
>
>>>   1 file changed, 27 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/misc/chromeos-firmware.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
>>> b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
>>> new file mode 100644
>>> index 000..8240611
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/misc/chromeos-firmware.txt
>>> @@ -0,0 +1,27 @@
>>> +Device-Tree bindings for chromeos-firmware.c.
>>
>>
>> Perhaps a bit more description what this is.
>>
>> What aspect of this is firmware? How does this relate to the EC?
>>
>
> With respect to write-protect, this line is the write protection for the
> flash which holds the bootloader.

What is driving the write-protect? Are trying to assign ownership of
the SOC GPIOs to the bootloader/firmware? If so, I think this is all
wrong.

Rob
--
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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi Roger,

On Wed, Dec 02, 2015 at 10:42:12AM +0530, Roger Quadros wrote:
> On 02/12/15 08:56, Brian Norris wrote:
> > On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote:
> >> On 30/11/15 21:54, Brian Norris wrote:
> >>> But anyway, I'm not sure that completely answered my question. My
> >>> question was whether you were removing the irqchip code solely for
> >>> performance reasons, or are there others?
> >>
> >> Yes. Only for performance reasons.
> > 
> > Hmm, that's not my favorite answer. I'd prefer that more analysis was
> > done here before scrapping irqchip...
> 
> I agree. We could retain the irqchip model till we have more satisfying
> analysis.

I won't insist, though if it's not too ugly/horrible to do so, I think
that would make sense. I'll leave it as your call.

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 v3 3/7] ARM: dts: imx: Add Advantech BA-16 Qseven module

[Akshay Bhat]

On 11/16/2015 06:16 AM, Lucas Stach wrote:

Hi Akshay,

another comment below and in the next patch, sorry for not spotting this
in the last round.

Regards,
Lucas



Thanks for the continued feedback :)


Am Dienstag, den 10.11.2015, 13:00 -0500 schrieb Akshay Bhat:

From: Justin Waters 

Add support for Advantech BA-16 module based on iMX6D processor

http://www2.advantech.com/products/medical_computing_system/dms-ba16/mod_64aa1566-169c-483d-97c8-c2c22c163fc3.aspx
Signed-off-by: Akshay Bhat 
---
  arch/arm/boot/dts/imx6q-ba16.dtsi | 584 ++
  1 file changed, 584 insertions(+)
  create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi

diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi 
b/arch/arm/boot/dts/imx6q-ba16.dtsi
new file mode 100644
index 000..d0c4568
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
@@ -0,0 +1,584 @@
+/*
+ * Support for imx6 based Advantech DMS-BA16 Qseven module
+ *
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx6q.dtsi"
+#include 
+
+/ {
+   memory {
+   reg = <0x1000 0x4000>;
+   };
+
+   clocks {
+   clk24m: clk24m {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2400>;
+   };
+   };
+
+   regulators {
+   compatible = "simple-bus";
+


The use of a simple-bus, while giving some structure to the DT is
considered bad style as it doesn't reflect any real hardware.

Please remove this, the regulators should be located the same DT level
as the backlight and other board components.


Thanks for the explanation. Fixed in v4 version of patch:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390373.html




+   reg_usb_otg_vbus: regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_otg_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   reg_usb_h1_vbus: regulator@2 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_h1_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   reg_1p8v: regulator@3 {
+   compatible = "regulator-fixed";
+   regulator-name = "1P8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   reg_3p3v: regulator@4 {
+   compatible = "regulator-fixed";
+   regulator-name = "3P3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   lvds_ppen: regulator@5 {
+   compatible = "regulator-fixed";
+   regulator-name = "lvds_ppen";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+   };
+
+   backlight {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_display>;
+   compatible = "pwm-backlight";
+   pwms = <&pwm1 0 500>;
+   brightness-levels = <  0   1   2   3   4   5   6   7   8   9
+ 10  11  12  13  14  15  16  17  18  19
+ 20  21  22  23  24  25  26  27  28  29
+ 30  31  32  33  34  35  36  37  38  39
+ 40  41  42  43  44  45  46  47  48  49
+ 50  51  52  53  54  55  56  57  58  59
+ 60  61  62  63  64  65  66  67  68  69
+ 70  71  72  73  74  75  76  77  78  79
+ 80  81  82  83  84  85  86  87  88  89
+ 90  91  92  93  94  95  96  97  98  99
+100 101 102 103 104 105 106 107 108 109
+110 111 112 113 114 115 116 117 118 119
+ 

[PATCH 2/2] drm/panel: simple: Add support for Kyocera TCG121XGLP panel

[Lucas Stach]

The Kyocera TCG121XGLP panel is an XGA LCD TFT panel connected through
LVDS, which can be supported by the simple panel driver.

Signed-off-by: Lucas Stach 
---
 .../bindings/display/panel/kyo,tcg121xglp.txt  |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 2 files changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/kyo,tcg121xglp.txt

diff --git a/Documentation/devicetree/bindings/display/panel/kyo,tcg121xglp.txt 
b/Documentation/devicetree/bindings/display/panel/kyo,tcg121xglp.txt
new file mode 100644
index ..a8e940fe731e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/kyo,tcg121xglp.txt
@@ -0,0 +1,7 @@
+Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel
+
+Required properties:
+- compatible: should be "kyo,tcg121xglp"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f97b73ec4713..1476bb90ac14 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -902,6 +902,30 @@ static const struct panel_desc innolux_zj070na_01p = {
},
 };
 
+static const struct display_timing kyo_tcg121xglp_timing = {
+   .pixelclock = { 5200, 6500, 7100 },
+   .hactive = { 1024, 1024, 1024 },
+   .hfront_porch = { 2, 2, 2 },
+   .hback_porch = { 2, 2, 2 },
+   .hsync_len = { 86, 124, 244 },
+   .vactive = { 768, 768, 768 },
+   .vfront_porch = { 2, 2, 2 },
+   .vback_porch = { 2, 2, 2 },
+   .vsync_len = { 6, 34, 73 },
+   .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc kyo_tcg121xglp = {
+   .timings = &kyo_tcg121xglp_timing,
+   .num_timings = 1,
+   .bpc = 8,
+   .size = {
+   .width = 246,
+   .height = 184,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+};
+
 static const struct drm_display_mode lg_lb070wv8_mode = {
.clock = 33246,
.hdisplay = 800,
@@ -1167,6 +1191,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,zj070na-01p",
.data = &innolux_zj070na_01p,
}, {
+   .compatible = "kyo,tcg121xglp",
+   .data = &kyo_tcg121xglp,
+   }, {
.compatible = "lg,lb070wv8",
.data = &lg_lb070wv8,
}, {
-- 
2.6.2

--
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 1/2] devicetree: add vendor prefix for Kyocera Corporation

[Lucas Stach]

KYO is the stock ticker symbol of Kyocera Corporation.

Signed-off-by: Lucas Stach 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 55df1d444e9f..7c6464c1f9f1 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -123,6 +123,7 @@ jedec   JEDEC Solid State Technology Association
 karo   Ka-Ro electronics GmbH
 keymileKeymile GmbH
 kinetic Kinetic Technologies
+kyoKyocera Corporation
 lacie  LaCie
 lantiq Lantiq Semiconductor
 lenovo Lenovo Group Ltd.
-- 
2.6.2

--
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 v3 5/7] ARM: dts: imx: Add support for Advantech/GE B450v3

[Akshay Bhat]

On 11/16/2015 06:19 AM, Lucas Stach wrote:

Am Dienstag, den 10.11.2015, 13:00 -0500 schrieb Akshay Bhat:

Add support for Advantech/GE B450v3 board.

Signed-off-by: Akshay Bhat 
---
  arch/arm/boot/dts/Makefile |  1 +
  arch/arm/boot/dts/imx6q-b450v3.dts | 75 ++
  2 files changed, 76 insertions(+)
  create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..b3330fe 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -310,6 +310,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-wandboard-revb1.dtb \
imx6q-apf6dev.dtb \
imx6q-arm2.dtb \
+   imx6q-b450v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts 
b/arch/arm/boot/dts/imx6q-b450v3.dts
new file mode 100644
index 000..919e4a4
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -0,0 +1,75 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+   model = "Advantech MX6Q B450V3 QSeven Board";
+   compatible = "ge,imx6q-b450v3", "advantech,imx6q-ba16", "fsl,imx6q";
+
+   chosen {
+   stdout-path = &uart3;
+   };
+};
+
+&ldb {
+   assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+   assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+   status = "okay";
+
+   lvds0: lvds-channel@0 {
+   fsl,data-mapping = "spwg";
+   fsl,data-width = <24>;
+   status = "okay";
+
+   display-timings {
+   native-mode = <&timing0>;
+   timing0: G121X1-L03 {
+   clock-frequency = <6500>;
+   hactive = <1024>;
+   vactive = <768>;
+   hback-porch = <320>;
+   hfront-porch = <0>;
+   vback-porch = <0>;
+   vfront-porch = <38>;
+   hsync-len = <1>;
+   vsync-len = <1>;
+   };
+   };


Display timings in DT are deprecated and new boards should add the
display with a specific compatible to the simple-panel driver and then
link a panel node to the LVDS channels. Take a look at the i.MX6
Nitrogen DTs for an example on how to do this.

Same comment applies to the next patches as well.


Thanks for the example Lucas. Added G121X1-L03 panel which is now in 
linux-next 
(https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel?h=next-20151127&id=f8fa17ba812b7df1535f6bb75d7264670f5997a6)


v4 patch now uses simple-panel:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390373.html




+   };
+
+   lvds1: lvds-channel@1 {
+   fsl,data-mapping = "spwg";
+   fsl,data-width = <24>;
+   status = "okay";
+
+   display-timings {
+   native-mode = <&timing1>;
+   timing1: G121X1-L03 {
+   clock-frequency = <6500>;
+   hactive = <1024>;
+   vactive = <768>;
+   hback-porch = <320>;
+   hfront-porch = <0>;
+   vback-porch = <0>;
+   vfront-porch = <38>;
+   hsync-len = <1>;
+   vsync-len = <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 v4 6/7] ARM: dts: imx: Add support for Advantech/GE B650v3

[Akshay Bhat]

Add support for Advantech/GE B650v3 board.

Signed-off-by: Akshay Bhat 
---
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/imx6q-b650v3.dts | 84 ++
 2 files changed, 85 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-b650v3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 219830f..9cdff66 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -311,6 +311,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-apf6dev.dtb \
imx6q-arm2.dtb \
imx6q-b450v3.dtb \
+   imx6q-b650v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts 
b/arch/arm/boot/dts/imx6q-b650v3.dts
new file mode 100644
index 000..cbe99fd
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -0,0 +1,84 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+   model = "Advantech MX6Q B650V3 QSeven Board";
+   compatible = "ge,imx6q-b650v3", "advantech,imx6q-ba16", "fsl,imx6q";
+
+   chosen {
+   stdout-path = &uart3;
+   };
+
+   panel_lvds0 {
+   compatible = "innolux,g121x1-l03";
+   backlight = <&backlight_lvds>;
+   power-supply = <®_lvds>;
+
+   port {
+   panel_in_lvds0: endpoint {
+   remote-endpoint = <&lvds0_out>;
+   };
+   };
+   };
+
+   panel_lvds1 {
+   compatible = "innolux,g121x1-l03";
+   backlight = <&backlight_lvds>;
+   power-supply = <®_lvds>;
+
+   port {
+   panel_in_lvds1: endpoint {
+   remote-endpoint = <&lvds1_out>;
+   };
+   };
+   };
+};
+
+&ldb {
+   assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+   assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+   status = "okay";
+
+   lvds0: lvds-channel@0 {
+   fsl,data-mapping = "spwg";
+   fsl,data-width = <24>;
+   status = "okay";
+
+   port@4 {
+   reg = <4>;
+
+   lvds0_out: endpoint {
+   remote-endpoint = <&panel_in_lvds0>;
+   };
+   };
+   };
+
+   lvds1: lvds-channel@1 {
+   fsl,data-mapping = "spwg";
+   fsl,data-width = <24>;
+   status = "okay";
+
+   port@4 {
+   reg = <4>;
+
+   lvds1_out: endpoint {
+   remote-endpoint = <&panel_in_lvds1>;
+   };
+   };
+   };
+};
-- 
2.6.3

--
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 v4 4/7] ARM: dts: imx: Add support for Advantech/GE Bx50v3

[Akshay Bhat]

From: Justin Waters 

Advantech has 3 carrier boards (B450v3, B650v3, B850v3) which use
the Advantech BA-16 module (based on iMX6D). This file has the
devicetree entries that are common to all 3 boards.

Signed-off-by: Akshay Bhat 
---
 arch/arm/boot/dts/imx6q-bx50v3.dtsi | 207 
 1 file changed, 207 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi

diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi 
b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
new file mode 100644
index 000..61bb9aa
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -0,0 +1,207 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx6q-ba16.dtsi"
+
+/ {
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mclk: clock@0 {
+   compatible = "fixed-clock";
+   reg = <0>;
+   #clock-cells = <0>;
+   clock-frequency = <2200>;
+   };
+   };
+
+   reg_wl18xx_vmmc: regulator@6 {
+   compatible = "regulator-fixed";
+   regulator-name = "vwl1807";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&pca9539 3 GPIO_ACTIVE_HIGH>;
+   startup-delay-us = <7>;
+   enable-active-high;
+   };
+
+   reg_wlan: regulator@7 {
+   compatible = "regulator-fixed";
+   regulator-name = "3P3V_wlan";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   regulator-boot-on;
+   gpio = <&gpio6 14 GPIO_ACTIVE_HIGH>;
+   };
+
+   sound {
+   compatible = "fsl,imx6q-ba16-sgtl5000",
+"fsl,imx-audio-sgtl5000";
+   model = "imx6q-ba16-sgtl5000";
+   ssi-controller = <&ssi1>;
+   audio-codec = <&codec>;
+   audio-routing =
+   "MIC_IN", "Mic Jack",
+   "Mic Jack", "Mic Bias",
+   "LINE_IN", "Line In Jack",
+   "Headphone Jack", "HP_OUT";
+   mux-int-port = <1>;
+   mux-ext-port = <4>;
+   };
+};
+
+&ecspi5 {
+   fsl,spi-num-chipselects = <1>;
+   cs-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ecspi5>;
+   status = "okay";
+
+   m25_eeprom: m25p80@0 {
+   compatible = "atmel,at25";
+   spi-max-frequency = <2000>;
+   size = <0x8000>;
+   pagesize = <64>;
+   reg = <0>;
+   address-width = <16>;
+   };
+};
+
+&i2c1 {
+   pca9547: mux@70 {
+   compatible = "nxp,pca9547";
+   reg = <0x70>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mux_i2c3: i2c@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0>;
+
+   ads7830: ads7830@48 {
+   compatible = "ti,ads7830";
+   reg = <0x48>;
+   };
+
+   mma8453: mma8453@1c {
+   compatible = "fsl,mma8453";
+   reg = <0x1c>;
+   };
+   };
+
+   mux_i2c4: i2c@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x1>;
+
+   eeprom: eeprom@50 {
+   compatible = "atmel,24c08";
+   reg = <0x50>;
+   };
+
+   mpl3115: mpl3115@60 {
+   compatible = "fsl,mpl3115";
+   reg = <0x60>;
+   };
+   };
+
+   mux_i2c5: i2c@2 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x2>;
+   };
+
+   mux_i2c6: i2c@3 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x3>;
+
+   codec: sgtl5000@0a {
+   compatible = "fsl,sgtl5000";
+   reg = <0x0a>;
+   clocks = <&mclk>;
+ 

[PATCH v4 2/7] of: Add vendor prefix for General Electric Company

[Akshay Bhat]

This patch adds vendor prefix for General Electric Company

Signed-off-by: Akshay Bhat 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c51bf7c..f1cc839 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -88,6 +88,7 @@ fcs   Fairchild Semiconductor
 fireflyFirefly
 focaltech  FocalTech Systems Co.,Ltd
 fslFreescale Semiconductor
+ge General Electric Company
 GEFanucGE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gefGE Fanuc Intelligent Platforms Embedded Systems, Inc.
 geniatech  Geniatech, Inc.
-- 
2.6.3

--
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 v4 5/7] ARM: dts: imx: Add support for Advantech/GE B450v3

[Akshay Bhat]

Add support for Advantech/GE B450v3 board.

Signed-off-by: Akshay Bhat 
---
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/imx6q-b450v3.dts | 84 ++
 2 files changed, 85 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 760a737..219830f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -310,6 +310,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-wandboard-revb1.dtb \
imx6q-apf6dev.dtb \
imx6q-arm2.dtb \
+   imx6q-b450v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts 
b/arch/arm/boot/dts/imx6q-b450v3.dts
new file mode 100644
index 000..ba1ec0a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -0,0 +1,84 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+   model = "Advantech MX6Q B450V3 QSeven Board";
+   compatible = "ge,imx6q-b450v3", "advantech,imx6q-ba16", "fsl,imx6q";
+
+   chosen {
+   stdout-path = &uart3;
+   };
+
+   panel_lvds0 {
+   compatible = "innolux,g121x1-l03";
+   backlight = <&backlight_lvds>;
+   power-supply = <®_lvds>;
+
+   port {
+   panel_in_lvds0: endpoint {
+   remote-endpoint = <&lvds0_out>;
+   };
+   };
+   };
+
+   panel_lvds1 {
+   compatible = "innolux,g121x1-l03";
+   backlight = <&backlight_lvds>;
+   power-supply = <®_lvds>;
+
+   port {
+   panel_in_lvds1: endpoint {
+   remote-endpoint = <&lvds1_out>;
+   };
+   };
+   };
+};
+
+&ldb {
+   assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+   assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+   status = "okay";
+
+   lvds0: lvds-channel@0 {
+   fsl,data-mapping = "spwg";
+   fsl,data-width = <24>;
+   status = "okay";
+
+   port@4 {
+   reg = <4>;
+
+   lvds0_out: endpoint {
+   remote-endpoint = <&panel_in_lvds0>;
+   };
+   };
+   };
+
+   lvds1: lvds-channel@1 {
+   fsl,data-mapping = "spwg";
+   fsl,data-width = <24>;
+   status = "okay";
+
+   port@4 {
+   reg = <4>;
+
+   lvds1_out: endpoint {
+   remote-endpoint = <&panel_in_lvds1>;
+   };
+   };
+   };
+};
-- 
2.6.3

--
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 v4 3/7] ARM: dts: imx: Add Advantech BA-16 Qseven module

[Akshay Bhat]

From: Justin Waters 

Add support for Advantech BA-16 module based on iMX6D processor

http://www2.advantech.com/products/medical_computing_system/dms-ba16/mod_64aa1566-169c-483d-97c8-c2c22c163fc3.aspx
Signed-off-by: Akshay Bhat 
---
 arch/arm/boot/dts/imx6q-ba16.dtsi | 586 ++
 1 file changed, 586 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi

diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi 
b/arch/arm/boot/dts/imx6q-ba16.dtsi
new file mode 100644
index 000..e5779a0
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
@@ -0,0 +1,586 @@
+/*
+ * Support for imx6 based Advantech DMS-BA16 Qseven module
+ *
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx6q.dtsi"
+#include 
+
+/ {
+   memory {
+   reg = <0x1000 0x4000>;
+   };
+
+   clocks {
+   clk24m: clk24m {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2400>;
+   };
+   };
+
+   backlight_lvds: backlight {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_display>;
+   compatible = "pwm-backlight";
+   pwms = <&pwm1 0 500>;
+   brightness-levels = <  0   1   2   3   4   5   6   7   8   9
+ 10  11  12  13  14  15  16  17  18  19
+ 20  21  22  23  24  25  26  27  28  29
+ 30  31  32  33  34  35  36  37  38  39
+ 40  41  42  43  44  45  46  47  48  49
+ 50  51  52  53  54  55  56  57  58  59
+ 60  61  62  63  64  65  66  67  68  69
+ 70  71  72  73  74  75  76  77  78  79
+ 80  81  82  83  84  85  86  87  88  89
+ 90  91  92  93  94  95  96  97  98  99
+100 101 102 103 104 105 106 107 108 109
+110 111 112 113 114 115 116 117 118 119
+120 121 122 123 124 125 126 127 128 129
+130 131 132 133 134 135 136 137 138 139
+140 141 142 143 144 145 146 147 148 149
+150 151 152 153 154 155 156 157 158 159
+160 161 162 163 164 165 166 167 168 169
+170 171 172 173 174 175 176 177 178 179
+180 181 182 183 184 185 186 187 188 189
+190 191 192 193 194 195 196 197 198 199
+200 201 202 203 204 205 206 207 208 209
+210 211 212 213 214 215 216 217 218 219
+220 221 222 223 224 225 226 227 228 229
+230 231 232 233 234 235 236 237 238 239
+240 241 242 243 244 245 246 247 248 249
+250 251 252 253 254 255>;
+   default-brightness-level = <255>;
+   enable-gpios = <&gpio4 15 GPIO_ACTIVE_HIGH>;
+   };
+
+   reg_1p8v: regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "1P8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   reg_3p3v: regulator@2 {
+   compatible = "regulator-fixed";
+   regulator-name = "3P3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   reg_lvds: regulator@3 {
+   compatible = "regulator-fixed";
+   regulator-name = "lvds_ppen";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_usb_otg_vbus: regulator@4 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_otg_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   reg_usb_h1_vbus: regulator@5 {
+   compatible = "regulator-fixed

[PATCH v4 7/7] ARM: dts: imx: Add support for Advantech/GE B850v3

[Akshay Bhat]

Add support for Advantech/GE B850v3 board.

Signed-off-by: Akshay Bhat 
---
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/imx6q-b850v3.dts | 127 +
 2 files changed, 128 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-b850v3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9cdff66..37d5b09 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -312,6 +312,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-arm2.dtb \
imx6q-b450v3.dtb \
imx6q-b650v3.dtb \
+   imx6q-b850v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts 
b/arch/arm/boot/dts/imx6q-b850v3.dts
new file mode 100644
index 000..7ebb7d9
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -0,0 +1,127 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+   model = "Advantech MX6Q B850V3 QSeven Board";
+   compatible = "ge,imx6q-b850v3", "advantech,imx6q-ba16", "fsl,imx6q";
+
+   chosen {
+   stdout-path = &uart3;
+   };
+
+   panel_lvds0 {
+   compatible = "auo,b133htn01";
+   backlight = <&backlight_lvds>;
+   ddc-i2c-bus = <&mux_i2c12>;
+
+   port {
+   panel_in_lvds0: endpoint {
+   remote-endpoint = <&lvds0_out>;
+   };
+   };
+   };
+};
+
+&ldb {
+   assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+   assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+   fsl,dual-channel;
+   status = "okay";
+
+   lvds0: lvds-channel@0 {
+   fsl,data-mapping = "spwg";
+   fsl,data-width = <24>;
+   status = "okay";
+
+   port@4 {
+   reg = <4>;
+
+   lvds0_out: endpoint {
+   remote-endpoint = <&panel_in_lvds0>;
+   };
+   };
+   };
+};
+
+&i2c2 {
+   pca9547_ddc: mux@70 {
+   compatible = "nxp,pca9547";
+   reg = <0x70>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mux_i2c11: i2c@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0>;
+   };
+
+   mux_i2c12: i2c@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x1>;
+   };
+
+   mux_i2c13: i2c@2 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x2>;
+   };
+
+   mux_i2c14: i2c@3 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x3>;
+   };
+
+   mux_i2c15: i2c@4 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x4>;
+   };
+
+   mux_i2c16: i2c@5 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x5>;
+   };
+
+   mux_i2c17: i2c@6 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x6>;
+   };
+
+   mux_i2c18: i2c@7 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x7>;
+   };
+   };
+};
+
+&hdmi {
+   ddc-i2c-bus = <&mux_i2c11>;
+};
+
+&mux_i2c3 {
+   ads7830_2: ads7830@4a {
+   compatible = "ti,ads7830";
+   reg = <0x4a>;
+   };
+};
-- 
2.6.3

--
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 v4 1/7] of: Add vendor prefix for Advantech Corporation

[Akshay Bhat]

This patch adds vendor prefix for Advantech Corporation.

Website: http://www.advantech.com/
Signed-off-by: Akshay Bhat 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 62ff22f..c51bf7c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -10,6 +10,7 @@ adAvionic Design GmbH
 adapteva   Adapteva, Inc.
 adhAD Holdings Plc.
 adiAnalog Devices, Inc.
+advantech  Advantech Corporation
 aeroflexgaislerAeroflex Gaisler AB
 al Annapurna Labs
 allwinner  Allwinner Technology Co., Ltd.
-- 
2.6.3

--
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 v4 0/7] ARM: dts: Add Advantech board support

[Akshay Bhat]

This series aims to add Advantech BA-16 module (iMX6 based) and GE board 
support.

This series has been tested against linux-next tag next-20151127.

Modifications:
v3->v4:
- Remove simple-bus for regulators as suggested by Lucas Stash
- Use simple-panel instead of display-timings as suggested by Lucas Stash
- Add epson RTC node
- Reorder nodes alphabetically

History:

[v1]: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/381872.html
[v2]: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/383276.html
[v3]: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384202.html

Akshay Bhat (5):
  of: Add vendor prefix for Advantech Corporation
  of: Add vendor prefix for General Electric Company
  ARM: dts: imx: Add support for Advantech/GE B450v3
  ARM: dts: imx: Add support for Advantech/GE B650v3
  ARM: dts: imx: Add support for Advantech/GE B850v3

Justin Waters (2):
  ARM: dts: imx: Add Advantech BA-16 Qseven module
  ARM: dts: imx: Add support for Advantech/GE Bx50v3

 .../devicetree/bindings/vendor-prefixes.txt|   2 +
 arch/arm/boot/dts/Makefile |   3 +
 arch/arm/boot/dts/imx6q-b450v3.dts |  84 +++
 arch/arm/boot/dts/imx6q-b650v3.dts |  84 +++
 arch/arm/boot/dts/imx6q-b850v3.dts | 127 +
 arch/arm/boot/dts/imx6q-ba16.dtsi  | 586 +
 arch/arm/boot/dts/imx6q-bx50v3.dtsi| 207 
 7 files changed, 1093 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts
 create mode 100644 arch/arm/boot/dts/imx6q-b650v3.dts
 create mode 100644 arch/arm/boot/dts/imx6q-b850v3.dts
 create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi
 create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi

-- 
2.6.3

--
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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote:
> * Roger Quadros  [151201 21:13]:
> > On 02/12/15 08:56, Brian Norris wrote:
> > > 
> > > I'll take another pass over your patch set, but if things are looking
> > > better, how do you expect to merge this? There are significant portions
> > > that touch at least 2 or 3 different subsystem trees, AFAICT.
> > 
> > Tony could create an immutable branch with all the dts and memory changes.
> > You could base the mtd changes on top of that?
> 
> If we all agree on that it will be immutable Roger can set up the branch
> with our acks and we can all merge it in as needed. I believe v4.4-rc1
> should work as a base for us all?

There are oustanding comments about the NAND ready/busy GPIO naming in
patch 18, which I'd like addressed. I'll re-review the rest before the
end of the day (West Coast U.S.A.). I'm not sure my acks are worth much
beyond the MTD stuff.

Regarding branches, 4.4-rc1 is fine with me.

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/2] clk: Add brcm,bcm63xx-gate-clk device tree binding

[Florian Fainelli]

2015-11-30 12:52 GMT-08:00 Simon Arlott :
> Add device tree binding for the BCM63xx's gated clocks.
>
> The BCM63xx contains clocks gated with a register. Clocks are indexed
> by bits in the register and are active high. Clock gate bits are
> interleaved with other status bits and configurable clocks in the same
> register.
>
> Signed-off-by: Simon Arlott 
> ---
>  .../bindings/clock/brcm,bcm63xx-gate-clk.txt   | 58 
> ++
>  1 file changed, 58 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/brcm,bcm63xx-gate-clk.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/clock/brcm,bcm63xx-gate-clk.txt 
> b/Documentation/devicetree/bindings/clock/brcm,bcm63xx-gate-clk.txt
> new file mode 100644
> index 000..3f4ead1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,bcm63xx-gate-clk.txt
> @@ -0,0 +1,58 @@
> +Broadcom BCM63xx clocks
> +
> +This binding uses the common clock binding:
> +   Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +The BCM63xx contains clocks gated with a register. Clocks are indexed
> +by bits in the register and are active high. Clock gate bits are
> +interleaved with other status bits and configurable clocks in the same
> +register.

Most MIPS-based BCM63xx SoCs have clock gating set of registers, these
SoCs are pretty much all of them except 63381 (maybe newer ones too),
this one uses the PMB interface, like 63138 to control resets and
clocks fed to peripherals.

> +
> +Required properties:
> +- compatible:  Should be "brcm,bcm-gate-clk", "brcm,bcm63xx-gate-clk"

I think we would want to start with the lowest common denominator
here, which is either 6345 or 6348.
--
Florian
--
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] clk: bcm63xx: Add BCM63xx gated clock support

[Florian Fainelli]

2015-11-30 12:54 GMT-08:00 Simon Arlott :
> The BCM63xx contains clocks gated with a register. Clocks are indexed
> by bits in the register and are active high. Clock gate bits are
> interleaved with other status bits and configurable clocks in the same
> register.
>
> Enabled by default for BMIPS_GENERIC.
>
> Signed-off-by: Simon Arlott 
> ---

[snip]

> +
> +config CLK_BCM63XX
> +   bool "Broadcom BCM63xx clock support"
> +   depends on BMIPS_GENERIC
> +   depends on COMMON_CLK
> +   default y

default BMIPS_GENERIC?

> +   help
> + Enable clock framework support for Broadcom 63xx SoCs
> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> index 3fc9506..4f5f8ce 100644
> --- a/drivers/clk/bcm/Makefile
> +++ b/drivers/clk/bcm/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_COMMON_CLK_IPROC)  += clk-ns2.o
>  obj-$(CONFIG_ARCH_BCM_CYGNUS)  += clk-cygnus.o
>  obj-$(CONFIG_ARCH_BCM_NSP) += clk-nsp.o
>  obj-$(CONFIG_ARCH_BCM_5301X)   += clk-nsp.o
> +obj-$(CONFIG_CLK_BCM63XX)  += clk-bcm63xx.o
> diff --git a/drivers/clk/bcm/clk-bcm63xx.c b/drivers/clk/bcm/clk-bcm63xx.c
> new file mode 100644
> index 000..0e8cc06
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm63xx.c

There is a pending clk-bcm63xx.c implementation, covering BCM63138 in
Stephen Boyd's clk/next tree, which you would want to base your
patches on, it is not a huge deal to resolve the conflict, and there
will be separate entry points and functions based on the compatible
string anyway...

> @@ -0,0 +1,187 @@
> +/*
> + * Copyright 2015 Simon Arlott
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Based on clk-gate.c:
> + * Copyright (C) 2010-2011 Canonical Ltd 
> + * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd 
> + */

I am not really anything very specific to 63xx chips in there, in
fact, this looks like a fairly generic clk-gate driver using regmap to
get its masks and offsets, would it make sense to create
clk-gate-regmap.c which exposes the bulk of what you are doing and you
could match using a specific compatible string?
--
Florian
--
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] reset: bcm63xx: Add support for the BCM63xx soft-reset controller

[Florian Fainelli]

2015-11-30 12:58 GMT-08:00 Simon Arlott :
> The BCM63xx contains a soft-reset controller activated by setting
> a bit (that must previously have cleared).
>
> Signed-off-by: Simon Arlott 
> ---
>  MAINTAINERS   |   1 +
>  drivers/reset/Kconfig |   9 +++
>  drivers/reset/Makefile|   1 +
>  drivers/reset/reset-bcm63xx.c | 134 
> ++
>  4 files changed, 145 insertions(+)
>  create mode 100644 drivers/reset/reset-bcm63xx.c


Could you create a bcm directory and then add your reset-bcm63xx.c
file there? I have a pending submission for the BCM63138 reset
controller which is not at all using the same structure and will share
nothing with your driver.

[snip]

> +static int bcm63xx_reset_xlate(struct reset_controller_dev *rcdev,
> +   const struct of_phandle_args *reset_spec)
> +{
> +   struct bcm63xx_reset_priv *priv = to_bcm63xx_reset_priv(rcdev);
> +
> +   if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
> +   return -EINVAL;
> +
> +   if (reset_spec->args[0] >= rcdev->nr_resets)
> +   return -EINVAL;

Should not these two things be moved to the core reset controller code
based on the #reset-cells value?

[snip]

> +   if (of_property_read_u32(np, "offset", &priv->offset))
> +   return -EINVAL;
> +
> +   /* valid reset bits */
> +   if (of_property_read_u32(np, "mask", &priv->mask))
> +   priv->mask = 0x;
> +
> +   priv->rcdev.owner = THIS_MODULE;
> +   priv->rcdev.ops = &bcm63xx_reset_ops;
> +   priv->rcdev.nr_resets = 32;

Should not that come from Device Tree, or be computed based on the
mask property, like hweight_long() or something along these lines?

> +   priv->rcdev.of_node = pdev->dev.of_node;
> +   priv->rcdev.of_reset_n_cells = 1;
> +   priv->rcdev.of_xlate = bcm63xx_reset_xlate;

-- 
Florian
--
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/3] pinctrl: Broadcom NSP GPIO-a device tree bindings

[Ray Jui]

Hi Rob,

On 12/2/2015 7:07 AM, Rob Herring wrote:

On Tue, Dec 01, 2015 at 11:46:38PM -0500, Yendapally Reddy Dhananjaya Reddy 
wrote:

Device tree binding documentation for Broadcom NSP GPIO-a driver


Bindings are for h/w, not drivers...



Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
---
  .../devicetree/bindings/pinctrl/brcm,nsp-gpio.txt  | 80 ++
  1 file changed, 80 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt 
b/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
new file mode 100644
index 000..bea4211
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,nsp-gpio.txt
@@ -0,0 +1,80 @@
+Broadcom Northstar plus (NSP) GPIO/PINCONF Controller
+
+Required properties:
+- compatible:
+Must be "brcm,nsp-gpio-a"
+
+- reg:
+Should contain the register physical address and length for each of
+GPIO base, IO control registers
+
+- #gpio-cells:
+Must be two. The first cell is the GPIO pin number (within the
+controller's pin space) and the second cell is used for the following:
+bit[0]: polarity (0 for active high and 1 for active low)
+
+- gpio-controller:
+Specifies that the node is a GPIO controller
+
+- ngpios:
+Number of gpios supported (58x25 supports 32 and 58x23 supports 24)


2 chips? You should have 2 compatible strings. I think this is incorrect
use of ngpios which AIUI is not for how many lines there are, but how
many can be used (e.g. not reserved).



I believe this is the identical GPIO controller IP that is integrated 
into two different SoC chip variants. The only difference is the 
supported number of GPIO pins.


In this case, I believe this is what Linus prefers: 1) Using a single 
compatible string (tied to the GPIO controller IP); 2) Addressing 
difference in number of GPIOs using DT property 'ngpios'.


Thanks,

Ray
--
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: [PATCHv7 2/2] mailbox: Adding driver for Xilinx LogiCORE IP mailbox.

[Moritz Fischer]

Hi Jassi,

thanks for your feedback.

On Mon, Aug 10, 2015 at 1:05 AM, Jassi Brar  wrote:
> On Wed, Jul 15, 2015 at 6:30 AM, Moritz Fischer
>  wrote:
>
>> +
>> +static void xilinx_mbox_rx_data(struct mbox_chan *chan)
>> +{
>> +   struct xilinx_mbox *mbox = mbox_chan_to_xilinx_mbox(chan);
>> +   u32 data;
>> +
>> +   if (xilinx_mbox_pending(mbox)) {
>> +   data = readl_relaxed(mbox->mbox_base + MAILBOX_REG_RDDATA);
>> +   mbox_chan_received_data(chan, (void *)data);
>>
> If RDDATA is a FIFO, then above seems wrong - you are assuming
> messages are always going to be exactly 32-bits for every protocol.
> Ideally you should empty the fifo fully, at least when RX has an
> interrupt.

>From my understanding it's hard to tell how much actually is in the fifo,
you can tell if it's full for send direction, or empty for read direction.

Maybe the STI / RTI can be setup in a smart way to work with multiple message
sizes.
>
>> +
>> +static int xilinx_mbox_irq_send_data(struct mbox_chan *chan, void *data)
>> +{
>> +   struct xilinx_mbox *mbox = mbox_chan_to_xilinx_mbox(chan);
>> +   u32 *udata = data;
>> +
>> +   if (xilinx_mbox_full(mbox))
>> +   return -EBUSY;
>>
> This check is redundant. last_tx_done already makes sure this is always true.

Good to know. I'll fix it.
>
>> +   /* enable interrupt before send */
>> +   xilinx_mbox_tx_intmask(mbox, true);
>> +
>> +   writel_relaxed(*udata, mbox->mbox_base + MAILBOX_REG_WRDATA);
>> +
> From status EMPTY and FULL, it seems WRDATA is a FIFO. So here also
> you should expect messages to be <= fifo depth. And not assume exactly
> 32bit messages always.

How do I determine the message size? Doesn't
drivers/mailbox/bcm2835-mailbox.c or
mailbox-altera.c make the same assumption?

>
>> +
>> +static bool xilinx_mbox_last_tx_done(struct mbox_chan *chan)
>> +{
>> +   struct xilinx_mbox *mbox = mbox_chan_to_xilinx_mbox(chan);
>> +
>> +   /* return false if mailbox is full */
>> +   return !xilinx_mbox_full(mbox);
>>
> Instead of FULL, I think it should check for stricter EMPTY status ...
> mbox api submits only 1 message at a time.

The EMPTY status applies to the receive direction only, I could check
the STI status
bit though I suppose.

[...]
>> +
>> +   mbox->irq = platform_get_irq(pdev, 0);
>> +   /* if irq is present, we can use it, otherwise, poll */
>> +   if (mbox->irq > 0) {
>> +   mbox->controller.txdone_irq = true;
>> +   mbox->controller.ops = &xilinx_mbox_irq_ops;
>> +   } else {
>> +   dev_info(&pdev->dev, "IRQ not found, fallback to 
>> polling.\n");
>> +   mbox->controller.txdone_poll = true;
>> +   mbox->controller.txpoll_period = MBOX_POLLING_MS;
>> +   mbox->controller.ops = &xilinx_mbox_poll_ops;
>> +
>> +   setup_timer(&mbox->rxpoll_timer, xilinx_mbox_poll_rx,
>> +   (unsigned long)&mbox->chan);
>>
> I believe there is indeed some platform that doesn't have RX-Interrupt?
>  If no, please remove this.
>  If yes, you may want to get some hint from platform about the size of
> messages and do mbox_chan_received_data() only upon reading those many
> bytes.

I'd be fine to drop the polling use case for the moment, on my
platform I can wire up the IRQ.
We can always add it back in in a follow up use case.

Thanks,

Moritz
--
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 3/7] clk: Amlogic: Add reset controller for CPU cores for Meson8b

[Carlo Caione]

From: Carlo Caione 

In the Amlogic Meson8b SoC we need to soft reset the CPU cores during
the boot to enable the SMP support. With this patch we extend the clock
controller adding a small reset controller in charge of resetting the
cores.

Signed-off-by: Carlo Caione 
---
 drivers/clk/meson/clk-cpu.c  | 60 +++-
 drivers/clk/meson/clkc.c |  5 +--
 drivers/clk/meson/clkc.h |  6 ++--
 drivers/clk/meson/meson8b-clkc.c |  4 +--
 include/dt-bindings/clock/meson8b-clkc.h |  5 +++
 5 files changed, 73 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/meson/clk-cpu.c b/drivers/clk/meson/clk-cpu.c
index f7c30ea..8836fa9 100644
--- a/drivers/clk/meson/clk-cpu.c
+++ b/drivers/clk/meson/clk-cpu.c
@@ -37,9 +37,14 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define MESON_CPU_CLK_CNTL10x00
 #define MESON_CPU_CLK_CNTL 0x40
+#define MESON_CPU_CLK_CNTL_CPU 0x19c
+
+#define MESON_MAX_CPU_RST  4
 
 #define MESON_CPU_CLK_MUX1 BIT(7)
 #define MESON_CPU_CLK_MUX2 BIT(0)
@@ -51,6 +56,11 @@
 
 #include "clkc.h"
 
+struct meson_reset_cpu {
+   void __iomem*reset_base;
+   struct reset_controller_dev rcdev;
+};
+
 struct meson_clk_cpu {
struct notifier_block   clk_nb;
const struct clk_div_table  *div_table;
@@ -182,13 +192,50 @@ static const struct clk_ops meson_clk_cpu_ops = {
.set_rate   = meson_clk_cpu_set_rate,
 };
 
-struct clk *meson_clk_register_cpu(const struct clk_conf *clk_conf,
+static int meson_reset_cpu_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+   u32 reg;
+   struct meson_reset_cpu *reset_cpu = container_of(rcdev,
+struct meson_reset_cpu,
+rcdev);
+
+   reg = readl(reset_cpu->reset_base);
+   reg |= BIT(id + 24);
+   writel(reg, reset_cpu->reset_base);
+
+   return 0;
+}
+
+static int meson_reset_cpu_deassert(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   u32 reg;
+   struct meson_reset_cpu *reset_cpu = container_of(rcdev,
+struct meson_reset_cpu,
+rcdev);
+
+   reg = readl(reset_cpu->reset_base);
+   reg &= ~BIT(id + 24);
+   writel(reg, reset_cpu->reset_base);
+
+   return 0;
+}
+
+static struct reset_control_ops meson_cpu_reset_ops = {
+   .assert = meson_reset_cpu_assert,
+   .deassert   = meson_reset_cpu_deassert,
+};
+
+struct clk *meson_clk_register_cpu(struct device_node *np,
+  const struct clk_conf *clk_conf,
   void __iomem *reg_base,
   spinlock_t *lock)
 {
struct clk *clk;
struct clk *pclk;
struct meson_clk_cpu *clk_cpu;
+   struct meson_reset_cpu *reset_cpu;
struct clk_init_data init;
int ret;
 
@@ -231,6 +278,17 @@ struct clk *meson_clk_register_cpu(const struct clk_conf 
*clk_conf,
goto unregister_clk_nb;
}
 
+   reset_cpu = kzalloc(sizeof(*reset_cpu), GFP_KERNEL);
+   if (!reset_cpu)
+   goto out;
+
+   reset_cpu->reset_base = reg_base + MESON_CPU_CLK_CNTL_CPU;
+   reset_cpu->rcdev.nr_resets = MESON_MAX_CPU_RST;
+   reset_cpu->rcdev.ops = &meson_cpu_reset_ops;
+   reset_cpu->rcdev.of_node = np;
+   reset_controller_register(&reset_cpu->rcdev);
+
+out:
return clk;
 
 unregister_clk_nb:
diff --git a/drivers/clk/meson/clkc.c b/drivers/clk/meson/clkc.c
index c83ae13..df71e82 100644
--- a/drivers/clk/meson/clkc.c
+++ b/drivers/clk/meson/clkc.c
@@ -197,7 +197,8 @@ meson_clk_register_fixed_rate(const struct clk_conf 
*clk_conf,
return clk;
 }
 
-void __init meson_clk_register_clks(const struct clk_conf *clk_confs,
+void __init meson_clk_register_clks(struct device_node *np,
+   const struct clk_conf *clk_confs,
size_t nr_confs,
void __iomem *clk_base)
 {
@@ -221,7 +222,7 @@ void __init meson_clk_register_clks(const struct clk_conf 
*clk_confs,
   clk_base);
break;
case CLK_CPU:
-   clk = meson_clk_register_cpu(clk_conf, clk_base,
+   clk = meson_clk_register_cpu(np, clk_conf, clk_base,
 &clk_lock);
break;
case CLK_PLL:
diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
index 609ae92..648d41d 100644
--- a/drivers/clk/meson/clk

[PATCH v2 4/7] ARM: DTS: Amlogic: Enable reset controller for Meson8b

[Carlo Caione]

From: Carlo Caione 

Extend the CPU nodes to use the reset controller.

Signed-off-by: Carlo Caione 
---
 arch/arm/boot/dts/meson8b.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index b1990dc..51b32ed 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -60,6 +60,7 @@
compatible = "arm,cortex-a5";
next-level-cache = <&L2>;
reg = <0x200>;
+   resets = <&clkc RST_CORE0>;
};
 
cpu@201 {
@@ -67,6 +68,7 @@
compatible = "arm,cortex-a5";
next-level-cache = <&L2>;
reg = <0x201>;
+   resets = <&clkc RST_CORE1>;
};
 
cpu@202 {
@@ -74,6 +76,7 @@
compatible = "arm,cortex-a5";
next-level-cache = <&L2>;
reg = <0x202>;
+   resets = <&clkc RST_CORE2>;
};
 
cpu@203 {
@@ -81,6 +84,7 @@
compatible = "arm,cortex-a5";
next-level-cache = <&L2>;
reg = <0x203>;
+   resets = <&clkc RST_CORE3>;
};
};
 
@@ -147,6 +151,7 @@
};
 
clkc: clock-controller@c1104000 {
+   #reset-cells = <1>;
#clock-cells = <1>;
compatible = "amlogic,meson8b-clkc";
reg = <0xc1108000 0x4>, <0xc1104000 0x460>;
-- 
2.5.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 3/4] dmaengine: qcom_bam_dma: use correct pipe FIFO size

[Andy Gross]

On Wed, Dec 02, 2015 at 06:44:11PM +0200, Stanimir Varbanov wrote:
> On 12/01/2015 07:23 PM, Andy Gross wrote:
> > On Tue, Dec 01, 2015 at 11:14:58AM +0200, Stanimir Varbanov wrote:
> >> The pipe fifo size register must instruct the bam hw
> >> how many hw descriptors can be pushed to fifo. Currently
> >> we isntruct the hw with 32KBytes but wrap the tail in
> >> bam_start_dma in BAM_P_EVNT_REG on 4095 i.e. 32760. This
> >> leads to stalled transactions when the tail wraps.
> >>
> >> Fix this by use the correct fifo size in BAM_P_FIFO_SIZES
> >> register i.e. 32K - 8.
> >>
> >> Signed-off-by: Stanimir Varbanov 
> >> ---
> >>  drivers/dma/qcom_bam_dma.c |2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
> >> index 0f06f3b7a72b..6d290de9ab2b 100644
> >> --- a/drivers/dma/qcom_bam_dma.c
> >> +++ b/drivers/dma/qcom_bam_dma.c
> >> @@ -458,7 +458,7 @@ static void bam_chan_init_hw(struct bam_chan *bchan,
> >> */
> >>writel_relaxed(ALIGN(bchan->fifo_phys, sizeof(struct bam_desc_hw)),
> >>bam_addr(bdev, bchan->id, BAM_P_DESC_FIFO_ADDR));
> >> -  writel_relaxed(BAM_DESC_FIFO_SIZE,
> >> +  writel_relaxed(BAM_MAX_DATA_SIZE,
> >>bam_addr(bdev, bchan->id, BAM_P_FIFO_SIZES));
> > 
> > This is just using the #define.  That is ok, but if you use this instead of 
> > the
> > BAM_P_FIFO_SIZES then you need to fix your comment.  Or actually use the
> > register value otherwise looks fine.
> 
> I did not follow your comment, but the intension of the patch is to set
> the proper FIFO size in BAM_P_FIFO_SIZES register, i.e. 32K - 8.

Sorry, I mixed up the usage and was thinking there was something you read out
that told you the size.  That's not how it works, unfortunately.  The
MAX_DATA_SIZE is fine, but the name is a little misleading.  Perhaps just
BAM_FIFO_SIZE?


Regards,

Andy
--
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 6/7] ARM: Amlogic: Add SMP bringup code for Meson8b

[Carlo Caione]

From: Carlo Caione 

This adds the necessary SMP-operations and startup code to use the
additional cores on the Amlogic Meson8b SoCs.

Signed-off-by: Carlo Caione 
---
 arch/arm/Makefile |   1 +
 arch/arm/mach-meson/Kconfig   |   1 +
 arch/arm/mach-meson/Makefile  |   1 +
 arch/arm/mach-meson/platsmp.c | 234 ++
 4 files changed, 237 insertions(+)
 create mode 100644 arch/arm/mach-meson/platsmp.c

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 2c2b28e..ec0609a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -150,6 +150,7 @@ textofs-$(CONFIG_SA) := 0x00208000
 endif
 textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
 textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
+textofs-$(CONFIG_ARCH_MESON) := 0x00208000
 textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 
 # Machine directory name.  This list is sorted alphanumerically
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index 5d56f86..e171744 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -6,6 +6,7 @@ menuconfig ARCH_MESON
select CACHE_L2X0
select PINCTRL
select PINCTRL_MESON
+   select HAVE_ARM_SCU if SMP
 
 if ARCH_MESON
 
diff --git a/arch/arm/mach-meson/Makefile b/arch/arm/mach-meson/Makefile
index 9d7380e..bc26c85 100644
--- a/arch/arm/mach-meson/Makefile
+++ b/arch/arm/mach-meson/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_ARCH_MESON) += meson.o
+obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-meson/platsmp.c b/arch/arm/mach-meson/platsmp.c
new file mode 100644
index 000..1235830
--- /dev/null
+++ b/arch/arm/mach-meson/platsmp.c
@@ -0,0 +1,234 @@
+/*
+ * Copyright (C) 2015 Carlo Caione 
+ *
+ * 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, or
+ * (at your option) any later version.
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MESON_CPU_CTRL_REG (0x00)
+#define MESON_CPU_CTRL_ADDR_REG(c) (0x04 + ((c - 1) << 2))
+
+#define MESON_CPU_AO_RTI_PWR_A9_CNTL0  (0x00)
+#define MESON_CPU_AO_RTI_PWR_A9_CNTL1  (0x04)
+#define MESON_CPU_AO_RTI_PWR_A9_MEM_PD0(0x14)
+
+#define MESON_CPU_PWR_A9_CNTL0_M(c)(0x03 << ((c * 2) + 16))
+#define MESON_CPU_PWR_A9_CNTL1_M(c)(0x03 << ((c + 1) << 1))
+#define MESON_CPU_PWR_A9_MEM_PD0_M(c)  (0x0f << (32 - (c * 4)))
+#define MESON_CPU_PWR_A9_CNTL1_ST(c)   (0x01 << (c + 16))
+
+static void __iomem *sram_base;
+static void __iomem *scu_base;
+static struct regmap *pmu;
+
+static void __init meson8b_smp_prepare_cpus(unsigned int max_cpus)
+{
+   static struct device_node *node;
+
+   /* SMP SRAM */
+   node = of_find_compatible_node(NULL, NULL, "amlogic,meson8b-smp-sram");
+   if (!node) {
+   pr_err("Missing SRAM node\n");
+   return;
+   }
+
+   sram_base = of_iomap(node, 0);
+   if (!sram_base) {
+   pr_err("Couldn't map SRAM registers\n");
+   return;
+   }
+
+   /* PMU */
+   pmu = syscon_regmap_lookup_by_compatible("amlogic,meson8b-pmu");
+   if (IS_ERR(pmu)) {
+   pr_err("Couldn't map PMU registors\n");
+   return;
+   }
+
+   /* SCU */
+   node = of_find_compatible_node(NULL, NULL, "arm,cortex-a5-scu");
+   if (!node) {
+   pr_err("Missing SCU node\n");
+   return;
+   }
+
+   scu_base = of_iomap(node, 0);
+   if (!scu_base) {
+   pr_err("Couln't map SCU registers\n");
+   return;
+   }
+
+   scu_enable(scu_base);
+}
+
+static struct reset_control *meson_get_core_reset(int cpu)
+{
+   struct device_node *np;
+
+   np = of_get_cpu_node(cpu, 0);
+
+   return of_reset_control_get(np, NULL);
+}
+
+static int meson8b_set_cpu_power_ctrl(unsigned int cpu, bool is_power_on)
+{
+   struct reset_control *rstc;
+   int ret;
+   u32 val;
+
+   rstc = meson_get_core_reset(cpu);
+   if (IS_ERR(rstc)) {
+   pr_err("Couldn't get the reset controller\n");
+   return -EINVAL;
+   }
+
+   if (is_power_on) {
+
+   /* CPU power UP */
+   ret = regmap_update_bits(pmu, MESON_CPU_AO_RTI_PWR_A9_CNTL0,
+MESON_CPU_PWR_A9_CNTL0_M(cpu), 0);
+   if (ret < 0) {
+   pr_err("Couldn't power up the CPU\n");
+   return ret;
+   

[PATCH v2 7/7] ARM: DTS: Amlogic: Add SMP related nodes for Meson8b

[Carlo Caione]

From: Carlo Caione 

Add nodes for: SCU, PMU and SRAM. Set also the enable-method for SMP
bringup.

Signed-off-by: Carlo Caione 
---
 arch/arm/boot/dts/meson8b.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 51b32ed..27e1b2f 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -51,9 +51,20 @@
 / {
interrupt-parent = <&gic>;
 
+   scu@c430 {
+   compatible = "arm,cortex-a5-scu";
+   reg = <0xc430 0x100>;
+   };
+
+   pmu@c81000e4 {
+   compatible = "amlogic,meson8b-pmu", "syscon";
+   reg = <0xc81000e0 0x18>;
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "amlogic,meson8b-smp";
 
cpu@200 {
device_type = "cpu";
@@ -88,6 +99,19 @@
};
};
 
+   sram: sram@d900 {
+   compatible = "mmio-sram";
+   reg = <0xd900 0x2>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0xd900 0x2>;
+
+   smp-sram@1ff80 {
+   compatible = "amlogic,meson8b-smp-sram";
+   reg = <0x1ff80 0x8>;
+   };
+   };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
-- 
2.5.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

[PATCH v2 5/7] dt-bindings: Amlogic: Add SMP related documentation

[Carlo Caione]

From: Carlo Caione 

With this patch we add documentation for:

* power-management-unit: the PMU is used to bring up the cores during
  SMP operations
* sram: among other things the sram is used to store the first code
  executed by the core when it is powered up
* cpu-enable-method: the CPU enable method used by Amlogic Meson8b SoCs

Signed-off-by: Carlo Caione 
---
 .../devicetree/bindings/arm/amlogic/pmu.txt| 16 +++
 .../devicetree/bindings/arm/amlogic/smp-sram.txt   | 32 ++
 Documentation/devicetree/bindings/arm/cpus.txt |  1 +
 3 files changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic/pmu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt

diff --git a/Documentation/devicetree/bindings/arm/amlogic/pmu.txt 
b/Documentation/devicetree/bindings/arm/amlogic/pmu.txt
new file mode 100644
index 000..7b9b2da
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amlogic/pmu.txt
@@ -0,0 +1,16 @@
+Amlogic power-management-unit:
+---
+
+The pmu is used to turn off and on different power domains of the SoCs
+This includes the power to the CPU cores.
+
+Required node properties:
+- compatible value : = "amlogic,meson8b-pmu";
+- reg : physical base address and the size of the registers window
+
+Example:
+
+   pmu@c81000e4 {
+   compatible = "amlogic,meson8b-pmu", "syscon";
+   reg = <0xc81000e0 0x18>;
+   };
diff --git a/Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt 
b/Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt
new file mode 100644
index 000..455ca20
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt
@@ -0,0 +1,32 @@
+Amlogic SRAM for smp bringup:
+--
+
+Amlogic's smp-capable SoCs use part of the sram for the bringup of the cores.
+Once the core gets powered up it executes the code that is residing at a
+specific location.
+
+Therefore a reserved section sub-node has to be added to the mmio-sram
+declaration.
+
+Required sub-node properties:
+- compatible : should be "amlogic,meson8b-smp-sram"
+
+The rest of the properties should follow the generic mmio-sram discription
+found in ../../misc/sram.txt
+
+Example:
+
+   sram: sram@d900 {
+   compatible = "mmio-sram";
+   reg = <0xd900 0x2>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0xd900 0x2>;
+
+   smp-sram@1ff80 {
+   compatible = "amlogic,meson8b-smp-sram";
+   reg = <0x1ff80 0x8>;
+   };
+   };
+
+
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index 3a07a87..22381b4 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -189,6 +189,7 @@ nodes to be present and contain the properties described 
below.
  can be one of:
"allwinner,sun6i-a31"
"allwinner,sun8i-a23"
+   "amlogic,meson8b-smp"
"arm,psci"
"brcm,brahma-b15"
"marvell,armada-375-smp"
-- 
2.5.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

[PATCH v2 1/7] ARM: DTS: Amlogic: Extend L2 cache controller node for Meson8b

[Carlo Caione]

From: Carlo Caione 

This patch extends the L2 cache controller node for Amlogic Meson8b
SoCs with some missing parameters.

Signed-off-by: Carlo Caione 
---
 arch/arm/boot/dts/meson8b.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index ee352bf..b1990dc 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -93,6 +93,9 @@
L2: l2-cache-controller@c420 {
compatible = "arm,pl310-cache";
reg = <0xc420 0x1000>;
+   arm,data-latency = <3 3 3>;
+   arm,tag-latency = <2 2 2>;
+   arm,filter-ranges = <0x10 0xc000>;
cache-unified;
cache-level = <2>;
};
-- 
2.5.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

[PATCH v2 2/7] dt-bindings: Amlogic: Document the CPU reset controller for Meson8b

[Carlo Caione]

From: Carlo Caione 

The clock controller on Amlogic Meson8b SoCs has been extended with a
reset controller used to reset the CPU cores. It is used during SMP
bringup.

With this patch we extend the clock controller documentation.

Signed-off-by: Carlo Caione 
---
 Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt 
b/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt
index 2b7b3fa..feeb4de 100644
--- a/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt
+++ b/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt
@@ -1,7 +1,8 @@
 * Amlogic Meson8b Clock and Reset Unit
 
 The Amlogic Meson8b clock controller generates and supplies clock to various
-controllers within the SoC.
+controllers within the SoC and also implements a reset controller for the CPU
+cores.
 
 Required Properties:
 
@@ -13,16 +14,19 @@ Required Properties:
   mapped region.
 
 - #clock-cells: should be 1.
+- #reset-cells: should be 1.
 
 Each clock is assigned an identifier and client nodes can use this identifier
 to specify the clock which they consume. All available clocks are defined as
 preprocessor macros in the dt-bindings/clock/meson8b-clkc.h header and can be
 used in device tree sources.
+Similar identifiers exist for the CPU core reset lines.
 
 Example: Clock controller node:
 
clkc: clock-controller@c1104000 {
#clock-cells = <1>;
+   #reset-cells = <1>;
compatible = "amlogic,meson8b-clkc";
reg = <0xc1108000 0x4>, <0xc1104000 0x460>;
};
-- 
2.5.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

[PATCH v2 0/7] Add basic SMP support for Amlogic Meson8b

[Carlo Caione]

From: Carlo Caione 

This patchset adds SMP support for Amlogic Meson8b SoCs.

Patch 1 fix some paramater for L2 cache needed for SMP.
Patches 2-4 add a small reset controller used to reset the CPU cores at boot.
Patches 5-7 deal with the SMP code itself.

Changelog:

V2:
- Add forgotten textofs-$(CONFIG_ARCH_MESON)
- Checking for of_reset_control_get() failure
- Use more specific subjects

Carlo Caione (7):
  ARM: DTS: Amlogic: Extend L2 cache controller node for Meson8b
  dt-bindings: Amlogic: Document the CPU reset controller for Meson8b
  clk: Amlogic: Add reset controller for CPU cores for Meson8b
  ARM: DTS: Amlogic: Enable reset controller for Meson8b
  dt-bindings: Amlogic: Add SMP related documentation
  ARM: Amlogic: Add SMP bringup code for Meson8b
  ARM: DTS: Amlogic: Add SMP related nodes for Meson8b

 .../devicetree/bindings/arm/amlogic/pmu.txt|  16 ++
 .../devicetree/bindings/arm/amlogic/smp-sram.txt   |  32 +++
 Documentation/devicetree/bindings/arm/cpus.txt |   1 +
 .../bindings/clock/amlogic,meson8b-clkc.txt|   6 +-
 arch/arm/Makefile  |   1 +
 arch/arm/boot/dts/meson8b.dtsi |  32 +++
 arch/arm/mach-meson/Kconfig|   1 +
 arch/arm/mach-meson/Makefile   |   1 +
 arch/arm/mach-meson/platsmp.c  | 234 +
 drivers/clk/meson/clk-cpu.c|  60 +-
 drivers/clk/meson/clkc.c   |   5 +-
 drivers/clk/meson/clkc.h   |   6 +-
 drivers/clk/meson/meson8b-clkc.c   |   4 +-
 include/dt-bindings/clock/meson8b-clkc.h   |   5 +
 14 files changed, 396 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic/pmu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt
 create mode 100644 arch/arm/mach-meson/platsmp.c

-- 
2.5.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 v3 2/4] drm: Add support for ARM's HDLCD controller.

[Daniel Stone]

Hi Liviu,

On 2 December 2015 at 12:23, Liviu Dudau  wrote:
> +   if (irq_status & HDLCD_INTERRUPT_VSYNC) {
> +   unsigned long flags;
> +
> +   drm_handle_vblank(drm, 0);
> +
> +   spin_lock_irqsave(&drm->event_lock, flags);
> +   if (hdlcd->event) {
> +   drm_send_vblank_event(drm, hdlcd->event->pipe, 
> hdlcd->event);
> +   drm_crtc_vblank_put(&hdlcd->crtc);
> +   hdlcd->event = NULL;
> +   }
> +   spin_unlock_irqrestore(&drm->event_lock, flags);
> +   }

As with VC4 and Rockchip, you're missing a ->preclose handler in your
drm_drv, to make sure that you don't try to send events to a dead
client (which causes an OOPS):
https://git.collabora.com/cgit/user/daniels/linux.git/commit/?h=wip/4.4.x/rockchip-drm-fixes&id=d14f21bcd7
(and its parent)

Also, is there anything preventing clients from submitting multiple
pageflips before the event is sent? I couldn't see anything from a
quick look, so you could have the situation of:
  - client submits pageflip, event 1 stored to hdlcd->event
  - client submits pageflip, event 2 stored to hdlcd->event
  - vblank arrives, event 2 is sent
  - event 1 has disappeared and been leaked

Cheers,
Daniel
--
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