Re: [PATCH v7 0/8] Watchdog: introduce ARM SBSA watchdog driver

[Fu Wei]

Hi Pratyush,

Great thanks for your testing, this info is very helpful. :-)
my new patchset will come out soon.

On 30 September 2015 at 13:13, Pratyush Anand  wrote:
> Hi Fu Wei,
>
> On 25/08/2015:01:01:15 AM, fu@linaro.org wrote:
>> From: Fu Wei 
>>
>> This patchset:
>> (1)Introduce Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
>> for FDT info of SBSA Generic Watchdog, and give two examples of
>> adding SBSA Generic Watchdog device node into the dts files:
>> foundation-v8.dts and amd-seattle-soc.dtsi.
>>
>> (2)Introduce "pretimeout" into the watchdog framework, and update
>> Documentation/watchdog/watchdog-kernel-api.txt to introduce:
>> (1)the new elements in the watchdog_device and watchdog_ops struct;
>> (2)the new API "watchdog_init_timeouts".
>>
>> (3)Introduce ARM SBSA watchdog driver:
>> a.Use linux kernel watchdog framework;
>> b.Work with FDT on ARM64;
>> c.Use "pretimeout" in watchdog framework;
>> d.Support getting timeout and pretimeout from parameter and FDT
>>   at the driver init stage.
>> e.In the first timeout, do panic to save system context;
>> f.In the second stage, user can still feed the dog without
>>   cleaning WS0. By this feature, we can avoid the panic infinite
>>   loops, while backing up a large system context in a server.
>> g.In the second stage, can trigger WS1 by setting pretimeout = 0
>>   if necessary.
>>
>> (4)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
>> Parse SBSA Generic Watchdog Structure in GTDT table of ACPI,
>> and create a platform device with that information.
>> This platform device can be used by This Watchdog driver.
>> drivers/clocksource/arm_arch_timer.c is simplified by this GTDT support.
>>
>> This patchset has been tested with watchdog daemon
>> (ACPI/FDT, module/build-in) on the following platforms:
>> (1)ARM Foundation v8 model
>>
>
> I tested it with kdump on fedora-arm64 Seattle platform. I enabled watchdog
> using systemd (with 30s timeout), insured that watchdog is active and then
> crashed the system. I can see that kdump kernel loads sbsa_wdt and activates
> watchdog, still vmcore copy is done successfully.
> My test kernel is here [1]
>
> ~Pratyush
>
> [1] https://github.com/pratyushanand/linux/commits/wdt/sbsa-test-kexec



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
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: [alsa-devel] [PATCH 04/10] ASoC: img: Add driver for I2S output controller

[kbuild test robot]

Hi Damien.Horsley,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: sh-allyesconfig (attached as .config)
reproduce:
  wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  git checkout 5037c15dd47c86ab337b73c7f9ffcabe1bb86f3b
  # save the attached .config to linux build tree
  make.cross ARCH=sh 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   sound/soc/img/img-i2s-out.c: In function 'img_i2s_out_set_fmt':
>> sound/soc/img/img-i2s-out.c:108:2: warning: 'reg' may be used uninitialized 
>> in this function [-Wuninitialized]
   sound/soc/img/img-i2s-out.c:291:6: note: 'reg' was declared here

vim +/reg +108 sound/soc/img/img-i2s-out.c

92  }
93  
94  static inline void img_i2s_out_writel(struct img_i2s_out *i2s, u32 val,
95  u32 reg)
96  {
97  writel(val, i2s->base + reg);
98  }
99  
   100  static inline u32 img_i2s_out_readl(struct img_i2s_out *i2s, u32 reg)
   101  {
   102  return readl(i2s->base + reg);
   103  }
   104  
   105  static inline void img_i2s_out_ch_writel(struct img_i2s_out *i2s,
   106  u32 chan, u32 val, u32 reg)
   107  {
 > 108  writel(val, i2s->channel_base + (chan * IMG_I2S_OUT_CH_STRIDE) 
 > + reg);
   109  }
   110  
   111  static inline u32 img_i2s_out_ch_readl(struct img_i2s_out *i2s, u32 
chan,
   112  u32 reg)
   113  {
   114  return readl(i2s->channel_base + (chan * IMG_I2S_OUT_CH_STRIDE) 
+ reg);
   115  }
   116  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] ARM: shmobile: porter: initial device tree

[Sergei Shtylyov]

Hello.

On 09/30/2015 02:26 AM, Sergei Shtylyov wrote:


Add the initial device tree for the R8A7791 SoC based Porter low cost board
(which  is a  slightly modified version  of the Henninger board).

SCIF0 serial port support is included, so that the serial console can work.

Signed-off-by: Sergei Shtylyov 

---
This patch is against the 'renesas-devel-20150928-v4.3-rc3' tag of Simon
Horman's 'renesas.git' repo.


   Forgot to mention I had to disable USB-DMAC.


Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -0,0 +1,54 @@
+/*
+ * Device Tree Source for the Porter board
+ *
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "r8a7791.dtsi"
+
+/ {
+   model = "Porter";
+   compatible = "renesas,porter", "renesas,r8a7791";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   bootargs = "console=ttySC0,115200 ignore_loglevel";


   Oops, scratch that. I thought I removed console= but I forgot to refresh 
the patch. :-/


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

Re: [PATCH v2 1/4] clocksource: rockchip: Make the driver more compatible

[Heiko Stübner]

Hi Daniel,

Am Dienstag, 29. September 2015, 06:18:03 schrieb Daniel Lezcano:
> On 09/25/2015 04:14 AM, Caesar Wang wrote:
> > Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
> > There are some failure with build up on timer driver for rockchip.
> > 
> > Says:
> > /tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand 1 --
> > `dsb`
> > ...
> > 
> > The problem was different semantics of dsb on btw arm32 and arm64,
> > Here we can convert the dsb with insteading of dsb(sy).The "sy" param
> > is the default which you are allow to omit, so on arm32 dsb()and dsb(sy)
> > are the same.
> > 
> > Signed-off-by: Caesar Wang 
> 
> Acked-by: Daniel Lezcano 

as you have "just" Acked these patches, I guess you are expecting them to go 
through the same tree as the devicetree changes, right?

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

[linux-sunxi][PATCH v5] ARM: sun7i: dt: Add new Olimex A20 EVB device

[codekipper]

From: Marcus Cooper 

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

Signed-off-by: Marcus Cooper 
---
Changes since v4:
- removed reg_usb0_vbus which will return when usb otg is added.
Changes since v3:
- removed i2c1 as it's not used
- removed axp_ipsout regulator
Changes since v2:
- changed dcdc2 to have max voltage of 1.4V
Changes since v1:
- renamed dts from sun7i-a20-olinuxino-evb to sun7i-a20-olimex-som-evb
- added "axp209 dtsi"
- change regulator settings
---
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 198 +
 2 files changed, 199 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts

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

Re: [PATCH v2 4/6] tty: serial: msm: Add TX DMA support

[Mark Rutland]

On Wed, Sep 30, 2015 at 02:51:26PM +0100, Ivan T. Ivanov wrote:
> 
> On Wed, 2015-09-30 at 14:29 +0100, Mark Rutland wrote:
> > On Wed, Sep 30, 2015 at 01:08:24PM +0100, Ivan T. Ivanov wrote:
> > > Add transmit DMA support for UARTDM type of controllers.
> > > 
> > > Tested on APQ8064, which have UARTDM v1.3 and ADM DMA engine
> > > and APQ8016, which have UARTDM v1.4 and BAM DMA engine.
> > > 
> > > Signed-off-by: Ivan T. Ivanov iva...@linaro.org>
> > > ---
> > >  .../devicetree/bindings/serial/qcom,msm-uartdm.txt |   3 +
> > >  drivers/tty/serial/msm_serial.c| 312 
> > > +++--
> > >  drivers/tty/serial/msm_serial.h|   3 +
> > >  3 files changed, 294 insertions(+), 24 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt 
> > > b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
> > > index a2114c217376..a600023d9ec1 100644
> > > --- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
> > > +++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
> > > @@ -26,6 +26,9 @@ Required properties:
> > >  Optional properties:
> > >  - dmas: Should contain dma specifiers for transmit and receive channels
> > >  - dma-names: Should contain "tx" for transmit and "rx" for receive 
> > > channels
> > > +- qcom,tx-crci: Identificator  for Client Rate Control Interface to 
> > > be
> > > +   used with TX DMA channel. Required when using DMA for 
> > > transmission
> > > +   with UARTDM v1.3 and bellow.
> > 
> > This sounds like it belongs in the dma-specifier, and dealt with by the
> > DMA controller driver.
> > 
> > Why does the UART driver need to know about this?
> 
> CRCI information was part of the first version of ADM DMA engine driver
> bindings, but Andy remove it because some client devices are requiring
> more that one CRCI number. See here[1] and here [2].
> 
> Regards,
> Ivan
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314190.html
> [2] https://lkml.org/lkml/2015/8/19/19

This leaves me more confused. If different writes from the same agent
are being distinguished then it sounds like you actually have two
logical DMA channels.

Could you elaborate on the qcom,ebi2-nand binding? From a brief read I'd
expect you to have "txrx" and "cmd" dmas, rather than describing the
CRCI information on the side.

Mark.
--
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] arm64: dts: add all hi6220 uart nodes

[Tyler Baker]

On 30 September 2015 at 10:31, Mark Brown  wrote:
> On Wed, Sep 30, 2015 at 10:24:56AM +0200, Arnd Bergmann wrote:
>> On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
>
>> > aliases {
>> > serial0 = 
>> > +   serial1 = 
>> > +   serial2 = 
>> > +   serial3 = 
>> > +   serial4 = 
>> > };
>
>> In the changelog you mention "both uarts", but here you have five of them.
>> Are they all accessible on the connector? If not, only provide aliases
>> for the ones that are, using numbering that makes most sense for given
>> how one would use the board.

Thanks for the comment Arnd. Mark's comment below is correct, there
are only two UARTs accessible on the LS connection in addition to the
one on the board (solder pad).

Is the following definition any clearer?

serial0 =  // Onboard UART0
serial1 =  // LS expansion UART0
serial2 =  // LS expansion UART1

If so, I'll respin this patch.

> Unless I'm missing something there's only two UARTs brought out on the
> low speed expansion connector (in addition to the one on the solder pads
> which is currently supported).  We should also adjust the console
> default to match whatever one of the low speed expansion connector UARTs
> is being used by the bootloader.

Your not missing anything, I should not have added the additional
aliases, it is confusing, will remove. The UART boards by default come
configured to use UART1 on the LS connector.

+ Peter as he has been submitting u-boot patches recently for the HiKey.

Obviously, both UEFI and u-boot can be configured to use either UART,
and at the moment u-boot defaults to using the on board UART. Whereas
UEFI is using UART1 on the LS connector. I'm fine with switching the
console default to use the UART1 on the LS connector as long as there
is agreement to do so.

> While we're at it there was a recent talk which mentioned a fairly large
> amount of functionality that's apparently already "upstream" for this
> device but not included in the DT, assuming that means that driver
> support is there it would be good to add the corresponding DT.

Indeed, I think this comment is targeted to toward the d410c though as
there are drivers for eMMC, and microsd drivers upstream but no DT
bindings. I do not believe currently this is the case for HiKey.

Cheers,

Tyler
--
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] arm64: dts: add all hi6220 uart nodes

[Mark Brown]

On Wed, Sep 30, 2015 at 10:24:56AM +0200, Arnd Bergmann wrote:
> On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:

> > aliases {
> > serial0 = 
> > +   serial1 = 
> > +   serial2 = 
> > +   serial3 = 
> > +   serial4 = 
> > };

> In the changelog you mention "both uarts", but here you have five of them.
> Are they all accessible on the connector? If not, only provide aliases
> for the ones that are, using numbering that makes most sense for given
> how one would use the board.

Unless I'm missing something there's only two UARTs brought out on the
low speed expansion connector (in addition to the one on the solder pads
which is currently supported).  We should also adjust the console
default to match whatever one of the low speed expansion connector UARTs
is being used by the bootloader.

While we're at it there was a recent talk which mentioned a fairly large
amount of functionality that's apparently already "upstream" for this
device but not included in the DT, assuming that means that driver
support is there it would be good to add the corresponding DT.


signature.asc
Description: Digital signature

Re: [PATCH v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC

[Mark Brown]

On Tue, Sep 29, 2015 at 01:58:41PM -0500, Andrew F. Davis wrote:
> On 09/29/2015 01:38 PM, Mark Brown wrote:

> >Oh, ick.  The binding has a compatible string in the individual
> >regulator bindings which is broken unless there really are lots of
> >variants being configured via DT (which is just not the case here).
> >It's not only more typing in the DT,

> I don't see this, the alternative is matching to this "regulator-compatible",
> why not just use the existing compatible.

No, you don't need to use regulator-compatible - that's deprecated.
Just use the node names.

> >it also means that we can't read
> >back the configuration of the device unless the user goes and creates a
> >DT which explicitly lists each regulator on the device which is
> >unhelpful.  We should be able to read back the configurations of all the
> >regulators by simply listing the device in DT.

> Could you expand this? I'm not sure I understand why we still cant do this
> using this new way.

I'm not sure what there is to add...  if the regulator is only
instantiated when it features in the device tree then obviously it must
be included in the device to be instantiated.

> Bindings should have compatible strings when they describe hardware like this,
> we can then do stuff like put the LDO and DCDC drivers in separate modules for
> instance, letting DT only load what we need. There are other benefits like
> not having to search our own DT binding for data, and we only get probed for
> devices in the DT.

Only getting probed for device is in DT is exactly the problem here, and
nothing prevents us having separate modules for things without
enumerating everything in DT.

> This also eliminates the need for MFD_CORE, we just call
> of_platform_populate on ourself and DT helpers do the rest. Why hard code
> mfd_cell's and do matching when DT does the same thing.

Putting everything in DT means more work for people integrating the
device and means that we have to have a full and complete understanding
of the device at the time we write the DT, including decions about how
we split the functionality of the device between subsystems.

> >The fact that this is different to the bindings for other regulator
> >drivers and requires more code ought to have been a big warning sign
> >here :(

> The binding is the same as the new tps65218 driver, different isn't always
> a warning sign. And what do you mean "requires more code"? This regulator
> driver is smaller than almost any other. DT takes care of everything for
> us relating to hardware instantiation like it should.

That's not a new driver, it's from more than a year ago (before or about
the same time the helpers got added IIRC).


signature.asc
Description: Digital signature

Re: [PATCH v5 2/4] Documentation: arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

Hi Ben,

On Wed, Sep 30, 2015 at 4:23 PM, Mark Rutland  wrote:
> On Tue, Sep 29, 2015 at 09:38:04AM +0100, Ganapatrao Kulkarni wrote:
>> (sending again, by mistake it was set to html mode)
>>
>> On Tue, Sep 29, 2015 at 2:05 PM, Ganapatrao Kulkarni
>>  wrote:
>> > Hi Mark,
>> >
>> > I have tried to answer your comments, in the meantime we are waiting for 
>> > Ben
>> > to share the details.
>> >
>> > On Fri, Aug 28, 2015 at 6:02 PM, Mark Rutland  wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Fri, Aug 14, 2015 at 05:39:32PM +0100, Ganapatrao Kulkarni wrote:
>> >> > DT bindings for numa map for memory, cores and IOs using
>> >> > arm,associativity device node property.
>> >>
>> >> Given this is just a copy of ibm,associativity, I'm not sure I see much
>> >> point in renaming the properties.
>> >>
>> >> However, (somewhat counter to that) I'm also concerned that this isn't
>> >> sufficient for systems we're beginning to see today (more on that
>> >> below), so I don't think a simple copy of ibm,associativity is good
>> >> enough.
>> >
>> > it is just copy right now, however it can evolve when we come across more
>> > arm64 numa platforms
>
> Whatever we do I suspect we'll have to evolve it as new platforms
> appear. As I mentioned there are contemporary NUMA ARM64 platforms (e.g.
> those with CCN) that I don't think we can ignore now given we'll have to
> cater for them.
>
>> >> > +==
>> >> > +2 - arm,associativity
>> >> >
>> >> > +==
>> >> > +The mapping is done using arm,associativity device property.
>> >> > +this property needs to be present in every device node which needs to
>> >> > to be
>> >> > +mapped to numa nodes.
>> >>
>> >> Can't there be some inheritance? e.g. all devices on a bus with an
>> >> arm,associativity property being assumed to share that value?
>> >
>> > yes there is inheritance and respective bus drivers should take care of it,
>> > like pci driver does at present.
>
> Ok.
>
> That seems counter to my initial interpretation of the wording that the
> property must be present on device nodes that need to be mapped to NUMA
> nodes.
>
> Is there any simple way of describing the set of nodes that need this
> property?
>
>> >> > +topology and boundary in the system at which a significant difference
>> >> > in
>> >> > +performance can be measured between cross-device accesses within
>> >> > +a single location and those spanning multiple locations.
>> >> > +The first cell always contains the broadest subdivision within the
>> >> > system,
>> >> > +while the last cell enumerates the individual devices, such as an SMT
>> >> > thread
>> >> > +of a CPU, or a bus bridge within an SoC".
>> >>
>> >> While this gives us some hierarchy, this doesn't seem to encode relative
>> >> distances at all. That seems like an oversight.
>> >
>> >
>> > distance is computed, will add the details to document.
>> > local nodes will have distance as 10(LOCAL_DISTANCE) and every level, the
>> > distance multiplies by 2.
>> > for example, for level 1 numa topology, distance from local node to remote
>> > node will be 20.
>
> This seems arbitrary.
>
> Why not always have this explicitly described?
>
>> >> Additionally, I'm somewhat unclear on how what you'd be expected to
>> >> provide for this property in cases like ring or mesh interconnects,
>> >> where there isn't a strict hierarchy (see systems with ARM's own CCN, or
>> >> Tilera's TILE-Mx), but there is some measure of closeness.
>> >
>> >
>> > IIUC, as per ARMs CCN architecture, all core/clusters are at equal distance
>> > of DDR, i dont see any NUMA topology.
>
> The CCN is a ring interconnect, so CPU clusters (henceforth CPUs) can be
> connected with differing distances to RAM instances (or devices).
>
> Consider the simplified network below:
>
>   +---+  ++  +---+
>   | CPU 0 |--| DRAM A |--| CPU 1 |
>   +---+  ++  +---+
>   |  |
>   |  |
>   ++ ++
>   | DRAM B | | DRAM C |
>   ++ ++
>   |  |
>   |  |
>   +---+  ++  +---+
>   | CPU 2 |--| DRAM D |--| CPU 3 |
>   +---+  ++  +---+
>
> In this case CPUs and DRAMs are spaced evenly on the ring, but the
> distance between an arbitrary CPU and DRAM is not uniform.
>
> CPU 0 can access DRAM A or DRAM B with a single hop, but accesses to
> DRAM C or DRAM D take three hops.
>
> An access from CPU 0 to DRAM C could contend with accesses from CPU 1 to
> DRAM D, as they share hops on the ring.
>
> There is definitely a NUMA topology here, but there's not a strict
> hierarchy. I don't see 

Re: [alsa-devel] [PATCH 04/10] ASoC: img: Add driver for I2S output controller

[kbuild test robot]

Hi Damien.Horsley,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: blackfin-allmodconfig (attached as .config)
reproduce:
  wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  git checkout 5037c15dd47c86ab337b73c7f9ffcabe1bb86f3b
  # save the attached .config to linux build tree
  make.cross ARCH=blackfin 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   sound/soc/img/img-i2s-out.c: In function 'img_i2s_out_set_fmt':
>> include/asm-generic/io.h:163:2: warning: 'reg' may be used uninitialized in 
>> this function [-Wuninitialized]
   sound/soc/img/img-i2s-out.c:291:6: note: 'reg' was declared here

vim +/reg +163 include/asm-generic/io.h

9216efaf Thierry Reding 2014-10-01  147 __raw_writeb(value, addr);
3f7e212d Arnd Bergmann  2009-05-13  148  }
9216efaf Thierry Reding 2014-10-01  149  #endif
3f7e212d Arnd Bergmann  2009-05-13  150  
9216efaf Thierry Reding 2014-10-01  151  #ifndef writew
9216efaf Thierry Reding 2014-10-01  152  #define writew writew
9216efaf Thierry Reding 2014-10-01  153  static inline void writew(u16 value, 
volatile void __iomem *addr)
3f7e212d Arnd Bergmann  2009-05-13  154  {
9216efaf Thierry Reding 2014-10-01  155 
__raw_writew(cpu_to_le16(value), addr);
3f7e212d Arnd Bergmann  2009-05-13  156  }
9216efaf Thierry Reding 2014-10-01  157  #endif
3f7e212d Arnd Bergmann  2009-05-13  158  
9216efaf Thierry Reding 2014-10-01  159  #ifndef writel
9216efaf Thierry Reding 2014-10-01  160  #define writel writel
9216efaf Thierry Reding 2014-10-01  161  static inline void writel(u32 value, 
volatile void __iomem *addr)
3f7e212d Arnd Bergmann  2009-05-13  162  {
9216efaf Thierry Reding 2014-10-01 @163 
__raw_writel(__cpu_to_le32(value), addr);
3f7e212d Arnd Bergmann  2009-05-13  164  }
9216efaf Thierry Reding 2014-10-01  165  #endif
3f7e212d Arnd Bergmann  2009-05-13  166  
9216efaf Thierry Reding 2014-10-01  167  #ifdef CONFIG_64BIT
9216efaf Thierry Reding 2014-10-01  168  #ifndef writeq
9216efaf Thierry Reding 2014-10-01  169  #define writeq writeq
9216efaf Thierry Reding 2014-10-01  170  static inline void writeq(u64 value, 
volatile void __iomem *addr)
3f7e212d Arnd Bergmann  2009-05-13  171  {

:: The code at line 163 was first introduced by commit
:: 9216efafc52ff99e9351ef60de5fcafc2bc8adb6 asm-generic/io.h: Reconcile I/O 
accessor overrides

:: TO: Thierry Reding 
:: CC: Thierry Reding 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] arm64: dts: add all hi6220 uart nodes

[Mark Brown]

On Wed, Sep 30, 2015 at 11:12:58AM -0700, Tyler Baker wrote:
> On 30 September 2015 at 10:31, Mark Brown  wrote:

> + Peter as he has been submitting u-boot patches recently for the HiKey.

> Obviously, both UEFI and u-boot can be configured to use either UART,
> and at the moment u-boot defaults to using the on board UART. Whereas
> UEFI is using UART1 on the LS connector. I'm fine with switching the
> console default to use the UART1 on the LS connector as long as there
> is agreement to do so.

Given that UEFI is switching and the requirement for soldering to get to
the on board UART it does seem to make sense, though it will create some
pain for current users.

> > While we're at it there was a recent talk which mentioned a fairly large
> > amount of functionality that's apparently already "upstream" for this
> > device but not included in the DT, assuming that means that driver
> > support is there it would be good to add the corresponding DT.

> Indeed, I think this comment is targeted to toward the d410c though as
> there are drivers for eMMC, and microsd drivers upstream but no DT
> bindings. I do not believe currently this is the case for HiKey.

My understanding is that it applies to both with slightly different
driver sets, the slides aren't online yet (!) but if you look at 10:52
or so in the video we should have SD/eMMC on HiKey in v4.1 with thermal
and CPUfreq added in v4.2.  It also looks like there's just some DT
additions needed to enable reset, cpuidle and CPU hotplug using generic
code (mainly the constants for PSCI I expect).


signature.asc
Description: Digital signature

Re: [PATCH 1/8] dt-bindings: pmic: Document Hi655x pmic driver

[Mark Brown]

On Wed, Sep 30, 2015 at 07:05:04PM +0800, Fei Wang wrote:

> +Hisilicon hi655x Power Management Integrated Circuit (PMIC)
> +
> +hi655x consists of a large and varied group of sub-devices:
> +
> +DeviceSupply NamesDescription
> +-----
> +hi655x-powerkey  :   : Powerkey
> +hi655x-regulator-pmic:   : Regulators
> +hi655x-usbvbus   :   : USB plug detection
> +hi655x-pmu-rtc   :   : RTC
> +hi655x-coul  :   : Coulomb

...counter?

There's no documentation of the bindings for any of the above devices or
how things are structured, you need to provide binding documentation
which is understandable standalone.  None of the properties are
documented, nor is the set of regulators supported or how this is
structured.

> +coul: coul@1 {
> +compatible = "hisilicon,hi655x-coul";
> +interrupt-parent = <>;
> +interrupts = <24 0>, <25 0>, <26 0>, <27 0>;
> +interrupt-names = "cl_int_i", "cl_out_i", "cl_in_i", 
> "vbat_int_i";
> +battery_product_index = <0>;

For example, the "battery_product_index" property here is undocumented.


signature.asc
Description: Digital signature

Re: [PATCH 4/8] regulator: Hi655x: Add support for Hi655x regulator

[Mark Brown]

On Wed, Sep 30, 2015 at 07:05:07PM +0800, Fei Wang wrote:

> +config REGULATOR_HI655X
> +tristate "Hisilicon HI655X PMIC regulators support"
> +depends on ARCH_HISI
> + depends on MFD_HI655X_PMIC && OF

You've got some tab/space confusion above.  Also, can't we have an ||
COMPILE_TEST here?

> +#define REG_VALUE_SETBITS(reg_value, pos, bits, bits_value) \
> + (reg_value = (reg_value & \
> + ~unsigned int)1 << bits) - 1) << pos)) | \
> + ((unsigned int)(bits_value & \
> + (((unsigned int)1 << bits) - 1)) << pos))
> +
> +#define REG_VALUE_GETBITS(reg_value, pos, bits) \
> + ((reg_value >> pos) & (((unsigned int)1 << bits) - 1))

These are just really hard to read, sorry, and they appear to duplicate
existing regmap functionality.  If there is a strong reason to add them
consider doing so in the core and if you can then please at least make
them regular inline functions rather than using macros.  It's much safer
and more readable.

> +static int hi655x_regulator_pmic_is_enabled(struct regulator_dev *rdev)
> +{
> + int ret = 0;
> + unsigned int value = 0;
> +
> + struct hi655x_regulator *sreg = rdev_get_drvdata(rdev);
> + struct hi655x_regulator_ctrl_regs  *ctrl_regs = &(sreg->ctrl_regs);
> + struct hi655x_regulator_ctrl_data  *ctrl_data = &(sreg->ctrl_data);
> +
> + /*
> + * regulator is all set,but the pmu is only subset.
> + * maybe this "buck"/"ldo"/"lvs" is not contrl by a core.
> + * and in regulator have a "status" member ("okey" or "disable").
> + */

I'm having a hard time parsing the above comment.  Please also use the
normal kernel comment style (this is a problem throughout the driver).

> + regmap_read(rdev->regmap, ctrl_regs->status_reg, );
> + ret = (int)REG_VALUE_GETBITS(value, ctrl_data->shift,
> + ctrl_data->mask);

This appears to just duplicate regulator core functionality for reading
enable state from a bitfield?  Also note that the cast here isn't a
great advert for the macros above.

> +static int hi655x_regulator_pmic_enable(struct regulator_dev *rdev)
> +{
> + int ret = 0;
> + unsigned char value_u8 = 0;
> + unsigned int value_u32 = 0;
> + struct hi655x_regulator *sreg = rdev_get_drvdata(rdev);
> + struct hi655x_regulator_ctrl_regs  *ctrl_regs = &(sreg->ctrl_regs);
> + struct hi655x_regulator_ctrl_data  *ctrl_data = &(sreg->ctrl_data);
> +
> + REG_VALUE_SETBITS(value_u32, ctrl_data->shift, ctrl_data->mask, 0x1);
> + value_u8  = (unsigned char)value_u32;
> + regmap_write(rdev->regmap, ctrl_regs->enable_reg, value_u8);

I'm not *entirely* sure what this is supposed to be doing but it looks
like it's duplicating core functionality in a fashion that's really
quite hard to read.  Why not just use the core functions for setting
bits?

> + udelay(sreg->off_on_delay);

Use the regualtor core delay functionality please.

> +static int hi655x_regulator_pmic_list_voltage_linear(struct regulator_dev 
> *rdev,
> +   unsigned int selector)

This is *definitely* duplicating core functionality, I think you want to
use regulator_list_voltage_linear_range() or possibly just plain
_linear() and use separate operations for the LVS regulator.

We at least need to restructure the code so that the core helper
functions are used and we don't have regulator type decisions everywhere
- the whole goal of having per regulator ops is to avoid having to open
code decisions about which regulator we're dealing with into each op
function.

> +static unsigned int hi655x_regulator_pmic_get_mode(
> + struct regulator_dev *rdev)
> +{
> + return REGULATOR_MODE_NORMAL;
> +}

Don't implement empty functions, remove all these.

> + num_consumer_supplies = of_get_property(np,
> + "hisilicon,num_consumer_supplies", NULL);
> +
> + if ((NULL == num_consumer_supplies) || (0 == *num_consumer_supplies)) {
> + dev_warn(dev, "%s no consumer_supplies\n", __func__);
> + return init_data;
> + }

Obviously the binding is completely undocumented but this is setting off
alarm bells - why is the driver even considering consumers?  Please make
sure you are using the core regulator bindings rather than open coding
something which translates into platform data (which is what this looks
like).

I'm not going to review any more of the DT code without binding
documentation.

> + /*
> + *initdata mem will release auto;
> + *this is kernel 3.10 import.
> + */

Remove anything related to your vendor kernel support, this is not
relevant to upstream.


signature.asc
Description: Digital signature

Re: [PATCH] arm64: dts: add all hi6220 uart nodes

[Rob Herring]

On Wed, Sep 30, 2015 at 1:12 PM, Tyler Baker  wrote:
> On 30 September 2015 at 10:31, Mark Brown  wrote:
>> On Wed, Sep 30, 2015 at 10:24:56AM +0200, Arnd Bergmann wrote:
>>> On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
>>
>>> > aliases {
>>> > serial0 = 
>>> > +   serial1 = 
>>> > +   serial2 = 
>>> > +   serial3 = 
>>> > +   serial4 = 
>>> > };
>>
>>> In the changelog you mention "both uarts", but here you have five of them.
>>> Are they all accessible on the connector? If not, only provide aliases
>>> for the ones that are, using numbering that makes most sense for given
>>> how one would use the board.
>
> Thanks for the comment Arnd. Mark's comment below is correct, there
> are only two UARTs accessible on the LS connection in addition to the
> one on the board (solder pad).
>
> Is the following definition any clearer?
>
> serial0 =  // Onboard UART0
> serial1 =  // LS expansion UART0
> serial2 =  // LS expansion UART1

Yes, but use C style comments.

What about the BT UART?

>
> If so, I'll respin this patch.
>
>> Unless I'm missing something there's only two UARTs brought out on the
>> low speed expansion connector (in addition to the one on the solder pads
>> which is currently supported).  We should also adjust the console
>> default to match whatever one of the low speed expansion connector UARTs
>> is being used by the bootloader.
>
> Your not missing anything, I should not have added the additional
> aliases, it is confusing, will remove. The UART boards by default come
> configured to use UART1 on the LS connector.

Also, the console default should be set in chosen stdout-path so we
can move away from having to set it on the kernel command line. Then
the aliases don't matter so much, but there may be some work to do to
setup a getty correctly.

> + Peter as he has been submitting u-boot patches recently for the HiKey.
>
> Obviously, both UEFI and u-boot can be configured to use either UART,
> and at the moment u-boot defaults to using the on board UART. Whereas
> UEFI is using UART1 on the LS connector. I'm fine with switching the
> console default to use the UART1 on the LS connector as long as there
> is agreement to do so.

BTW, u-boot can output to multiple serial ports. I think I gave Peter
details on how to do it.

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 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

Hi Vladimir,

On Wed, Sep 23, 2015 at 09:31:12PM +0300, Vladimir Zapolskiy wrote:
> Hi Sascha,
> 
> in case of OF_DYNAMIC enabled of_parse_phandle() requires of_node_put(),
> which is fine to place right here.
> 
> > +   if (auxadc_phys_base == OF_BAD_ADDR) {
> > +   dev_err(>dev, "Can't get auxadc phys address\n");
> > +   return -EINVAL;
> > +   }
> > +
> 
> [snip]
> 
> > +
> > +   /*
> > +* These calibration values should finally be provided by the
> > +* firmware or fuses. For now use default values.
> > +*/
> > +   mt->calib_slope = -123;
> > +   mt->calib_offset = 465124;
> > +
> > +   for (i = 0; i < MT8173_NUM_ZONES; i++)
> > +   mtk_thermal_init_bank(mt, i, apmixed_phys_base, 
> > auxadc_phys_base);
> > +
> > +   platform_set_drvdata(pdev, mt);
> > +
> > +   for (i = 0; i < MT8173_NUM_ZONES; i++) {
> > +   struct mtk_thermal_bank *bank = >banks[i];
> > +
> > +   bank->tzd = thermal_zone_of_sensor_register(>dev, i, bank,
> > +   _thermal_ops);
> 
> I would propose to add return value checks here, otherwise there might
> be an oops in mtk_thermal_remove(), if something goes wrong.

Thanks for the input. I'll fix that in the next round.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v3 0/5] usb: change clock information for chipidea

[Peter Chen]

On Wed, Sep 30, 2015 at 01:28:36PM +0800, Shawn Guo wrote:
> On Wed, Sep 30, 2015 at 10:25:20AM +0800, Peter Chen wrote:
> > This patch set changes usb clock information for legacy i.mx platforms.
> > At these platforms, they needs three clocks to let controller work.
> > 
> > Hi Shawn,
> > 
> > Fabio has tested for both imx27 and imx25 platforms.
> > I have queued 1/5 and 5/5, would you please help to queue others,
> > thanks.
> > 
> > Changes for v3:
> > - Delete property "needs-three-clocks", and using of_device_id->data
> >   to differentiate platforms
> > - change  #v3.19+ to  #v4.1+
> 
> So the last patch will be sent as a fix with stable on copy?

Yes

> In that
> case, will USB driver just work without corresponding DTS change?  Or
> the driver change has a dependency on the DTS change?
> 

At v4.1, One of USB driver changes break i.mx27's USB function.
The driver's change at patch 5/5 is also tagged for stable tree,
so it needs both DTS and driver's change to let i.mx27 USB work from
v4.1.

-- 

Best Regards,
Peter Chen
--
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 support to make output voltage determined by VSET2[] bits

[Wenyou Yang]

The patch is to add support to make the output voltage of ACT8865
DC/DC regulator determined by VSET2[] bits. The DT property
"active-semi,vsel-high" is used to specify the VSEL pin at high
on the board. When the VSEL pin is high, output voltage is programmed
by VSET2[] bits.


Wenyou Yang (2):
  regulator: act8865: support output voltage by VSET2[] bits
  regulator: act8865: add DT binding for property
"active-semi,vsel-high"

 .../bindings/regulator/act8865-regulator.txt   |3 +++
 drivers/regulator/act8865-regulator.c  |   24 ++--
 2 files changed, 25 insertions(+), 2 deletions(-)

-- 
1.7.9.5

--
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: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

Hello Krzysztof,

On 09/30/2015 02:30 AM, Krzysztof Kozlowski wrote:

[snip]

>>
>> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
>> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
>> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
>>
>> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
>> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
>> and Rev5 searches for "google,snow-rev5". That way the compatible string
>> could be consistent with the DTS naming and still be able to pack both Rev4
>> and Rev5 FDT in the same FIT image and let the firmware pick the correct FDT.
>>
>>  arch/arm/boot/dts/Makefile|   1 +
>>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
>> ++
>>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>>  arch/arm/boot/dts/exynos5250-snow.dts | 666 
>> +
>>  4 files changed, 733 insertions(+), 665 deletions(-)
>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
> 
> Now the exynos5250-snow.dts means in fact Rev4... but there is no
> information in DTS about it. I think adding compatible
> "google,snow-rev4" makes sense:
> 1. For informational purposes (this could be also handled with a comment).
> 2. Later one could decide to switch the default meaning of "google,snow"
> to Rev5 and the real compatible (rev4) will be there already.
>

Ok, I explained my rationale about why I did not add a "google,snow-rev4"
but I don't have a strong opinion on this so I'll add it on v2.
 
> Could you add the new compatible and fix patch issues pointed by Doug?
>

Sure.

> Best regards,
> Krzysztof
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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: shmobile: porter: initial device tree

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Sep 30, 2015 at 1:26 AM, Sergei Shtylyov
 wrote:
> Add the initial device tree for the R8A7791 SoC based Porter low cost board
> (which  is a  slightly modified version  of the Henninger board).

Can you please tell us more about the differences?
It will help us reviewing future DTS updates.

> Signed-off-by: Sergei Shtylyov 

If you update Documentation/devicetree/bindings/arm/shmobile.txt, you can
add my
Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: Add Exynos5250 Snow Rev5+ support

[Krzysztof Kozlowski]

On 30.09.2015 15:58, Kukjin Kim wrote:
> On 09/30/15 09:30, Krzysztof Kozlowski wrote:
>> On 29.09.2015 20:57, Javier Martinez Canillas wrote:
>>> There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
>>> Rev4 and Rev5. The only difference between these 2 revisions is the codec,
>>> Rev4 has a max98095 codec while Rev5 has a max98090.
>>>
>>> Mainline only supports Rev4 so this patch moves the common device nodes to
>>> a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.
>>>
>>> The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.
>>>
>>> Signed-off-by: Javier Martinez Canillas 
>>>
>>> ---
>>>
>>> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
>>> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
>>> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
>>>
>>> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
>>> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
>>> and Rev5 searches for "google,snow-rev5". That way the compatible string
>>> could be consistent with the DTS naming and still be able to pack both Rev4
>>> and Rev5 FDT in the same FIT image and let the firmware pick the correct 
>>> FDT.
>>>
>>>  arch/arm/boot/dts/Makefile|   1 +
>>>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
>>> ++
>>>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>>>  arch/arm/boot/dts/exynos5250-snow.dts | 666 
>>> +
>>>  4 files changed, 733 insertions(+), 665 deletions(-)
>>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
>>
>> Now the exynos5250-snow.dts means in fact Rev4... but there is no
>> information in DTS about it. I think adding compatible
>> "google,snow-rev4" makes sense:
>> 1. For informational purposes (this could be also handled with a comment).
>> 2. Later one could decide to switch the default meaning of "google,snow"
>> to Rev5 and the real compatible (rev4) will be there already.
>>
>> Could you add the new compatible and fix patch issues pointed by Doug?
>>
> Documenting for the compatibles would be required even I already applied
> its updated patch...

What do you mean by "documenting compatibles"? These are board
compatibles, they are not documented...

Best regards,
Krzysztof

--
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] dmaengine: xgene-dma: Fix overwritting DMA tx ring

[Vinod Koul]

On Wed, Sep 16, 2015 at 01:33:23PM +0530, Rameshwar Prasad Sahu wrote:
> This patch fixes an over flow issue with the TX ring descriptor. Each
> descriptor is 32B in size and an operation requires 2 of these
> descriptors.

Applied, thanks

-- 
~Vinod
--
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] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

Hi Eduardo,

On Tue, Sep 29, 2015 at 04:04:40PM -0700, Eduardo Valentin wrote:
> On Wed, Sep 23, 2015 at 03:37:42PM +0200, Sascha Hauer wrote:
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> You dont seam to be using this header. Can you please clean up to have
> only the headers you need?

Ok, did that.

> > +   struct mtk_thermal *mt = bank->mt;
> > +   int temp, i, max;
> > +   u32 raw;
> > +
> > +   temp = max = INT_MIN;
> > +
> > +   for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
> > +   raw = readl(mt->thermal_base + sensing_points[i].msr);
> > +
> > +   temp = raw_to_mcelsius(mt, raw);
> > +
> > +   /*
> > +* The first read of a sensor often contains very high bogus
> > +* temperature value. Filter these out so that the system does
> > +* not immediately shut down.
> > +*/
> > +   if (temp > 20)
> 
> Ok... How about after the first read?  is > 20 a valid (supported) value 
> range?

No, temperatures over 200°C are not supported for this SoC.

> > +
> > +   mt->dev = >dev;
> > +
> > +   auxadc = of_parse_phandle(np, "mediatek,auxadc", 0);
> of_put?

added

> > +   if (!auxadc) {
> > +   dev_err(>dev, "missing auxadc node\n");
> > +   return -ENODEV;
> > +   }
> > +
> > +   auxadc_phys_base = of_get_phys_base(auxadc);
> > +   if (auxadc_phys_base == OF_BAD_ADDR) {
> > +   dev_err(>dev, "Can't get auxadc phys address\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   apmixedsys = of_parse_phandle(np, "mediatek,apmixedsys", 0);
> > +   if (!apmixedsys) {
> > +   dev_err(>dev, "missing apmixedsys node\n");
> > +   return -ENODEV;
> > +   }

For this one aswell.

> > +   /*
> > +* These calibration values should finally be provided by the
> > +* firmware or fuses. For now use default values.
> > +*/
> > +   mt->calib_slope = -123;
> > +   mt->calib_offset = 465124;
> 
> I would still prefer that this driver would not have these hardcoded
> values. Specially considering the fact that we could map it in DT for
> instance. What is the impact of using this? Does it work across all chip
> distribution?

I think yes, but not that accurate.

> 
> Should we wait until you have the code to read the fuses before merging
> this?

I'd say we should merge this. It makes the life easier for the guys
writing the cpufreq driver. Adding a dependency on a not yet written
driver IMO only adds unnecessary delays.

> 
> > +
> > +   for (i = 0; i < MT8173_NUM_ZONES; i++)
> > +   mtk_thermal_init_bank(mt, i, apmixed_phys_base, 
> > auxadc_phys_base);
> > +
> > +   platform_set_drvdata(pdev, mt);
> > +
> > +   for (i = 0; i < MT8173_NUM_ZONES; i++) {
> > +   struct mtk_thermal_bank *bank = >banks[i];
> > +
> > +   bank->tzd = thermal_zone_of_sensor_register(>dev, i, bank,
> > +   _thermal_ops);
> 
> You need to error handle this.

Errors here are pretty much expected. This is due to the behaviour of
thermal_zone_of_sensor_register which errors out when no user for a
sensor is found. Normally I would expect that I can register a sensor
regardless if it is used or not, but that's not how
thermal_zone_of_sensor_register is written.

I could catch -EPROBE_DEFER here, but currently I see no case where this
can actually be returned from thermal_zone_of_sensor_register.

What I can and should do though is to call
thermal_zone_of_sensor_unregister only for sensors that are successfully
registered.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

Hello Doug,

On 09/29/2015 07:28 PM, Doug Anderson wrote:

[snip]

> 
> 
>>  arch/arm/boot/dts/Makefile|   1 +
>>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
>> ++
>>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>>  arch/arm/boot/dts/exynos5250-snow.dts | 666 
>> +
>>  4 files changed, 733 insertions(+), 665 deletions(-)
> 
> Thanks!  Note:
> 
> $ pwclient git-am 7285451
> Applying patch #7285451 using 'git am'
> Description: ARM: dts: Add Exynos5250 Snow Rev5+ support
> Applying: ARM: dts: Add Exynos5250 Snow Rev5+ support
> .git/rebase-apply/patch:774: new blank line at EOF.
> +
> warning: 1 line adds whitespace errors.
>

sigh, sorry for missing that one.
 
> 
> One other nit is that the exynos5250-snow.dts" ends up with the
> "max98095" pinctrl properties sorted differently than the
> "exynos5250-snow-rev5.dts".  Is it worth reordering the
> "exynos5250-snow.dts" in the same patch?
>

Right, I'll change exynos5250-snow.dts to have pinctrl-names
before pinctrl-0 that will not only match max98090 properties
order but also be consistent with the rest of the dev nodes.
 
> Otherwise this looks fine to me.
> 
> Reviewed-by: Douglas Anderson 
> 

Thanks a lot for your feedback and review!

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 v5 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

[Shawn Guo]

On Tue, Sep 01, 2015 at 06:06:53PM +0530, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
> 
> Signed-off-by: Sanchayan Maity 

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

[PATCH v2 0/3] regulator: axp20x: Drop AXP221 DC1SW/DC5LDO supplies from bindings

[Chen-Yu Tsai]

Hi everyone,

This is v2 of "regulators: axp20x: Rename AXP221 DC1SW and DC5LDO supply
names". v2 removes the regulator supply properties for AXP221 DC1SW
and DC5LDO, instead of renaming them. These 2 regulators are secondary
outputs for DCDC1 and DCDC5 buck regulators, respectively, so they are
connected to them internally. This relationship should not be represented
in the device tree.


Patch 1 drops the AXP22X DC1SW/DC5LDO supply properties from the axp20x
DT bindings.

Patch 2 updates the axp20x regulator driver.

Patch 3 updates the only dts, the Hummingbird A31, that uses these
bindings.

If everything's ok, could we merge this for 4.4?

Thanks.


Regards,
ChenYu


Chen-Yu Tsai (3):
  mfd: axp20x: Drop AXP221 DC1SW and DC5LDO regulator supplies from
bindings
  regulator: axp20x: set supply names for AXP22X DC1SW/DC5LDO internally
  ARM: dts: sun6i: hummingbird: Drop AXP221 DC1SW and DC5LDO supplies

 Documentation/devicetree/bindings/mfd/axp20x.txt |  4 +-
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts  |  2 -
 drivers/regulator/axp20x-regulator.c | 54 ++--
 3 files changed, 52 insertions(+), 8 deletions(-)

-- 
2.5.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 v2 2/3] regulator: axp20x: set supply names for AXP22X DC1SW/DC5LDO internally

[Chen-Yu Tsai]

The DC1SW and DC5LDO regulators in the AXP22X are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property.

Since they are internally connected, the relationship should not be
represented in the device tree, but handled internally by the driver.

This patch has the driver remember the regulator names for the parent
DCDC1/DCDC5, and use them as supply names for DC1SW/DC5LDO.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/regulator/axp20x-regulator.c | 54 +---
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index a9567af7cec0..35de22fdb7a0 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -196,10 +196,10 @@ static const struct regulator_desc axp22x_regulators[] = {
AXP_DESC(AXP22X, DCDC5, "dcdc5", "vin5", 1000, 2550, 50,
 AXP22X_DCDC5_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(5)),
/* secondary switchable output of DCDC1 */
-   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", "dcdc1", 1600, 3400, 100,
+   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", NULL, 1600, 3400, 100,
AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(7)),
/* LDO regulator internally chained to DCDC5 */
-   AXP_DESC(AXP22X, DC5LDO, "dc5ldo", "dcdc5", 700, 1400, 100,
+   AXP_DESC(AXP22X, DC5LDO, "dc5ldo", NULL, 700, 1400, 100,
 AXP22X_DC5LDO_V_OUT, 0x7, AXP22X_PWR_OUT_CTRL1, BIT(0)),
AXP_DESC(AXP22X, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
 AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(6)),
@@ -350,6 +350,8 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
};
int ret, i, nregulators;
u32 workmode;
+   const char *axp22x_dc1_name = axp22x_regulators[AXP22X_DCDC1].name;
+   const char *axp22x_dc5_name = axp22x_regulators[AXP22X_DCDC5].name;
 
switch (axp20x->variant) {
case AXP202_ID:
@@ -371,8 +373,37 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
axp20x_regulator_parse_dt(pdev);
 
for (i = 0; i < nregulators; i++) {
-   rdev = devm_regulator_register(>dev, [i],
-  );
+   const struct regulator_desc *desc = [i];
+   struct regulator_desc *new_desc;
+
+   /*
+* Regulators DC1SW and DC5LDO are connected internally,
+* so we have to handle their supply names separately.
+*
+* We always register the regulators in proper sequence,
+* so the supply names are correctly read. See the last
+* part of this loop to see where we save the DT defined
+* name.
+*/
+   if (regulators == axp22x_regulators) {
+   if (i == AXP22X_DC1SW) {
+   new_desc = devm_kzalloc(>dev,
+   sizeof(*desc),
+   GFP_KERNEL);
+   *new_desc = regulators[i];
+   new_desc->supply_name = axp22x_dc1_name;
+   desc = new_desc;
+   } else if (i == AXP22X_DC5LDO) {
+   new_desc = devm_kzalloc(>dev,
+   sizeof(*desc),
+   GFP_KERNEL);
+   *new_desc = regulators[i];
+   new_desc->supply_name = axp22x_dc5_name;
+   desc = new_desc;
+   }
+   }
+
+   rdev = devm_regulator_register(>dev, desc, );
if (IS_ERR(rdev)) {
dev_err(>dev, "Failed to register %s\n",
regulators[i].name);
@@ -388,6 +419,21 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
dev_err(>dev, "Failed to set workmode on 
%s\n",
rdev->desc->name);
}
+
+   /*
+* Save AXP22X DCDC1 / DCDC5 regulator names for later.
+*/
+   if (regulators == axp22x_regulators) {
+   /* Can we use rdev->constraints->name instead? */
+   if (i == AXP22X_DCDC1)
+   of_property_read_string(rdev->dev.of_node,
+   "regulator-name",
+   _dc1_name);
+   else if (i == AXP22X_DCDC5)
+   

[PATCH v2 3/3] ARM: dts: sun6i: hummingbird: Drop AXP221 DC1SW and DC5LDO supplies

[Chen-Yu Tsai]

"dcdc1-supply" and "dcdc5-supply" have been dropped, as they are
internally connected and should not be represented in the device
tree.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts 
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 06d9391ca30e..f93cf4c42a7a 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -178,8 +178,6 @@
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <1>;
-   dcdc1-supply = <_3v0>;
-   dcdc5-supply = <_dram>;
 
regulators {
x-powers,dcdc-freq = <3000>;
-- 
2.5.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 2/2] regulator: act8865: add DT binding for property "active-semi,vsel-high"

[Wenyou Yang]

Add a DT property "active-semi,vsel-high" to indicate the VSEL pin
is high. If this property is missing, then assume the VSEL pin is
low(0).

Signed-off-by: Wenyou Yang 
---

 .../bindings/regulator/act8865-regulator.txt   |3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt 
b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
index e91485d..6067d98 100644
--- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
@@ -8,6 +8,8 @@ Required properties:
 Optional properties:
 - system-power-controller: Telling whether or not this pmic is controlling
   the system power. See 
Documentation/devicetree/bindings/power/power-controller.txt .
+- active-semi,vsel-high: Indicates the VSEL pin is high.
+  If this property is missing, assume the VSEL pin is low(0).
 
 Optional input supply properties:
 - for act8600:
@@ -49,6 +51,7 @@ Example:
pmic: act8865@5b {
compatible = "active-semi,act8865";
reg = <0x5b>;
+   active-semi,vsel-high;
status = "disabled";
 
regulators {
-- 
1.7.9.5

--
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] regulator: act8865: support output voltage by VSET2[] bits

[Wenyou Yang]

For the step-down DC/DC regulators, the output voltage is
selectable by setting VSEL pin that when VSEL is low, output
voltage is programmed by VSET1[] bits, and when VSEL is high,
output voltage is programmed by VSET2[] bits.

The DT property "active-semi,vsel-high" is used to specify
the VSEL pin at high on the board.

Signed-off-by: Wenyou Yang 
---

 drivers/regulator/act8865-regulator.c |   24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/act8865-regulator.c 
b/drivers/regulator/act8865-regulator.c
index 896db16..e2b50f3 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -261,6 +261,16 @@ static const struct regulator_desc act8865_regulators[] = {
ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET, "inl67"),
 };
 
+static const struct regulator_desc act8865_alt_regulators[] = {
+   ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET2),
+   ACT88xx_REG("DCDC_REG2", ACT8865, DCDC2, VSET2),
+   ACT88xx_REG("DCDC_REG3", ACT8865, DCDC3, VSET2),
+   ACT88xx_REG("LDO_REG1", ACT8865, LDO1, VSET),
+   ACT88xx_REG("LDO_REG2", ACT8865, LDO2, VSET),
+   ACT88xx_REG("LDO_REG3", ACT8865, LDO3, VSET),
+   ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET),
+};
+
 #ifdef CONFIG_OF
 static const struct of_device_id act8865_dt_ids[] = {
{ .compatible = "active-semi,act8600", .data = (void *)ACT8600 },
@@ -413,6 +423,7 @@ static int act8865_pmic_probe(struct i2c_client *client,
struct act8865 *act8865;
unsigned long type;
int off_reg, off_mask;
+   int voltage_select;
 
pdata = dev_get_platdata(dev);
 
@@ -424,6 +435,10 @@ static int act8865_pmic_probe(struct i2c_client *client,
return -ENODEV;
 
type = (unsigned long) id->data;
+
+   voltage_select = !!of_get_property(dev->of_node,
+  "active-semi,vsel-high",
+  NULL);
} else {
type = i2c_id->driver_data;
}
@@ -442,8 +457,13 @@ static int act8865_pmic_probe(struct i2c_client *client,
off_mask = ACT8846_OFF_SYSMASK;
break;
case ACT8865:
-   regulators = act8865_regulators;
-   num_regulators = ARRAY_SIZE(act8865_regulators);
+   if (voltage_select) {
+   regulators = act8865_alt_regulators;
+   num_regulators = ARRAY_SIZE(act8865_alt_regulators);
+   } else {
+   regulators = act8865_regulators;
+   num_regulators = ARRAY_SIZE(act8865_regulators);
+   }
off_reg = ACT8865_SYS_CTRL;
off_mask = ACT8865_MSTROFF;
break;
-- 
1.7.9.5

--
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/3] mfd: axp20x: Drop AXP221 DC1SW and DC5LDO regulator supplies from bindings

[Chen-Yu Tsai]

The DC1SW and DC5LDO regulators in the AXP221 are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property. This causes
some confusion when we actually use it in the dts:

axp221 {
/* self supplying? */
dcdc1-supply = <>;
dcdc5-supply = <>;

dcdc1: dcdc1 {
...
};

dcdc5: dcdc5 {
...
};
};

Since they are internally connected within the PMIC, their relationships
should not be visible in the device tree.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 41811223e5be..a474359dd206 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -60,8 +60,8 @@ DCDC2 : DC-DC buck: vin2-supply
 DCDC3  : DC-DC buck: vin3-supply
 DCDC4  : DC-DC buck: vin4-supply
 DCDC5  : DC-DC buck: vin5-supply
-DC1SW  : On/Off Switch : dcdc1-supply  : DCDC1 secondary output
-DC5LDO : LDO   : dcdc5-supply  : input from DCDC5
+DC1SW  : On/Off Switch :   : DCDC1 secondary output
+DC5LDO : LDO   :   : input from DCDC5
 ALDO1  : LDO   : aldoin-supply : shared supply
 ALDO2  : LDO   : aldoin-supply : shared supply
 ALDO3  : LDO   : aldoin-supply : shared supply
-- 
2.5.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] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Kukjin Kim]

On 09/30/15 09:30, Krzysztof Kozlowski wrote:
> On 29.09.2015 20:57, Javier Martinez Canillas wrote:
>> There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
>> Rev4 and Rev5. The only difference between these 2 revisions is the codec,
>> Rev4 has a max98095 codec while Rev5 has a max98090.
>>
>> Mainline only supports Rev4 so this patch moves the common device nodes to
>> a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.
>>
>> The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
>> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
>> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
>>
>> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
>> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
>> and Rev5 searches for "google,snow-rev5". That way the compatible string
>> could be consistent with the DTS naming and still be able to pack both Rev4
>> and Rev5 FDT in the same FIT image and let the firmware pick the correct FDT.
>>
>>  arch/arm/boot/dts/Makefile|   1 +
>>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
>> ++
>>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>>  arch/arm/boot/dts/exynos5250-snow.dts | 666 
>> +
>>  4 files changed, 733 insertions(+), 665 deletions(-)
>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
> 
> Now the exynos5250-snow.dts means in fact Rev4... but there is no
> information in DTS about it. I think adding compatible
> "google,snow-rev4" makes sense:
> 1. For informational purposes (this could be also handled with a comment).
> 2. Later one could decide to switch the default meaning of "google,snow"
> to Rev5 and the real compatible (rev4) will be there already.
> 
> Could you add the new compatible and fix patch issues pointed by Doug?
> 
Documenting for the compatibles would be required even I already applied
its updated patch...

- Kukjin
--
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: Add Exynos5250 Snow Rev5+ support

[Krzysztof Kozlowski]

On 30.09.2015 16:06, Javier Martinez Canillas wrote:
> Hello,
> 
> On 09/30/2015 09:02 AM, Krzysztof Kozlowski wrote:
>> On 30.09.2015 15:58, Kukjin Kim wrote:
> 
> [snip]
> 

 Could you add the new compatible and fix patch issues pointed by Doug?

>>> Documenting for the compatibles would be required even I already applied
>>> its updated patch...
>>
> 
> Kukjin, I agree that they should be documented but I thought it would
> be a separate patch since currently we don't document any board.
>  
>> What do you mean by "documenting compatibles"? These are board
>> compatibles, they are not documented...
>>
> 
> Krzysztof, I've on my TODO list to add a file describing all Exynos
> platforms and DT bindings, something like what other SoC do, i.e:
> 
> Documentation/devicetree/bindings/arm/omap/omap.txt
> Documentation/devicetree/bindings/arm/rockchip.txt

Right, that's a good idea. However lack of it does not affect current
work because compatibles for Exynos board are not documented at all.

Best regards,
Krzysztof

--
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] arm64: dts: add all hi6220 uart nodes

[Arnd Bergmann]

On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
> aliases {
> serial0 = 
> +   serial1 = 
> +   serial2 = 
> +   serial3 = 
> +   serial4 = 
> };
> 

In the changelog you mention "both uarts", but here you have five of them.
Are they all accessible on the connector? If not, only provide aliases
for the ones that are, using numbering that makes most sense for given
how one would use the board.

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

[PATCH 1/2] i2c: at91: add DT property for the HOLD field of TWIHS_CWGR

[Ludovic Desroches]

From: Wenyou Yang 

Add the HOLD field setting in order to support I2C slave devices which need
a longer hold time of the data.
Since it depends on the slave devices connected to the bus, add a DT
property "atmel,twd-hold-cycles" to specify this HOLD field.

Signed-off-by: Wenyou Yang 
Signed-off-by: Ludovic Desroches 
---
 drivers/i2c/busses/i2c-at91.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 1c758cd..06e66ef 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -64,6 +64,7 @@
 #defineAT91_TWI_IADR   0x000c  /* Internal Address Register */
 
 #defineAT91_TWI_CWGR   0x0010  /* Clock Waveform Generator Reg 
*/
+#defineAT91_TWI_CWGR_HOLD(x)   (((x) & 0x1f) << 24)
 
 #defineAT91_TWI_SR 0x0020  /* Status Register */
 #defineAT91_TWI_TXCOMP BIT(0)  /* Transmission Complete */
@@ -185,7 +186,8 @@ static void at91_init_twi_bus(struct at91_twi_dev *dev)
  * Calculate symmetric clock as stated in datasheet:
  * twi_clk = F_MAIN / (2 * (cdiv * (1 << ckdiv) + offset))
  */
-static void at91_calc_twi_clock(struct at91_twi_dev *dev, int twi_clk)
+static void at91_calc_twi_clock(struct at91_twi_dev *dev,
+   int twi_clk, u32 twd_hold)
 {
int ckdiv, cdiv, div;
struct at91_twi_pdata *pdata = dev->pdata;
@@ -204,7 +206,9 @@ static void at91_calc_twi_clock(struct at91_twi_dev *dev, 
int twi_clk)
cdiv = 255;
}
 
-   dev->twi_cwgr_reg = (ckdiv << 16) | (cdiv << 8) | cdiv;
+   dev->twi_cwgr_reg = (ckdiv << 16) | (cdiv << 8) | cdiv
+   | AT91_TWI_CWGR_HOLD(twd_hold);
+
dev_dbg(dev->dev, "cdiv %d ckdiv %d\n", cdiv, ckdiv);
 }
 
@@ -936,6 +940,7 @@ static int at91_twi_probe(struct platform_device *pdev)
int rc;
u32 phy_addr;
u32 bus_clk_rate;
+   u32 twd_hold_cycles;
 
dev = devm_kzalloc(>dev, sizeof(*dev), GFP_KERNEL);
if (!dev)
@@ -992,7 +997,12 @@ static int at91_twi_probe(struct platform_device *pdev)
if (rc)
bus_clk_rate = DEFAULT_TWI_CLK_HZ;
 
-   at91_calc_twi_clock(dev, bus_clk_rate);
+   rc = of_property_read_u32(dev->dev->of_node,
+ "atmel,twd-hold-cycles", _hold_cycles);
+   if (rc)
+   twd_hold_cycles = 0;
+
+   at91_calc_twi_clock(dev, bus_clk_rate, twd_hold_cycles);
at91_init_twi_bus(dev);
 
snprintf(dev->adapter.name, sizeof(dev->adapter.name), "AT91");
-- 
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 v7 0/2] pwm: Add support for R-Car PWM Timer

[Yoshihiro Shimoda]

This patch set is based on the latest linux-pwm.git / for-next branch.
(commit id = a83a6a82250fe900be85c8e142f5cb504d9482bd)

Changes from v6:
 - Modify rcar_pwm_set_counter() to be readable code.
 - Add a condition not to call rcar_pwm_set_clock_control() in rcar_pwm_config.
 - Remove chip.of_xlate setting to use of_pwm_simple_xlate().

Changes from v5:
 - Fix coding style and unreadable code in patch 2.
 - Add "Reviewed-by: Simon Horman ".

Changes from v4:
 - Clean up coding style and typo in patch 2.
 - Change to_rcar_pwm_chip() macro to static inline function in patch 2.
 - Use writel()/readl() instead of iowrite32()/ioread32() in patch 2.
 - Add an error handling in rcar_pwm_config() to avoid silent in patch 2.
 - Remove success message in rcar_pwm_probe() in patch 2.
 - Change rcar_pwm_remove() to always call pm_runtime_disable() in patch 2.

Changes from v3:
 - Fix register size in patch 1.
 - Add "Acked-by: Geert Uytterhoeven " in patch 1
 - Remove an unnecessary definition in patch 2.
 - Use "ULL" to avoid overflow in patch 2.
 - Remove unnecessary casts in patch 2.

Changes from v2:
 - Add compatible string "renesas,pwm-rcar".
 - Remove compatible strings "renesas,pwm-r8a77xx" in rcar_pwm_of_table.
 - Fix build error.

Changes from v1:
 - Change compatible string to SoC-specific compatible values.
 - Fix #pwm-call value to 2 in the device tree document.
 - Fix "depends on" value in Kconfig.
 - Fix help explanation in Kconfig.
 - Remove an unnecessary member in rcar_pwm_chip.
 - Remove hardcoded number of channels and change chip.npwm value to 1.
 - Fix formulas for clock calculation to improve accuracy.

Yoshihiro Shimoda (2):
  pwm: Add device tree binding document for R-Car PWM Timer
  pwm: Add support for R-Car PWM Timer

 .../devicetree/bindings/pwm/renesas,pwm-rcar.txt   |  27 +++
 drivers/pwm/Kconfig|  11 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-rcar.c | 266 +
 4 files changed, 305 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
 create mode 100644 drivers/pwm/pwm-rcar.c

-- 
1.9.1

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

[PATCH v7 1/2] pwm: Add device tree binding document for R-Car PWM Timer

[Yoshihiro Shimoda]

Add binding document for Renesas PWM Timer on R-Car SoCs.

Signed-off-by: Yoshihiro Shimoda 
Acked-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
---
 .../devicetree/bindings/pwm/renesas,pwm-rcar.txt   | 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt

diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt 
b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
new file mode 100644
index 000..ea0a27b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
@@ -0,0 +1,27 @@
+* Renesas R-Car PWM Timer Controller
+
+Required Properties:
+- compatible: should be one of the following.
+ - "renesas,pwm-rcar": for generic R-Car compatible PWM Timer
+ - "renesas,pwm-r8a7778": for R-Car M1A
+ - "renesas,pwm-r8a7779": for R-Car H1
+ - "renesas,pwm-r8a7790": for R-Car H2
+ - "renesas,pwm-r8a7791": for R-Car M2-W
+ - "renesas,pwm-r8a7794": for R-Car E2
+- reg: base address and length of the registers block for the PWM.
+- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
+  the cells format.
+- clocks: clock phandle and specifier pair.
+- pinctrl-0: phandle, referring to a default pin configuration node.
+- pinctrl-names: Set to "default".
+
+Example: R8A7790 (R-Car H2) PWM Timer node
+
+   pwm0: pwm@e6e3 {
+   compatible = "renesas,pwm-r8a7790", "renesas,pwm-rcar";
+   reg = <0 0xe6e3 0 0x8>;
+   #pwm-cells = <2>;
+   clocks = <_clks R8A7790_CLK_PWM>;
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   };
-- 
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 v7 2/2] pwm: Add support for R-Car PWM Timer

[Yoshihiro Shimoda]

This patch adds support for R-Car SoCs PWM Timer. The PWM timer of
R-Car H2 has 7 channels. So, we can use the channels if we describe
device tree nodes.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
---
 drivers/pwm/Kconfig|  11 ++
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-rcar.c | 266 +
 3 files changed, 278 insertions(+)
 create mode 100644 drivers/pwm/pwm-rcar.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 062630a..5dac49f 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -268,6 +268,17 @@ config PWM_PXA
  To compile this driver as a module, choose M here: the module
  will be called pwm-pxa.
 
+config PWM_RCAR
+   tristate "Renesas R-Car PWM support"
+   depends on ARCH_RCAR_GEN1 || ARCH_RCAR_GEN2 || COMPILE_TEST
+   depends on HAS_IOMEM
+   help
+ This driver exposes the PWM Timer controller found in Renesas
+ R-Car chips through the PWM API.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-rcar.
+
 config PWM_RENESAS_TPU
tristate "Renesas TPU PWM support"
depends on ARCH_SHMOBILE || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index a0e00c0..9107d65 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
 obj-$(CONFIG_PWM_PCA9685)  += pwm-pca9685.o
 obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
 obj-$(CONFIG_PWM_PXA)  += pwm-pxa.o
+obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
 obj-$(CONFIG_PWM_RENESAS_TPU)  += pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
 obj-$(CONFIG_PWM_SAMSUNG)  += pwm-samsung.o
diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
new file mode 100644
index 000..b641701
--- /dev/null
+++ b/drivers/pwm/pwm-rcar.c
@@ -0,0 +1,266 @@
+/*
+ * R-Car PWM Timer driver
+ *
+ * Copyright (C) 2015 Renesas Electronics Corporation
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RCAR_PWM_MAX_DIVISION  24
+#define RCAR_PWM_MAX_CYCLE 1023
+
+#define RCAR_PWMCR 0x00
+#define RCAR_PWMCNT0x04
+
+#define RCAR_PWMCR_CC0_MASK0x000f
+#define RCAR_PWMCR_CC0_SHIFT   16
+#define RCAR_PWMCR_CCMDBIT(15)
+#define RCAR_PWMCR_SYNCBIT(11)
+#define RCAR_PWMCR_SS0 BIT(4)
+#define RCAR_PWMCR_EN0 BIT(0)
+
+#define RCAR_PWMCNT_CYC0_MASK  0x03ff
+#define RCAR_PWMCNT_CYC0_SHIFT 16
+#define RCAR_PWMCNT_PH0_MASK   0x03ff
+#define RCAR_PWMCNT_PH0_SHIFT  0
+
+struct rcar_pwm_chip {
+   struct pwm_chip chip;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static inline struct rcar_pwm_chip *to_rcar_pwm_chip(struct pwm_chip *chip)
+{
+   return container_of(chip, struct rcar_pwm_chip, chip);
+}
+
+static void rcar_pwm_write(struct rcar_pwm_chip *rp, u32 data, u32 reg)
+{
+   writel(data, rp->base + reg);
+}
+
+static u32 rcar_pwm_read(struct rcar_pwm_chip *rp, u32 reg)
+{
+   return readl(rp->base + reg);
+}
+
+static void rcar_pwm_bit_modify(struct rcar_pwm_chip *rp, u32 mask, u32 data,
+   u32 reg)
+{
+   u32 val = rcar_pwm_read(rp, reg);
+
+   val &= ~mask;
+   val |= data & mask;
+   rcar_pwm_write(rp, val, reg);
+}
+
+static int rcar_pwm_get_clock_division(struct rcar_pwm_chip *rp, int period_ns)
+{
+   unsigned int div;
+   unsigned long clk_rate = clk_get_rate(rp->clk);
+   unsigned long long max; /* max cycle / nanoseconds */
+
+   if (clk_rate == 0)
+   return -EINVAL;
+
+   for (div = 0; div <= RCAR_PWM_MAX_DIVISION; div++) {
+   max = (unsigned long long)NSEC_PER_SEC * RCAR_PWM_MAX_CYCLE *
+   (1 << div);
+   do_div(max, clk_rate);
+   if (period_ns < max)
+   break;
+   }
+
+   return (div <= RCAR_PWM_MAX_DIVISION) ? div : -ERANGE;
+}
+
+static void rcar_pwm_set_clock_control(struct rcar_pwm_chip *rp, int div)
+{
+   u32 val = rcar_pwm_read(rp, RCAR_PWMCR);
+
+   val &= ~(RCAR_PWMCR_CCMD | RCAR_PWMCR_CC0_MASK);
+   if (div & 1)
+   val |= RCAR_PWMCR_CCMD;
+   div >>= 1;
+   val |= div << RCAR_PWMCR_CC0_SHIFT;
+   rcar_pwm_write(rp, val, RCAR_PWMCR);
+}
+
+static int rcar_pwm_set_counter(struct rcar_pwm_chip *rp, int div, int duty_ns,
+   int period_ns)
+{
+   unsigned long long one_cycle, tmp;  /* 0.01 nanoseconds */
+   unsigned long clk_rate = clk_get_rate(rp->clk);
+   u32 cyc, ph;
+
+ 

[PATCH 2/2] i2c: at91: update documentation for new "atmel,twd-hold-cycles" property

[Ludovic Desroches]

From: Wenyou Yang 

Add a DT property "atmel,twd-hold-cycles" to specify the HOLD
field of TWIHS_CWGR register to increase the TWD hold time.

Signed-off-by: Wenyou Yang 
Signed-off-by: Ludovic Desroches 
---
 Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt 
b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
index 6e81dc1..f14c0b2 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
@@ -17,6 +17,8 @@ Optional properties:
 - dma-names: should contain "tx" and "rx".
 - atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for 
FIFO
   capable I2C controllers.
+- atmel,twd-hold-cycles: increase the TWD hold time by
+  (atmel,twd-hold-cycles + 3) x t_periperal_clk, maximum value is 0x1f.
 - Child nodes conforming to i2c bus binding
 
 Examples :
@@ -29,6 +31,7 @@ i2c0: i2c@fff84000 {
#size-cells = <0>;
clocks = <_clk>;
clock-frequency = <40>;
+   atmel,twd-hold-cycles = <2>;
 
24c512@50 {
compatible = "24c512";
-- 
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 1/2] regulator: act8865: support output voltage by VSET2[] bits

[kbuild test robot]

Hi Wenyou,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: i386-randconfig-r0-201539 (attached as .config)
reproduce:
  git checkout 2470179cdcc3b8eebdb6abd5aecbbe6e2804fb33
  # save the attached .config to linux build tree
  make ARCH=i386 

All error/warnings (new ones prefixed by >>):

>> drivers/regulator/act8865-regulator.c:265:48: error: macro "ACT88xx_REG" 
>> requires 5 arguments, but only 4 given
 ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET2),
   ^
>> drivers/regulator/act8865-regulator.c:265:2: error: 'ACT88xx_REG' undeclared 
>> here (not in a function)
 ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET2),
 ^
   drivers/regulator/act8865-regulator.c:266:48: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("DCDC_REG2", ACT8865, DCDC2, VSET2),
   ^
   drivers/regulator/act8865-regulator.c:267:48: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("DCDC_REG3", ACT8865, DCDC3, VSET2),
   ^
   drivers/regulator/act8865-regulator.c:268:45: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("LDO_REG1", ACT8865, LDO1, VSET),
^
   drivers/regulator/act8865-regulator.c:269:45: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("LDO_REG2", ACT8865, LDO2, VSET),
^
   drivers/regulator/act8865-regulator.c:270:45: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("LDO_REG3", ACT8865, LDO3, VSET),
^
   drivers/regulator/act8865-regulator.c:271:45: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET),
^

vim +/ACT88xx_REG +265 drivers/regulator/act8865-regulator.c

   259  ACT88xx_REG("LDO_REG2", ACT8865, LDO2, VSET, "inl45"),
   260  ACT88xx_REG("LDO_REG3", ACT8865, LDO3, VSET, "inl67"),
   261  ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET, "inl67"),
   262  };
   263  
   264  static const struct regulator_desc act8865_alt_regulators[] = {
 > 265  ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET2),
   266  ACT88xx_REG("DCDC_REG2", ACT8865, DCDC2, VSET2),
   267  ACT88xx_REG("DCDC_REG3", ACT8865, DCDC3, VSET2),
   268  ACT88xx_REG("LDO_REG1", ACT8865, LDO1, VSET),

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v5 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Yakir Yang]

Hi Krzysztof,

On 09/30/2015 01:17 PM, Krzysztof Kozlowski wrote:

On 22.09.2015 16:29, Yakir Yang wrote:

Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.

Beside the new analogix_dp driver would export four hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_detect()" and "analogix_dp_get_modes()"

The bind/unbind symbols is used for analogix platform driver to connect
with analogix_dp core driver. And the detect/get_modes is used for analogix
platform driver to init the connector.

They reason why connector need register in helper driver is rockchip drm
haven't implement the atomic API, but Exynos drm have implement it, so
there would need two different connector helper functions, that's why we
leave the connector register in helper driver.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
   the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
   attch function. Cause once platform failed at attach, core driver should
   still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
   patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)

Thanks for fixing this, looks much better.

I don't feel comfortable enough to provide a review tag but it looks
good to me.


Thanks  ;)

- Yakir


Best regards,
Krzysztof







--
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 v5 03/17] drm: bridge: analogix/dp: fix some obvious code style

[Yakir Yang]

Hi Krzysztof,

On 09/30/2015 01:22 PM, Krzysztof Kozlowski wrote:

On 22.09.2015 16:34, Yakir Yang wrote:

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
   from exynos_dp code, and rephrase reasonable commit message, and
   remove some controversial style (Krzysztof)
 -  analogix_dp_write_byte_to_dpcd(
 -  dp, DP_TEST_RESPONSE,
 +  analogix_dp_write_byte_to_dpcd(dp,
 +  DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
   uncommon style like bellow: (Joe Preches)
 -  retval = exynos_dp_read_bytes_from_i2c(...
  ...);
 +  retval =
 +  exynos_dp_read_bytes_from_i2c(..);

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
  3 files changed, 163 insertions(+), 162 deletions(-)


IMHO much better than in previous attempt. The code looks good:

Reviewed-by: Krzysztof Kozlowski 

BTW my opinion is not enough, you still need an ack from Exynos DP
maintainer (or DRM guys).


Aha, thanks.

- Yakir


Best regards,
Krzysztof







--
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/David,

On 18/09/15 17:53, 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

Could you please ack the patches affecting the omap2 nand driver?
These would be patches 4, 6, 9, 10, 11, 12, 18. Thanks.

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.
> 
> Roger Quadros (27):
>   ARM: OMAP2+: gpmc: Add platform data
>   ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
>   memory: omap-gpmc: Introduce GPMC to NAND interface
>   mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers
>   memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status
>   mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty
> check
>   memory: omap-gpmc: Remove NAND IRQ code
>   memory: omap-gpmc: Add IRQ ops for GPMC-NAND interface
>   mtd: nand: omap2: manage NAND interrupts
>   mtd: nand: omap: Copy platform data parameters to omap_nand_info data
>   mtd: nand: omap: Clean up device tree support
>   mtd: nand: omap: Update DT binding documentation
>   memory: omap-gpmc: Prevent mapping into 1st 16MB
>   memory: omap-gpmc: Move device tree binding to correct location
>   memory: omap-gpmc: Support general purpose input for WAITPINs
>   memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring
>   memory: omap-gpmc: Add irqchip support to the gpiochip
>   mtd: nand: omap2: Implement NAND ready using gpiolib
>   memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via
> gpmc_regs
>   ARM: dts: dra7: Fix NAND device nodes.
>   ARM: dts: dra7x-evm: Provide NAND ready pin
>   ARM: dts: am437x: Fix NAND device nodes
>   ARM: dts: am437x-gp-evm: Provide NAND ready pin
>   ARM: dts: am335x: Fix NAND device nodes
>   ARM: dts: am335x: Provide NAND ready pin
>   ARM: dts: dm816x: Fix gpmc and NAND node
>   ARM: dts: omap3: Fix gpmc and NAND nodes
> 
>  Documentation/devicetree/bindings/bus/ti-gpmc.txt  | 130 -
>  .../bindings/memory-controllers/omap-gpmc.txt  | 130 +
>  .../devicetree/bindings/mtd/gpmc-nand.txt  |  16 +-
>  arch/arm/boot/dts/am335x-chilisom.dtsi |   7 +-
>  arch/arm/boot/dts/am335x-evm.dts   |   7 +-
>  arch/arm/boot/dts/am335x-igep0033.dtsi |   7 +-
>  arch/arm/boot/dts/am33xx.dtsi  |   4 +
>  arch/arm/boot/dts/am4372.dtsi  |   4 +
>  arch/arm/boot/dts/am437x-gp-evm.dts|   8 +-
>  arch/arm/boot/dts/am43x-epos-evm.dts   |   8 +-
>  arch/arm/boot/dts/dm8168-evm.dts   |   7 +-
>  arch/arm/boot/dts/dm816x.dtsi  |   4 +
>  arch/arm/boot/dts/dra7-evm.dts |   6 +-
>  arch/arm/boot/dts/dra7.dtsi|   4 +
>  arch/arm/boot/dts/dra72-evm.dts|   6 +-
>  arch/arm/boot/dts/logicpd-torpedo-som.dtsi |   7 +-
>  arch/arm/boot/dts/omap3-beagle.dts |   2 +
>  arch/arm/boot/dts/omap3-cm-t3x.dtsi|   5 +-
>  arch/arm/boot/dts/omap3-devkit8000-common.dtsi |   3 +
>  arch/arm/boot/dts/omap3-evm-37xx.dts   |   7 +-
>  arch/arm/boot/dts/omap3-gta04.dtsi |   3 +
>  arch/arm/boot/dts/omap3-igep.dtsi  |   5 +-
>  arch/arm/boot/dts/omap3-igep0020-common.dtsi   |   4 +-
>  arch/arm/boot/dts/omap3-igep0030-common.dtsi   |   4 +
>  arch/arm/boot/dts/omap3-ldp.dts|   9 +-
>  arch/arm/boot/dts/omap3-lilly-a83x.dtsi|   5 +-
>  arch/arm/boot/dts/omap3-pandora-common.dtsi|   3 +
>  arch/arm/boot/dts/omap3-tao3530.dtsi   |   5 +-
>  arch/arm/boot/dts/omap3.dtsi   

RE: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey

[Opensource [Steve Twiss]]

On 30 September 2015 00:54 Dmitry Torokhov wrote:

> To: Opensource [Steve Twiss]
> Cc: Lee Jones; DEVICETREE; Ian Campbell; Kumar Gala; LINUXINPUT;
> LINUXKERNEL; Mark Rutland; Pawel Moll; RTCLINUX; Rob Herring; David
> Dajun Chen; Samuel Ortiz; Support Opensource
> Subject: Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for
> DA9062 OnKey
> 
> On Mon, Sep 28, 2015 at 08:19:27AM +, Opensource [Steve Twiss]
> wrote:
> >
> > Subject: Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings
> > for DA9062 OnKey
> >
> > Hi Lee and Dmitry,
> >
> > This patch seems to have been missed. It is the main OnKey driver for
> > DA9062 and this
> > component was waiting for the DA9062 MFD core to make it into linux-
> > mainline/v4.3-rc1.
> >
> >
> 
> I queued it for 4.4.
> 
> Thanks.
> 
> --
> Dmitry

Hi Dmitry,
I can see it in your repo now.
(a27b5e0 Input: add DA9062 OnKey capability to DA9063 OnKey driver)
Thanks for your efforts on this patch.
Regards,
Stephen

--
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] ARM: shmobile: r8a7794: add USB PHY DT support

[Simon Horman]

On Thu, Sep 17, 2015 at 02:15:58AM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 09/13/2015 01:50 AM, Sergei Shtylyov wrote:
> 
> >Define the R8A7794 generic part of the USB PHY device node. It is up to the
> >board file to enable the device.
> >
> >Signed-off-by: Sergei Shtylyov 
> >
> >---
> >  arch/arm/boot/dts/r8a7794.dtsi |   19 +++
> >  1 file changed, 19 insertions(+)
> >
> >Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
> >===
> >--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
> >+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
> >@@ -690,6 +690,25 @@
> >  0x1000 0 0 2  0 113 IRQ_TYPE_LEVEL_HIGH>;
> > };
> >
> >+usbphy: usb-phy@e6590100 {
> >+compatible = "renesas,usb-phy-r8a7794";
> >+reg = <0 0xe6590100 0 0x100>;
> >+#address-cells = <1>;
> >+#size-cells = <0>;
> >+clocks = <_clks R8A7794_CLK_HSUSB>;
> >+clock-names = "usbhs";
> 
>Forgot to add "power-domains" prop here. :-(

Are you planning to repost this?
--
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 00/11] Hi Maxime / Patrice / Srini,

[Maxime Coquelin]

Hi Peter,

On 09/28/2015 02:37 PM, Peter Griffin wrote:

This series makes a series of updates to the stih407 pinctrl groups
and makes the upstream kernel more closely aligned in terms of pin
configuration to the vendor kernel.

A number of new periphs are added such as spi fsm, nand, cec0, and
for others such as SPI the various alternate function pin muxings have
been added. Finally for SPI the controller nodes have been updated
to have the default pin assignment in the controller node.

Changes since v1:
  - Rebase on v4.3-rc3
  - Remove some SoBs (Lee)
  - Collect up Acks

kind regards,

Peter.

Peter Griffin (11):
   ARM: STi: DT: STiH407: Add a cec0 pin definition
   ARM: STi: DT: STiH407: Add i2c3 alternate pin configs
   ARM: DT: STiH407: Add SPI 3 wire and 4 wire pinctrl configs
   ARM: DT: STiH407: Add serial3 pinctrl configuration
   ARM: DT: STiH407: Add SPI FSM (NOR Flash) Controller pin config
   ARM: DT: STiH407: Add NAND flash controller pin configuration
   ARM: DT: STiH407: Add systrace pin configuration
   ARM: DT: STiH407: Add SD pinctrl config for mmc0 controller
   ARM: DT: STiH407: Add pinconfig for IRB UHF and IRB TX
   ARM: DT: STiH407: Add RMII pinctrl support
   ARM: STi: STiH407: Add spi default pinctrl groups.

  arch/arm/boot/dts/stih407-family.dtsi  |  14 ++
  arch/arm/boot/dts/stih407-pinctrl.dtsi | 378 -
  2 files changed, 387 insertions(+), 5 deletions(-)



Series applied to sti-dt-for-v4.4.
Thanks!
Maxime
--
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] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
Rev4 and Rev5. The only difference between these 2 revisions is the codec,
Rev4 has a max98095 codec while Rev5 has a max98090.

Mainline only supports Rev4 so this patch moves the common device nodes to
a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.

The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.

Signed-off-by: Javier Martinez Canillas 
Tested-by: Mauro Carvalho Chehab 
Reviewed-by: Douglas Anderson 

---

Changes in v2:
- Add Mauro Carvalho Chehab's Tested-by tag.
- Add Doug Anderson's Reviewed-by tag.
- Remove warning about adding a whitespace error. Suggested by Doug Anderson.
- Make Rev{4,5} codec pinctrl properties to match. Suggested by Doug Anderson.
- Add "google,snow-rev4" to compatible string. Suggested by Krzysztof Kozlowski.

 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 ++
 arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
 arch/arm/boot/dts/exynos5250-snow.dts | 671 +
 4 files changed, 736 insertions(+), 667 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
 create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5436ad479b08..a2408a63b341 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -115,6 +115,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+   exynos5250-snow-rev5.dtb \
exynos5250-spring.dtb \
exynos5260-xyref5260.dtb \
exynos5410-smdk5410.dtb \
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
new file mode 100644
index ..0a7f408824d8
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -0,0 +1,684 @@
+/*
+ * Google Snow board device tree source
+ *
+ * Copyright (c) 2012 Google, Inc
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "exynos5250.dtsi"
+
+/ {
+   aliases {
+   i2c104 = _104;
+   };
+
+   memory {
+   reg = <0x4000 0x8000>;
+   };
+
+   chosen {
+   bootargs = "console=tty1";
+   stdout-path = "serial3:115200n8";
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   pinctrl-names = "default";
+   pinctrl-0 = <_key_irq _irq>;
+
+   power {
+   label = "Power";
+   gpios = < 3 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   gpio-key,wakeup;
+   };
+
+   lid-switch {
+   label = "Lid";
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   linux,input-type = <5>; /* EV_SW */
+   linux,code = <0>; /* SW_LID */
+   debounce-interval = <1>;
+   gpio-key,wakeup;
+   };
+   };
+
+   vbat: vbat-fixed-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vbat-supply";
+   regulator-boot-on;
+   };
+
+   i2c-arbitrator {
+   compatible = "i2c-arb-gpio-challenge";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c-parent = <&{/i2c@12CA}>;
+
+   our-claim-gpio = < 3 GPIO_ACTIVE_LOW>;
+   their-claim-gpios = < 4 GPIO_ACTIVE_LOW>;
+   slew-delay-us = <10>;
+   wait-retry-us = <3000>;
+   wait-free-us = <5>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_our_claim _their_claim>;
+
+   /* Use ID 104 as a hint that we're on physical bus 4 */
+   i2c_104: i2c@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   battery: sbs-battery@b {
+   compatible = "sbs,sbs-battery";
+   reg = <0xb>;
+   sbs,poll-retry-count = <1>;
+   };
+
+   cros_ec: embedded-controller {
+   compatible = "google,cros-ec-i2c";
+   reg = <0x1e>;
+   interrupts = <6 IRQ_TYPE_NONE>;
+   interrupt-parent = <>;
+   pinctrl-names = "default";
+ 

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

Hello,

On 09/30/2015 09:02 AM, Krzysztof Kozlowski wrote:
> On 30.09.2015 15:58, Kukjin Kim wrote:

[snip]

>>>
>>> Could you add the new compatible and fix patch issues pointed by Doug?
>>>
>> Documenting for the compatibles would be required even I already applied
>> its updated patch...
>

Kukjin, I agree that they should be documented but I thought it would
be a separate patch since currently we don't document any board.
 
> What do you mean by "documenting compatibles"? These are board
> compatibles, they are not documented...
>

Krzysztof, I've on my TODO list to add a file describing all Exynos
platforms and DT bindings, something like what other SoC do, i.e:

Documentation/devicetree/bindings/arm/omap/omap.txt
Documentation/devicetree/bindings/arm/rockchip.txt
 
> Best regards,
> Krzysztof
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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/2] Add support to make output voltage determined by VSET2[] bits

[Wenyou Yang]

The patch is to add support to make the output voltage of ACT8865
DC/DC regulator determined by VSET2[] bits. The DT property
"active-semi,vsel-high" is used to specify the VSEL pin at high
on the board. When the VSEL pin is high, output voltage is programmed
by VSET2[] bits.

Changes in v2:
 - fix missed argument of macro "ACT88xx_REG" for act8865_alt_regulators
   structure variable.
 - set variable "voltage_select" initial value to avoid compile warning.

Wenyou Yang (2):
  regulator: act8865: support output voltage by VSET2[] bits
  regulator: act8865: add DT binding for property
"active-semi,vsel-high"

 .../bindings/regulator/act8865-regulator.txt   |3 +++
 drivers/regulator/act8865-regulator.c  |   24 ++--
 2 files changed, 25 insertions(+), 2 deletions(-)

-- 
1.7.9.5

--
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 v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Krzysztof Kozlowski]

On 30.09.2015 16:19, Yakir Yang wrote:
> Hi Krzysztof,
> 
> On 09/30/2015 01:32 PM, Krzysztof Kozlowski wrote:
>> On 22.09.2015 16:37, Yakir Yang wrote:
>>> Both hsync/vsync polarity and interlace mode can be parsed from
>>> drm display mode, and dynamic_range and ycbcr_coeff can be judge
>>> by the video code.
>>>
>>> But presumably Exynos still relies on the DT properties, so take
>>> good use of mode_fixup() in to achieve the compatibility hacks.
>>>
>>> Signed-off-by: Yakir Yang 
>>> ---
>>> Changes in v5:
>>> - Switch video timing type to "u32", so driver could use 
>>> "of_property_read_u32"
>>>   to get the backword timing values. 
>> Okay
>>
>>> Krzysztof suggest me that driver could use
>>>   the "of_property_read_bool" to get backword timing values, but that 
>>> interfacs
>>>   would modify the original drm_display_mode timing directly (whether those
>>>   properties exists or not).
>> Hmm, I don't understand. You have a:
>>  struct video_info {
>>  bool h_sync_polarity;
>>  bool v_sync_polarity;
>>  bool interlaced;
>>  };
>>
>> so what is wrong with:
>>  dp_video_config->h_sync_polarity =
>>  of_property_read_bool(dp_node, "hsync-active-high");
>>
>> Is it exactly the same binding as previously?
> 
> Yes, it is the same binding as previously. But just a note that we already
> mark those DT binding as deprecated.
> 
> +-interlaced:deprecated prop that can parsed frm drm_display_mode.
> +-vsync-active-high: deprecated prop that can parsed frm drm_display_mode.
> +-hsync-active-high: deprecated prop that can parsed frm drm_display_mode.
> 
> 
> For now those values should come from "struct drm_display_mode",
> and we already parsed them out from "drm_display_mode" before
> driver provide the backward compatibility.
> 
> Let's used the "hsync-active-high" example:
> As for now the code would like:
> static void analogix_dp_bridge_mode_set(...)
> {
> // Parsed timing value from "drm_display_mode"
> video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
> 
> // Try to detect the deprecated property, providing
> // the backward compatibility
> of_property_read_u32(dp_node, "hsync-active-high",
>  >h_sync_polarity);
> 
> /*
>  * In this case, if "hsync-active-high" property haven't been
>  * found, then the video timing "h_sync_polarity" would  keep
>  * no change, keeping the parsed value from "drm_display_mode"
>  */ 
> }   
> 
> But if keep the "of_property_read_bool", then code would like:
> static void analogix_dp_bridge_mode_set(...)
> {
> // Parsed timing value from "drm_display_mode"
> video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
> 
> // Try to detect the deprecated property, providing
> // the backward compatibility
> video->h_sync_polarity =
> of_property_read_bool(dp_node, "hsync-active-high");
>
> 
> /*
>  * In this case, if "hsync-active-high" property haven't been
>  * found, then the video timing "h_sync_polarity" would just
>  * modify to "false". That is the place we don't want, cause
>  * it would always modify the timing value parsed from
>  * "drm_display_mode"
>  */  
> }   
> 

OK, I see the point of overwriting values from drm_display_mode. However
I think you changed the binding. I believe the of_property_read_u32()
will behave differently for such DTS:

exynos_dp {
...
hsync-active-high;
}

It will return -EOVERFLOW which means it would be broken now...

Best regards,
Krzysztof


--
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 v5 07/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

[Yakir Yang]

Hi Krzysztof,

On 09/30/2015 01:39 PM, Krzysztof Kozlowski wrote:

On 22.09.2015 16:43, Yakir Yang wrote:

After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.

Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Correct the misspell in commit message. (Krzysztof)

Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)

Changes in v3: None
Changes in v2: None

  arch/arm/boot/dts/exynos5250-arndale.dts   | 2 --
  arch/arm/boot/dts/exynos5250-smdk5250.dts  | 2 --
  arch/arm/boot/dts/exynos5250-snow.dts  | 4 +---
  arch/arm/boot/dts/exynos5250-spring.dts| 4 +---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +---
  arch/arm/boot/dts/exynos5420-smdk5420.dts  | 2 --
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 4 +---
  7 files changed, 4 insertions(+), 18 deletions(-)


Assuming this will be merged as part of this set (dependency on previous
patches):

Reviewed-by: Krzysztof Kozlowski 


Thanks a lot ;)

- Yakir


Best regards,
Krzysztof







--
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 v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Krzysztof Kozlowski]

On 30.09.2015 17:20, Yakir Yang wrote:
> Hi Krzysztof,
> 
> On 09/30/2015 03:34 PM, Krzysztof Kozlowski wrote:
>> On 30.09.2015 16:19, Yakir Yang wrote:
>>> Hi Krzysztof,
>>>
>>> On 09/30/2015 01:32 PM, Krzysztof Kozlowski wrote:
 On 22.09.2015 16:37, Yakir Yang wrote:
> Both hsync/vsync polarity and interlace mode can be parsed from
> drm display mode, and dynamic_range and ycbcr_coeff can be judge
> by the video code.
>
> But presumably Exynos still relies on the DT properties, so take
> good use of mode_fixup() in to achieve the compatibility hacks.
>
> Signed-off-by: Yakir Yang 
> ---
> Changes in v5:
> - Switch video timing type to "u32", so driver could use 
> "of_property_read_u32"
>   to get the backword timing values. 
 Okay

> Krzysztof suggest me that driver could use
>   the "of_property_read_bool" to get backword timing values, but that 
> interfacs
>   would modify the original drm_display_mode timing directly (whether 
> those
>   properties exists or not).
 Hmm, I don't understand. You have a:
struct video_info {
bool h_sync_polarity;
bool v_sync_polarity;
bool interlaced;
};

 so what is wrong with:
dp_video_config->h_sync_polarity =
of_property_read_bool(dp_node, "hsync-active-high");

 Is it exactly the same binding as previously?
>>> Yes, it is the same binding as previously. But just a note that we already
>>> mark those DT binding as deprecated.
>>>
>>> +-interlaced:deprecated prop that can parsed frm 
>>> drm_display_mode.
>>> +-vsync-active-high: deprecated prop that can parsed frm 
>>> drm_display_mode.
>>> +-hsync-active-high: deprecated prop that can parsed frm 
>>> drm_display_mode.
>>>
>>>
>>> For now those values should come from "struct drm_display_mode",
>>> and we already parsed them out from "drm_display_mode" before
>>> driver provide the backward compatibility.
>>>
>>> Let's used the "hsync-active-high" example:
>>> As for now the code would like:
>>> static void analogix_dp_bridge_mode_set(...)
>>> {
>>> // Parsed timing value from "drm_display_mode"
>>> video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
>>>
>>> // Try to detect the deprecated property, providing
>>> // the backward compatibility
>>> of_property_read_u32(dp_node, "hsync-active-high",
>>>  >h_sync_polarity);
>>>
>>> /*
>>>  * In this case, if "hsync-active-high" property haven't been
>>>  * found, then the video timing "h_sync_polarity" would  keep
>>>  * no change, keeping the parsed value from "drm_display_mode"
>>>  */ 
>>> }   
>>>
>>> But if keep the "of_property_read_bool", then code would like:
>>> static void analogix_dp_bridge_mode_set(...)
>>> {
>>> // Parsed timing value from "drm_display_mode"
>>> video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
>>>
>>> // Try to detect the deprecated property, providing
>>> // the backward compatibility
>>> video->h_sync_polarity =
>>> of_property_read_bool(dp_node, "hsync-active-high");
>>>
>>>
>>> /*
>>>  * In this case, if "hsync-active-high" property haven't been
>>>  * found, then the video timing "h_sync_polarity" would just
>>>  * modify to "false". That is the place we don't want, cause
>>>  * it would always modify the timing value parsed from
>>>  * "drm_display_mode"
>>>  */  
>>> }   
>>>
>> OK, I see the point of overwriting values from drm_display_mode. However
>> I think you changed the binding. I believe the of_property_read_u32()
>> will behave differently for such DTS:
>>
>> exynos_dp {
>>  ...
>>  hsync-active-high;
>> }
>>
>> It will return -EOVERFLOW which means it would be broken now...
> 
> Whoops, thanks for your remind, after try that, I do see over flow error.
> static void *of_find_property_value_of_size(const struct device_node *np,
> const char *propname, u32 len)
> {
> 
> if (len > prop->length)
> return ERR_PTR(-EOVERFLOW);
> ...
> }
> 
> So I though code should be:
> if (of_property_read_bool(dp_node, "hsync-active-high"))
> video->h_sync_polarity = true;

Looks good.

> 
> And we can't provide full backward compatibility for this property, cause
> the previous exynos_dp driver would set this timing value to "false" when
> property not defined, but analogix_dp driver keep this timing value
> corresponding to "drm_display_mode" when property not found.

Indeed, the behaviour changes. I don't know if this is important issue...

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH 0/2] Add R8A7794/SILK board PCI USB DT support

[Simon Horman]

On Tue, Sep 29, 2015 at 03:18:30PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 9/29/2015 3:36 AM, Simon Horman wrote:
> 
> >>On 09/13/2015 01:28 AM, Sergei Shtylyov wrote:
> 
> >>>Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
> >>>'renesas-devel-20150911v2-v4.2' tag. Here we add PCI USB device tree 
> >>>support
> >>>for the R8A7794-based SILK board.
> 
> >>Oops, forgot to say that the patches need the 'pci-rcar-gen2' driver
> >>patch posted yesterday in order to work.
> 
> >Am I correct in thinking that patch has been accepted and
> >that therefore I can now pick up this series?
> 
>Yes, it's been merged by Linus already.

Thanks, I have queued-up this series.
--
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 v5 0/6] Add support for DA9150 Fuel-Gauge

[Opensource [Adam Thomson]]

On September 22, 2015 18:11, Lee Jones wrote:

> On Tue, 22 Sep 2015, Sebastian Reichel wrote:
> > On Fri, Sep 11, 2015 at 11:05:21AM +0100, Adam Thomson wrote:
> > > This patch set adds support for the Dialog DA9150 Fuel-Gauge.
> > >
> > > [...]
> > >
> > > Adam Thomson (6):
> > >   mfd: da9150: Add support for Fuel-Gauge
> > >   mfd: da9150: Update DT bindings for Fuel-Gauge support
> > >   power: Add support for DA9150 Fuel-Gauge
> > >   power: da9150: Add DT bindings documentation for Fuel-Gauge
> > >   mfd: da9150: Use relative paths in DT bindings document
> > >   mfd: da9150: Use DEFINE_RES_IRQ_NAMED() help macro for IRQ resource
> > >
> > >  Documentation/devicetree/bindings/mfd/da9150.txt   |  33 +-
> > >  .../devicetree/bindings/power/da9150-fg.txt|  23 +
> > >  drivers/mfd/da9150-core.c  | 191 +--
> > >  drivers/power/Kconfig  |  10 +
> > >  drivers/power/Makefile |   1 +
> > >  drivers/power/da9150-fg.c  | 578 
> > > +
> > >  include/linux/mfd/da9150/core.h|  19 +-
> > >  7 files changed, 810 insertions(+), 45 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/power/da9150-fg.txt
> > >  create mode 100644 drivers/power/da9150-fg.c
> >
> > I suggest, that you take the whole patchset via the mfd tree.
> 
> That's fine, but I'm still missing an Ack for patch 4.

Hi Lee,

I believe all patches are now acked. Is there anything else needed to help this
along?

Thanks
Adam

Re: [PATCH v3 0/9] ARM: dts: update Boundary Devices boards support

[Shawn Guo]

On Wed, Sep 09, 2015 at 02:30:44PM +0200, Gary Bisson wrote:
> Hi all,
> 
> This series is a follow-up to the previous series that added LCD display
> support.
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364425.html

The MAINTAINERS file has been updated for a couple of release cycles
with my new email address.  Please stop sending patches to
shawn@linaro.org, and resend any patches you want me to collect to
shawn...@kernel.org.

Shawn

> 
> This one aims at adding touchscreen and WiFi support for Nitrogen6x as well as
> adding two boards: Nitrogen6_Max and Nit6xlite.
> 
> It also takes care of updating the licenses to be GPLv2/X11.
> 
> The series has been tested against linux-next tag next-20150909.
> 
> Note that imx_v6_v7_defconfig has been used with the following additions:
> CONFIG_TOUCHSCREEN_EDT_FT5X06=y
> CONFIG_I2C_MUX_GPIO=y
> CONFIG_RTC_DRV_M41T80=y
> 
> Modifications:
> v2->v3:
> - Rename nodes to general class of device as suggested by Philipp and Russell.
> - Remove useless wakeup-gpio field for edt,ft5x06 touchscreen
> - Add missing muxing for interrupt GPIO
> - Rebased on next-20150909
> v1->v2:
> - Add Boundary Devices Inc. to vendor prefixes
> - Relicense devices trees to GPLv2/X11 as suggested by Fabio for:
>   - Nitrogen6x
>   - SabreLite
>   - Nit6xLite
>   - Nitrogen6_MAX
> - Change manufacturer to Boundary Devices as suggested by Fabio for:
>   - Nitrogen6x
>   - Nit6xLite
>   - Nitrogen6_MAX
> - Fixed missing macros for gpio/irq values as suggested by Philipp.
> - Rebased on next-20150908
> 
> Regards,
> Gary
> 
> Gary Bisson (9):
>   ARM: dts: imx6dql-nitrogen6x: add touchscreen support
>   ARM: dts: imx6qdl-nitrogen6x: add wifi wl1271 support
>   ARM: dts: imx6qdl-nitrogen6x: relicense under GPLv2/X11
>   ARM: dts: imx6qdl-sabrelite: relicense under GPLv2/X11
>   of: Add Boundary Devices Inc. vendor prefix
>   ARM: dts: imx6q-nitrogen6x: change manufacturer to Boundary Devices
>   ARM: dts: imx6dl-nitrogen6x: change manufacturer to Boundary Devices
>   ARM: dts: imx: add Boundary Devices Nitrogen6_Max board
>   ARM: dts: imx: add Boundary Devices Nitrogen6_Lite board
> 
>  .../devicetree/bindings/vendor-prefixes.txt|   1 +
>  arch/arm/boot/dts/Makefile |   2 +
>  arch/arm/boot/dts/imx6dl-nit6xlite.dts |  49 ++
>  arch/arm/boot/dts/imx6dl-nitrogen6x.dts|  44 +-
>  arch/arm/boot/dts/imx6dl-sabrelite.dts |  40 +-
>  arch/arm/boot/dts/imx6q-nitrogen6_max.dts  |  53 ++
>  arch/arm/boot/dts/imx6q-nitrogen6x.dts |  44 +-
>  arch/arm/boot/dts/imx6q-sabrelite.dts  |  40 +-
>  ...6qdl-nitrogen6x.dtsi => imx6qdl-nit6xlite.dtsi} | 396 ++
>  arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi   | 873 
> +
>  arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi  | 111 ++-
>  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi   |  40 +-
>  12 files changed, 1523 insertions(+), 170 deletions(-)
>  create mode 100644 arch/arm/boot/dts/imx6dl-nit6xlite.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6_max.dts
>  copy arch/arm/boot/dts/{imx6qdl-nitrogen6x.dtsi => imx6qdl-nit6xlite.dtsi} 
> (50%)
>  create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> 
> -- 
> 2.5.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v3 0/5] usb: change clock information for chipidea

[Shawn Guo]

On Wed, Sep 30, 2015 at 02:24:28PM +0800, Peter Chen wrote:
> On Wed, Sep 30, 2015 at 01:28:36PM +0800, Shawn Guo wrote:
> > On Wed, Sep 30, 2015 at 10:25:20AM +0800, Peter Chen wrote:
> > > This patch set changes usb clock information for legacy i.mx platforms.
> > > At these platforms, they needs three clocks to let controller work.
> > > 
> > > Hi Shawn,
> > > 
> > > Fabio has tested for both imx27 and imx25 platforms.
> > > I have queued 1/5 and 5/5, would you please help to queue others,
> > > thanks.
> > > 
> > > Changes for v3:
> > > - Delete property "needs-three-clocks", and using of_device_id->data
> > >   to differentiate platforms
> > > - change  #v3.19+ to  
> > > #v4.1+
> > 
> > So the last patch will be sent as a fix with stable on copy?
> 
> Yes
> 
> > In that
> > case, will USB driver just work without corresponding DTS change?  Or
> > the driver change has a dependency on the DTS change?
> > 
> 
> At v4.1, One of USB driver changes break i.mx27's USB function.
> The driver's change at patch 5/5 is also tagged for stable tree,
> so it needs both DTS and driver's change to let i.mx27 USB work from
> v4.1.

In that case, you need to have dts and driver changes go through the
same tree.  For dts patches, you can have

Acked-by: Shawn Guo 

As a side note, the kernel change breaks the ABI with DT anyway.

Shawn
--
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] ARM: dts: sun6i: hummingbird: Add aliases for rtc devices

[Chen-Yu Tsai]

The hummingbird A31 has 2 rtc devices available: one in the SoC, and
a pcf8563 external rtc on i2c2.

For some unknown reason, the onboard backup battery to power the
internal rtc when power is removed, and its time would reset. Hence
we want to use the external one by default.

Add aliases for the rtc devices with the external one as rtc0.

Signed-off-by: Chen-Yu Tsai 
---

Can someone else with the Hummingbird A31 also test the internal RTC
and see if it doesn't survive power removal?

Thanks
ChenYu

---
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts 
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 06d9391ca30e..358781113582 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -55,6 +55,8 @@
 
aliases {
serial0 = 
+   rtc0 = 
+   rtc1 = 
};
 
chosen {
-- 
2.5.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 v6 2/2] pwm: Add support for R-Car PWM Timer

[Yoshihiro Shimoda]

Hi Thierry,

> Sent: Tuesday, September 15, 2015 7:01 PM
> 
> Hi Thierry,
> 
> > Sent: Wednesday, August 19, 2015 8:01 PM
> >
> > Hi Thierry,
> >
> > > Sent: Wednesday, August 19, 2015 7:08 PM
> > >
> > > On Wed, Aug 19, 2015 at 01:13:59PM +0900, Yoshihiro Shimoda wrote:
> > > > This patch adds support for R-Car SoCs PWM Timer. The PWM timer of
> > > > R-Car H2 has 7 channels. So, we can use the channels if we describe
> > > > device tree nodes.
> > > >
> > > > Signed-off-by: Yoshihiro Shimoda 
> > > > Reviewed-by: Simon Horman 
> > > > ---
> > > >  drivers/pwm/Kconfig|  11 ++
> > > >  drivers/pwm/Makefile   |   1 +
> > > >  drivers/pwm/pwm-rcar.c | 265 
> > > > +
> > > >  3 files changed, 277 insertions(+)
> > > >  create mode 100644 drivers/pwm/pwm-rcar.c
> > >
> > > Found a couple more things. No need to respin for any of these, I can
> > > make the changes when applying, but I'd like confirmation on a couple
> > > of things below.
> >
> > Thank you!
> 
> I could not find this driver in the latest your linux-pwm.git / for-next 
> branch.
> Should I send v7 patch?

I submitted v7 patch now. So, would you review it?

Best regards,
Yoshihiro Shimoda

--
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] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Kukjin Kim]

On 09/30/15 15:44, Javier Martinez Canillas wrote:
> There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
> Rev4 and Rev5. The only difference between these 2 revisions is the codec,
> Rev4 has a max98095 codec while Rev5 has a max98090.
> 
> Mainline only supports Rev4 so this patch moves the common device nodes to
> a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.
> 
> The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.
> 
> Signed-off-by: Javier Martinez Canillas 
> Tested-by: Mauro Carvalho Chehab 
> Reviewed-by: Douglas Anderson 
> 
> ---
> 
> Changes in v2:
> - Add Mauro Carvalho Chehab's Tested-by tag.
> - Add Doug Anderson's Reviewed-by tag.
> - Remove warning about adding a whitespace error. Suggested by Doug Anderson.
> - Make Rev{4,5} codec pinctrl properties to match. Suggested by Doug Anderson.
> - Add "google,snow-rev4" to compatible string. Suggested by Krzysztof 
> Kozlowski.
> 
>  arch/arm/boot/dts/Makefile|   1 +
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
> ++
>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>  arch/arm/boot/dts/exynos5250-snow.dts | 671 +
>  4 files changed, 736 insertions(+), 667 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
> 
Applied, thanks.

- Kukjin
--
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: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

Hello Krzysztof,

On 09/30/2015 09:08 AM, Krzysztof Kozlowski wrote:
> On 30.09.2015 16:06, Javier Martinez Canillas wrote:
>> Hello,
>>
>> On 09/30/2015 09:02 AM, Krzysztof Kozlowski wrote:
>>> On 30.09.2015 15:58, Kukjin Kim wrote:
>>
>> [snip]
>>
>
> Could you add the new compatible and fix patch issues pointed by Doug?
>
 Documenting for the compatibles would be required even I already applied
 its updated patch...
>>>
>>
>> Kukjin, I agree that they should be documented but I thought it would
>> be a separate patch since currently we don't document any board.
>>  
>>> What do you mean by "documenting compatibles"? These are board
>>> compatibles, they are not documented...
>>>
>>
>> Krzysztof, I've on my TODO list to add a file describing all Exynos
>> platforms and DT bindings, something like what other SoC do, i.e:
>>
>> Documentation/devicetree/bindings/arm/omap/omap.txt
>> Documentation/devicetree/bindings/arm/rockchip.txt
> 
> Right, that's a good idea. However lack of it does not affect current
> work because compatibles for Exynos board are not documented at all.
> 

Agreed. That's why I didn't add it, even when checkpatch.pl complains:

WARNING: DT compatible string "google,snow-rev5" appears un-documented -- check 
./Documentation/devicetree/bindings/

> Best regards,
> Krzysztof
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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] regulator: act8865: support output voltage by VSET2[] bits

[Wenyou Yang]

For the step-down DC/DC regulators, the output voltage is
selectable by setting VSEL pin that when VSEL is low, output
voltage is programmed by VSET1[] bits, and when VSEL is high,
output voltage is programmed by VSET2[] bits.

The DT property "active-semi,vsel-high" is used to specify
the VSEL pin at high on the board.

Signed-off-by: Wenyou Yang 
---

Changes in v2:
 - fix missed argument of macro "ACT88xx_REG" for act8865_alt_regulators
   structure variable.
 - set variable "voltage_select" initial value to avoid compile warning.

 drivers/regulator/act8865-regulator.c |   24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/act8865-regulator.c 
b/drivers/regulator/act8865-regulator.c
index 896db16..f8d4cd3 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -261,6 +261,16 @@ static const struct regulator_desc act8865_regulators[] = {
ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET, "inl67"),
 };
 
+static const struct regulator_desc act8865_alt_regulators[] = {
+   ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET2, "vp1"),
+   ACT88xx_REG("DCDC_REG2", ACT8865, DCDC2, VSET2, "vp2"),
+   ACT88xx_REG("DCDC_REG3", ACT8865, DCDC3, VSET2, "vp3"),
+   ACT88xx_REG("LDO_REG1", ACT8865, LDO1, VSET, "inl45"),
+   ACT88xx_REG("LDO_REG2", ACT8865, LDO2, VSET, "inl45"),
+   ACT88xx_REG("LDO_REG3", ACT8865, LDO3, VSET, "inl67"),
+   ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET, "inl67"),
+};
+
 #ifdef CONFIG_OF
 static const struct of_device_id act8865_dt_ids[] = {
{ .compatible = "active-semi,act8600", .data = (void *)ACT8600 },
@@ -413,6 +423,7 @@ static int act8865_pmic_probe(struct i2c_client *client,
struct act8865 *act8865;
unsigned long type;
int off_reg, off_mask;
+   int voltage_select = 0;
 
pdata = dev_get_platdata(dev);
 
@@ -424,6 +435,10 @@ static int act8865_pmic_probe(struct i2c_client *client,
return -ENODEV;
 
type = (unsigned long) id->data;
+
+   voltage_select = !!of_get_property(dev->of_node,
+  "active-semi,vsel-high",
+  NULL);
} else {
type = i2c_id->driver_data;
}
@@ -442,8 +457,13 @@ static int act8865_pmic_probe(struct i2c_client *client,
off_mask = ACT8846_OFF_SYSMASK;
break;
case ACT8865:
-   regulators = act8865_regulators;
-   num_regulators = ARRAY_SIZE(act8865_regulators);
+   if (voltage_select) {
+   regulators = act8865_alt_regulators;
+   num_regulators = ARRAY_SIZE(act8865_alt_regulators);
+   } else {
+   regulators = act8865_regulators;
+   num_regulators = ARRAY_SIZE(act8865_regulators);
+   }
off_reg = ACT8865_SYS_CTRL;
off_mask = ACT8865_MSTROFF;
break;
-- 
1.7.9.5

--
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] regulator: act8865: add DT binding for property "active-semi,vsel-high"

[Wenyou Yang]

Add a DT property "active-semi,vsel-high" to indicate the VSEL pin
is high. If this property is missing, then assume the VSEL pin is
low(0).

Signed-off-by: Wenyou Yang 
---

Changes in v2: None

 .../bindings/regulator/act8865-regulator.txt   |3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt 
b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
index e91485d..6067d98 100644
--- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
@@ -8,6 +8,8 @@ Required properties:
 Optional properties:
 - system-power-controller: Telling whether or not this pmic is controlling
   the system power. See 
Documentation/devicetree/bindings/power/power-controller.txt .
+- active-semi,vsel-high: Indicates the VSEL pin is high.
+  If this property is missing, assume the VSEL pin is low(0).
 
 Optional input supply properties:
 - for act8600:
@@ -49,6 +51,7 @@ Example:
pmic: act8865@5b {
compatible = "active-semi,act8865";
reg = <0x5b>;
+   active-semi,vsel-high;
status = "disabled";
 
regulators {
-- 
1.7.9.5

--
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/4] net: phy: Broadcom iProc MDIO bus driver

[Arun Parameswaran]

This patch adds support for the Broadcom iProc MDIO bus interface.
The MDIO interface can be found in the Broadcom iProc family Soc's.

The MDIO bus is accessed using a combination of command and data
registers. This MDIO driver provides access to the Etherent GPHY's
connected to the MDIO bus.

Signed-off-by: Arun Parameswaran 
---
 drivers/net/phy/Kconfig  |   9 ++
 drivers/net/phy/Makefile |   1 +
 drivers/net/phy/mdio-bcm-iproc.c | 213 +++
 3 files changed, 223 insertions(+)
 create mode 100644 drivers/net/phy/mdio-bcm-iproc.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index c5ad98a..b57f6c2 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -225,6 +225,15 @@ config MDIO_BCM_UNIMAC
  This hardware can be found in the Broadcom GENET Ethernet MAC
  controllers as well as some Broadcom Ethernet switches such as the
  Starfighter 2 switches.
+
+config MDIO_BCM_IPROC
+   tristate "Broadcom iProc MDIO bus controller"
+   depends on ARCH_BCM_IPROC || COMPILE_TEST
+   depends on HAS_IOMEM && OF_MDIO
+   help
+ This module provides a driver for the MDIO busses found in the
+ Broadcom iProc SoC's.
+
 endif # PHYLIB
 
 config MICREL_KS8995MA
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 87f079c..f4e6eb9 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_MDIO_SUN4I)  += mdio-sun4i.o
 obj-$(CONFIG_MDIO_MOXART)  += mdio-moxart.o
 obj-$(CONFIG_MDIO_BCM_UNIMAC)  += mdio-bcm-unimac.o
 obj-$(CONFIG_MICROCHIP_PHY)+= microchip.o
+obj-$(CONFIG_MDIO_BCM_IPROC)   += mdio-bcm-iproc.o
diff --git a/drivers/net/phy/mdio-bcm-iproc.c b/drivers/net/phy/mdio-bcm-iproc.c
new file mode 100644
index 000..c0b4e65
--- /dev/null
+++ b/drivers/net/phy/mdio-bcm-iproc.c
@@ -0,0 +1,213 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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 
+
+#define IPROC_GPHY_MDCDIV0x1a
+
+#define MII_CTRL_OFFSET  0x000
+
+#define MII_CTRL_DIV_SHIFT   0
+#define MII_CTRL_PRE_SHIFT   7
+#define MII_CTRL_BUSY_SHIFT  8
+
+#define MII_DATA_OFFSET  0x004
+#define MII_DATA_MASK0x
+#define MII_DATA_TA_SHIFT16
+#define MII_DATA_TA_VAL  2
+#define MII_DATA_RA_SHIFT18
+#define MII_DATA_PA_SHIFT23
+#define MII_DATA_OP_SHIFT28
+#define MII_DATA_OP_WRITE1
+#define MII_DATA_OP_READ 2
+#define MII_DATA_SB_SHIFT30
+
+struct iproc_mdio_priv {
+   struct mii_bus *mii_bus;
+   void __iomem *base;
+};
+
+static inline int iproc_mdio_wait_for_idle(void __iomem *base)
+{
+   u32 val;
+   unsigned int timeout = 1000; /* loop for 1s */
+
+   do {
+   val = readl(base + MII_CTRL_OFFSET);
+   if ((val & BIT(MII_CTRL_BUSY_SHIFT)) == 0)
+   return 0;
+
+   usleep_range(1000, 2000);
+   } while (timeout--);
+
+   return -ETIMEDOUT;
+}
+
+static inline void iproc_mdio_config_clk(void __iomem *base)
+{
+   u32 val;
+
+   val = (IPROC_GPHY_MDCDIV << MII_CTRL_DIV_SHIFT) |
+ BIT(MII_CTRL_PRE_SHIFT);
+   writel(val, base + MII_CTRL_OFFSET);
+}
+
+static int iproc_mdio_read(struct mii_bus *bus, int phy_id, int reg)
+{
+   struct iproc_mdio_priv *priv = bus->priv;
+   u32 cmd;
+   int rc;
+
+   rc = iproc_mdio_wait_for_idle(priv->base);
+   if (rc)
+   return rc;
+
+   iproc_mdio_config_clk(priv->base);
+
+   /* Prepare the read operation */
+   cmd = (MII_DATA_TA_VAL << MII_DATA_TA_SHIFT) |
+   (reg << MII_DATA_RA_SHIFT) |
+   (phy_id << MII_DATA_PA_SHIFT) |
+   BIT(MII_DATA_SB_SHIFT) |
+   (MII_DATA_OP_READ << MII_DATA_OP_SHIFT);
+
+   writel(cmd, priv->base + MII_DATA_OFFSET);
+
+   rc = iproc_mdio_wait_for_idle(priv->base);
+   if (rc)
+   return rc;
+
+   cmd = readl(priv->base + MII_DATA_OFFSET) & MII_DATA_MASK;
+
+   return cmd;
+}
+
+static int iproc_mdio_write(struct mii_bus *bus, int phy_id,
+   int reg, u16 val)
+{
+   struct iproc_mdio_priv *priv = bus->priv;
+   u32 cmd;
+   int rc;
+
+   rc = iproc_mdio_wait_for_idle(priv->base);
+   if (rc)
+   return rc;
+
+   iproc_mdio_config_clk(priv->base);
+
+   /* Prepare the 

Re: [PATCH v2 4/6] tty: serial: msm: Add TX DMA support

[Andy Gross]

On Wed, Sep 30, 2015 at 06:32:01PM +0100, Mark Rutland wrote:
> On Wed, Sep 30, 2015 at 02:51:26PM +0100, Ivan T. Ivanov wrote:
> > 
> > On Wed, 2015-09-30 at 14:29 +0100, Mark Rutland wrote:
> > > On Wed, Sep 30, 2015 at 01:08:24PM +0100, Ivan T. Ivanov wrote:
> > > > Add transmit DMA support for UARTDM type of controllers.
> > > > 
> > > > Tested on APQ8064, which have UARTDM v1.3 and ADM DMA engine
> > > > and APQ8016, which have UARTDM v1.4 and BAM DMA engine.
> > > > 
> > > > Signed-off-by: Ivan T. Ivanov iva...@linaro.org>
> > > > ---
> > > >  .../devicetree/bindings/serial/qcom,msm-uartdm.txt |   3 +
> > > >  drivers/tty/serial/msm_serial.c| 312 
> > > > +++--
> > > >  drivers/tty/serial/msm_serial.h|   3 +
> > > >  3 files changed, 294 insertions(+), 24 deletions(-)
> > > > 
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt 
> > > > b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
> > > > index a2114c217376..a600023d9ec1 100644
> > > > --- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
> > > > +++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
> > > > @@ -26,6 +26,9 @@ Required properties:
> > > >  Optional properties:
> > > >  - dmas: Should contain dma specifiers for transmit and receive channels
> > > >  - dma-names: Should contain "tx" for transmit and "rx" for receive 
> > > > channels
> > > > +- qcom,tx-crci: Identificator  for Client Rate Control Interface 
> > > > to be
> > > > +   used with TX DMA channel. Required when using DMA for 
> > > > transmission
> > > > +   with UARTDM v1.3 and bellow.
> > > 
> > > This sounds like it belongs in the dma-specifier, and dealt with by the
> > > DMA controller driver.
> > > 
> > > Why does the UART driver need to know about this?
> > 
> > CRCI information was part of the first version of ADM DMA engine driver
> > bindings, but Andy remove it because some client devices are requiring
> > more that one CRCI number. See here[1] and here [2].
> > 
> > Regards,
> > Ivan
> > 
> > [1] 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314190.html
> > [2] https://lkml.org/lkml/2015/8/19/19
> 
> This leaves me more confused. If different writes from the same agent
> are being distinguished then it sounds like you actually have two
> logical DMA channels.
> 
> Could you elaborate on the qcom,ebi2-nand binding? From a brief read I'd
> expect you to have "txrx" and "cmd" dmas, rather than describing the
> CRCI information on the side.

The ADM does have physical channels, but when you utilize those channels you may
also need to describe the flow control used for specific transactions.  And this
flow control has to be configured for that specific transaction, if you are
interleaving different flow control origination/end points.

In the case of nand, they actually use different flow controls on the same
physical channel.  For UART/I2C/SPI, they use just one flow control identifier.

I see your point at specifying these as logical channels.  That is certainly a
possibility.  Then the ADM driver would just have to handle the logical channel
allocation.  That would remove the need for the slave_config being sent.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the 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

Re: [PATCH v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC

[Andrew F. Davis]

On 09/30/2015 12:28 PM, Mark Brown wrote:

On Tue, Sep 29, 2015 at 01:58:41PM -0500, Andrew F. Davis wrote:

On 09/29/2015 01:38 PM, Mark Brown wrote:



Oh, ick.  The binding has a compatible string in the individual
regulator bindings which is broken unless there really are lots of
variants being configured via DT (which is just not the case here).
It's not only more typing in the DT,



I don't see this, the alternative is matching to this "regulator-compatible",
why not just use the existing compatible.


No, you don't need to use regulator-compatible - that's deprecated.
Just use the node names.



Are we sure matching on node names is a good idea? Most are just arbitrary
names meant to be human readable and reference-able, giving them function
may lead to confusion. This seems to be why we have "compatible", for specific
identification of node function. But I'm new so maybe I'm wrong?


it also means that we can't read
back the configuration of the device unless the user goes and creates a
DT which explicitly lists each regulator on the device which is
unhelpful.  We should be able to read back the configurations of all the
regulators by simply listing the device in DT.



Could you expand this? I'm not sure I understand why we still cant do this
using this new way.


I'm not sure what there is to add...  if the regulator is only
instantiated when it features in the device tree then obviously it must
be included in the device to be instantiated.



This is already the case then, missing regulator nodes in old drivers will not
get instantiated ether. And old drivers don't always store any more info about
available regulators than mine does.


Bindings should have compatible strings when they describe hardware like this,
we can then do stuff like put the LDO and DCDC drivers in separate modules for
instance, letting DT only load what we need. There are other benefits like
not having to search our own DT binding for data, and we only get probed for
devices in the DT.


Only getting probed for device is in DT is exactly the problem here, and
nothing prevents us having separate modules for things without
enumerating everything in DT.



Sure, but then we have to do some fiddling with MFD_CORE to do that work,
why not remove the dependency and let DT do that for DT only drivers?


This also eliminates the need for MFD_CORE, we just call
of_platform_populate on ourself and DT helpers do the rest. Why hard code
mfd_cell's and do matching when DT does the same thing.


Putting everything in DT means more work for people integrating the
device and means that we have to have a full and complete understanding
of the device at the time we write the DT, including decions about how
we split the functionality of the device between subsystems.



We are not adding anything extra to the DT node, we just use the "compatible"
string to identify and match the node vs. "regulator-name", or the nodes name,
or whatever else has been used. The node is then just filled with the standard
optional properties just like every other driver's node.


The fact that this is different to the bindings for other regulator
drivers and requires more code ought to have been a big warning sign
here :(



The binding is the same as the new tps65218 driver, different isn't always
a warning sign. And what do you mean "requires more code"? This regulator
driver is smaller than almost any other. DT takes care of everything for
us relating to hardware instantiation like it should.


That's not a new driver, it's from more than a year ago (before or about
the same time the helpers got added IIRC).



Newer than a lot, I chose to base my driver off of that not just because
it is a similar TI part, but because it was the cleanest, simplest looking
one IMHO. The helpers would require more code (you need to know how many
regulators you have and call the helpers in a loop).

I have another PMIC I'm about to push a driver for when this gets figured out
that does the same thing, and it's more important I think to do it this way for
this new part. Some of the new regulators are designed without a dedicated
SOC or board to power in mind, so they will have a whole bunch for different
regulator types on one chip and it will be up to the designer to pick which ones
to turn on and use. With this DT approach you can just list the ones you want,
and we may even be able to split different types into different modules, then
we can use the same regulator driver in different spins of the PMIC with more
or less of that type of regulator, we just add that same node under a different
parent PMIC driver.

I could use the helper with this style and save a couple lines of code if we
could make regulator_of_get_init_data to also match on "compatible", it
currently only matches on "regulator-compatible" or the node name. I could make
this addition and send the patch if you would like to see what I have in mind.
--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH 3/4] net: phy: Add Broadcom phy library for common interfaces

[kbuild test robot]

Hi Arun,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: i386-randconfig-i1-201539 (attached as .config)
reproduce:
  git checkout 25a633b2114806a7ce7d4f171c4714880e2c721b
  # save the attached .config to linux build tree
  make ARCH=i386 

All error/warnings (new ones prefixed by >>):

>> ERROR: "bcm_phy_config_intr" [drivers/net/phy/broadcom.ko] undefined!
>> ERROR: "bcm_phy_ack_intr" [drivers/net/phy/broadcom.ko] undefined!
>> ERROR: "bcm_phy_read_exp" [drivers/net/phy/broadcom.ko] undefined!
>> ERROR: "bcm_phy_write_exp" [drivers/net/phy/broadcom.ko] undefined!
>> ERROR: "bcm_phy_read_shadow" [drivers/net/phy/broadcom.ko] undefined!
>> ERROR: "bcm_phy_write_shadow" [drivers/net/phy/broadcom.ko] undefined!
>> ERROR: "bcm_phy_enable_apd" [drivers/net/phy/bcm7xxx.ko] undefined!
>> ERROR: "bcm_phy_enable_eee" [drivers/net/phy/bcm7xxx.ko] undefined!
>> ERROR: "bcm_phy_write_misc" [drivers/net/phy/bcm7xxx.ko] undefined!
>> ERROR: "bcm_phy_write_exp" [drivers/net/phy/bcm7xxx.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH 0/4] Add support for Broadcom's iProc MDIO and Cygnus Ethernet PHY

[Arun Parameswaran]

Hi
This patchset adds support for the iProc MDIO interface and the
Broadcom Cygnus SoC's internal Ethernet PHY.

The internal Ethernet PHY(s) in the Cygnus SoC's are accessed
via the MDIO interface found in most of the iProc based chips.

The patch also consolidates the common API's used by the
Broadcom phys to a common library. Existing Broadcom phy
drivers have been modified to use the common library API's.

The Ethernet driver for the iProc family will be submitted soon,
as will the device tree configurations for the different iProc
family SoCs.

Arun Parameswaran (4):
  dt-bindings: net: Broadcom iProc MDIO bus driver device tree binding
  net: phy: Broadcom iProc MDIO bus driver
  net: phy: Add Broadcom phy library for common interfaces
  net: phy: Broadcom Cygnus internal Etherent PHY driver

 .../devicetree/bindings/net/brcm,iproc-mdio.txt|  23 +++
 drivers/net/phy/Kconfig|  28 +++
 drivers/net/phy/Makefile   |   3 +
 drivers/net/phy/bcm-cygnus.c   | 162 
 drivers/net/phy/bcm-phy-lib.c  | 209 
 drivers/net/phy/bcm-phy-lib.h  |  37 
 drivers/net/phy/bcm63xx.c  |  38 +---
 drivers/net/phy/bcm7xxx.c  | 127 +++-
 drivers/net/phy/broadcom.c | 149 +-
 drivers/net/phy/mdio-bcm-iproc.c   | 213 +
 include/linux/brcmphy.h|  24 +--
 11 files changed, 757 insertions(+), 256 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt
 create mode 100644 drivers/net/phy/bcm-cygnus.c
 create mode 100644 drivers/net/phy/bcm-phy-lib.c
 create mode 100644 drivers/net/phy/bcm-phy-lib.h
 create mode 100644 drivers/net/phy/mdio-bcm-iproc.c

-- 
2.5.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/4] dt-bindings: net: Broadcom iProc MDIO bus driver device tree binding

[Arun Parameswaran]

Add device tree binding documentation for the Broadcom iProc MDIO
bus driver.

Signed-off-by: Arun Parameswaran 
---
 .../devicetree/bindings/net/brcm,iproc-mdio.txt| 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt

diff --git a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt 
b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt
new file mode 100644
index 000..689f97c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt
@@ -0,0 +1,23 @@
+* Broadcom iProc MDIO bus controller
+
+Required properties:
+- compatible: should be "brcm,iproc-mdio"
+- reg: address and length of the register set for the MDIO interface
+- #size-cells: must be 1
+- #address-cells: must be 0
+
+Child nodes of this MDIO bus controller node are standard Ethernet PHY device
+nodes as described in Documentation/devicetree/bindings/net/phy.txt
+
+Example:
+
+mdio@0x18002000 {
+   compatible = "brcm,iproc-mdio";
+   reg = <0x18002000 0x8>;
+   #size-cells = <1>;
+   #address-cells = <0>;
+
+   enet-gphy@0 {
+   reg = <0>;
+   };
+};
-- 
2.5.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 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver

[Alexander Popov]

Hello Timur, thanks again for your review.

On 25.09.2015 04:01, Timur Tabi wrote:
> Alexander Popov wrote:
>> +
>> +for (i = 0; i < lpbfifo.cs_n; i++) {
>> +phys_addr_t cs_start;
>> +phys_addr_t cs_end;
>> +
>> +cs_start = lpbfifo.cs_ranges[i].addr;
>> +cs_end = cs_start + lpbfifo.cs_ranges[i].size - 1;
>> +
>> +if (lpbfifo.req->bus_phys >= cs_start &&
>> +lpbfifo.req->bus_phys + lpbfifo.req->size - 1 <= cs_end) {
>> +cs = lpbfifo.cs_ranges[i].csnum;
>> +break;
>> +}
>> +}
>> +if (i == lpbfifo.cs_n) {
> 
> Can you test for "!cs" here instead?
> 
>> +e = -EFAULT;
>> +goto err_param;
>> +}

Unfortunately no: 0 is a valid value for Chip Select.
Is it OK to leave it like that?

>> +
>> +/* 2. Prepare DMA */
>> +dma_dev = lpbfifo.chan->device;
>> +
>> +sg_init_table(, 1);
>> +if (lpbfifo.req->dir == MPC512X_LPBFIFO_REQ_DIR_WRITE)
>> +dir = DMA_TO_DEVICE;
>> +else
>> +dir = DMA_FROM_DEVICE;
>> +sg_dma_address() = dma_map_single(dma_dev->dev,
>> +lpbfifo.req->ram_virt, lpbfifo.req->size, dir);
>> +if (dma_mapping_error(dma_dev->dev, sg_dma_address())) {
>> +e = -EFAULT;
>> +goto err_param;
>> +}
>> +lpbfifo.ram_bus_addr = sg_dma_address(); /* For freeing later */
>> +sg_dma_len() = lpbfifo.req->size;
> 
> I don't think sg_dma_len() is meant to be used as an lvalue.

I've double-checked and found many cases of such usage of this macro.
It seems that I can't avoid it too.

>> +/*
>> + * The node defined as compatible with 'fsl,mpc5121-localbus'
>> + * should have 2 address cells and 1 size cell.
>> + * One item of its ranges property should consist of:
>> + * - the first address cell which is the chipselect number;
>> + * - the second address cell which is the offset in the chipselect,
>> + *must be zero.
>> + * - CPU address of the beginning of an access window;
>> + * - the only size cell which is the size of an access window.
>> + */
>> +addr_cells_p = of_get_property(lb_node, "#address-cells", NULL);
>> +size_cells_p = of_get_property(lb_node, "#size-cells", NULL);
>> +if (addr_cells_p == NULL || *addr_cells_p != 2 ||
>> +size_cells_p == NULL ||*size_cells_p != 1) {
>> +goto end1;
>> +}
> 
> Is this really necessary?

I'm not sure.

I've found a device tree node compatible with "fsl,mpc5121-localbus"
and I just check the format of "ranges" property before parsing it
because devicetree/bindings/powerpc/fsl/lbc.txt doesn't have details
about it.

Should I blindly assume that this property has 2 address cells and 1 size
cell?

> Can't you use the built-in OF functions for
> parsing ranges? 

I don't see anything to use instead of of_property_count_u32_elems() and
of_property_read_u32_array().

> Driver code that has to parse #address-cells or #size-cells
> is usually wrong.

I would not call it "parsing", I just check whether the dts-file is good.
Anyway, could you give me a clue how to do better?

>> +
>> +proplen = of_property_count_u32_elems(lb_node, "ranges");
>> +if (proplen < 0 || proplen % 4 != 0)
>> +goto end1;
>> +
>> +lpbfifo.cs_n = proplen / 4;
>> +lpbfifo.cs_ranges = kcalloc(lpbfifo.cs_n, sizeof(struct cs_range),
>> +GFP_KERNEL);
>> +if (!lpbfifo.cs_ranges)
>> +goto end1;
>> +
>> +if (of_property_read_u32_array(lb_node, "ranges",
>> +(u32 *)lpbfifo.cs_ranges, proplen) != 0) {
>> +goto end2;
>> +}
>> +
>> +for (i = 0; i < lpbfifo.cs_n; i++) {
>> +if (lpbfifo.cs_ranges[i].base != 0)
>> +goto end2;
>> +}
>> +
>> +res = 0;
>> + end2:
>> +if (res != 0)
>> +kfree(lpbfifo.cs_ranges);
>> + end1:
>> +of_node_put(lb_node);
>> + end0:
>> +return res;
>> +}

Best regards,
Alexander
--
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 4/4] net: phy: Broadcom Cygnus internal Etherent PHY driver

[Arun Parameswaran]

Add support for the Broadcom Cygnus SoCs internal PHY's.
The PHYs are 1000M/100M/10M capable with support for 'EEE'
and 'APD' (Auto Power Down).

This driver supports the following Broadcom Cygnus SoCs:
 - BCM583XX (BCM58300, BCM58302, BCM58303, BCM58305)
 - BCM113XX (BCM11300, BCM11320, BCM11350, BCM11360)

The PHY's on these SoC's require some workarounds for
stable operation, both during configuration time and
during suspend/resume. This driver handles the
application of the workarounds.

Signed-off-by: Arun Parameswaran 
---
 drivers/net/phy/Kconfig  |  13 
 drivers/net/phy/Makefile |   1 +
 drivers/net/phy/bcm-cygnus.c | 162 +++
 include/linux/brcmphy.h  |   2 +
 4 files changed, 178 insertions(+)
 create mode 100644 drivers/net/phy/bcm-cygnus.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 0c85a01..da979ec 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -79,6 +79,19 @@ config BROADCOM_PHY
  Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
  BCM5481 and BCM5482 PHYs.
 
+config BCM_CYGNUS_PHY
+   tristate "Drivers for Broadcom Cygnus SoC internal PHY"
+   depends on ARCH_BCM_CYGNUS || COMPILE_TEST
+   select BCM_NET_PHYLIB
+   select MDIO_BCM_IPROC
+   ---help---
+ This PHY driver is for the 1G internal PHYs of the Broadcom
+ Cygnus Family SoC.
+
+ Currently supports internal PHY's used in the BCM11300,
+ BCM11320, BCM11350, BCM11360, BCM58300, BCM58302,
+ BCM58303 & BCM58305 Broadcom Cygnus SoCs.
+
 config BCM63XX_PHY
tristate "Drivers for Broadcom 63xx SOCs internal PHY"
depends on BCM63XX
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 6932475..7655d47 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_BROADCOM_PHY)+= broadcom.o
 obj-$(CONFIG_BCM63XX_PHY)  += bcm63xx.o
 obj-$(CONFIG_BCM7XXX_PHY)  += bcm7xxx.o
 obj-$(CONFIG_BCM87XX_PHY)  += bcm87xx.o
+obj-$(CONFIG_BCM_CYGNUS_PHY)   += bcm-cygnus.o
 obj-$(CONFIG_ICPLUS_PHY)   += icplus.o
 obj-$(CONFIG_REALTEK_PHY)  += realtek.o
 obj-$(CONFIG_LSI_ET1011C_PHY)  += et1011c.o
diff --git a/drivers/net/phy/bcm-cygnus.c b/drivers/net/phy/bcm-cygnus.c
new file mode 100644
index 000..28bab20
--- /dev/null
+++ b/drivers/net/phy/bcm-cygnus.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/* Broadcom Cygnus SoC internal transceivers support. */
+#include "bcm-phy-lib.h"
+#include 
+#include 
+#include 
+#include 
+
+/* Broadcom Cygnus Phy specific registers */
+#define MII_BCM_CORE_BASE1E   0x1E /* Core BASE1E register */
+#define MII_BCM_EXPB0 0xB0 /* EXPB0 register */
+#define MII_BCM_EXPB1 0xB1 /* EXPB1 register */
+
+#define MII_BCM_CYGNUS_AFE_VDAC_ICTRL_0  0x91E5 /* VDAL Control register */
+
+static int bcm_cygnus_afe_config(struct phy_device *phydev)
+{
+   int rc;
+
+   /* ensure smdspclk is enabled */
+   rc = phy_write(phydev, MII_BCM54XX_AUX_CTL, 0x0c30);
+   if (rc < 0)
+   return rc;
+
+   /* AFE_VDAC_ICTRL_0 bit 7:4 Iq=1100 for 1g 10bt, normal modes */
+   rc = bcm_phy_write_misc(phydev, 0x39, 0x01, 0xA7C8);
+   if (rc < 0)
+   return rc;
+
+   /* AFE_HPF_TRIM_OTHERS bit11=1, short cascode enable for all modes*/
+   rc = bcm_phy_write_misc(phydev, 0x3A, 0x00, 0x0803);
+   if (rc < 0)
+   return rc;
+
+   /* AFE_TX_CONFIG_1 bit 7:4 Iq=1100 for test modes */
+   rc = bcm_phy_write_misc(phydev, 0x3A, 0x01, 0xA740);
+   if (rc < 0)
+   return rc;
+
+   /* AFE TEMPSEN_OTHERS rcal_HT, rcal_LT 1 */
+   rc = bcm_phy_write_misc(phydev, 0x3A, 0x03, 0x8400);
+   if (rc < 0)
+   return rc;
+
+   /* AFE_FUTURE_RSV bit 2:0 rccal <2:0>=100 */
+   rc = bcm_phy_write_misc(phydev, 0x3B, 0x00, 0x0004);
+   if (rc < 0)
+   return rc;
+
+   /* Adjust bias current trim to overcome digital offSet */
+   rc = phy_write(phydev, MII_BCM_CORE_BASE1E, 0x02);
+   if (rc < 0)
+   return rc;
+
+   /* make rcal=100, since rdb default is 000 */
+   rc = bcm_phy_write_exp(phydev, MII_BCM_EXPB1, 0x10);
+   if (rc < 0)
+   return rc;
+
+   /* CORE_EXPB0, Reset R_CAL/RC_CAL Engine */
+   rc = bcm_phy_write_exp(phydev, MII_BCM_EXPB0, 0x10);
+   if 

[PATCH 3/4] net: phy: Add Broadcom phy library for common interfaces

[Arun Parameswaran]

This patch adds the Broadcom phy library to consolidate common
interfaces shared by Broadcom phy's.

Moved the common interfaces to the 'bcm-phy-lib.c' and updated
the Broadcom PHY drivers to use the new APIs.

Signed-off-by: Arun Parameswaran 
---
 drivers/net/phy/Kconfig   |   6 ++
 drivers/net/phy/Makefile  |   1 +
 drivers/net/phy/bcm-phy-lib.c | 209 ++
 drivers/net/phy/bcm-phy-lib.h |  37 
 drivers/net/phy/bcm63xx.c |  38 +---
 drivers/net/phy/bcm7xxx.c | 127 ++---
 drivers/net/phy/broadcom.c| 149 +-
 include/linux/brcmphy.h   |  22 +
 8 files changed, 333 insertions(+), 256 deletions(-)
 create mode 100644 drivers/net/phy/bcm-phy-lib.c
 create mode 100644 drivers/net/phy/bcm-phy-lib.h

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index b57f6c2..0c85a01 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -69,8 +69,12 @@ config SMSC_PHY
---help---
  Currently supports the LAN83C185, LAN8187 and LAN8700 PHYs
 
+config BCM_NET_PHYLIB
+   bool
+
 config BROADCOM_PHY
tristate "Drivers for Broadcom PHYs"
+   select BCM_NET_PHYLIB
---help---
  Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
  BCM5481 and BCM5482 PHYs.
@@ -78,11 +82,13 @@ config BROADCOM_PHY
 config BCM63XX_PHY
tristate "Drivers for Broadcom 63xx SOCs internal PHY"
depends on BCM63XX
+   select BCM_NET_PHYLIB
---help---
  Currently supports the 6348 and 6358 PHYs.
 
 config BCM7XXX_PHY
tristate "Drivers for Broadcom 7xxx SOCs internal PHYs"
+   select BCM_NET_PHYLIB
---help---
  Currently supports the BCM7366, BCM7439, BCM7445, and
  40nm and 65nm generation of BCM7xxx Set Top Box SoCs.
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index f4e6eb9..6932475 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_QSEMI_PHY)   += qsemi.o
 obj-$(CONFIG_SMSC_PHY) += smsc.o
 obj-$(CONFIG_TERANETICS_PHY)   += teranetics.o
 obj-$(CONFIG_VITESSE_PHY)  += vitesse.o
+obj-$(CONFIG_BCM_NET_PHYLIB)   += bcm-phy-lib.o
 obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
 obj-$(CONFIG_BCM63XX_PHY)  += bcm63xx.o
 obj-$(CONFIG_BCM7XXX_PHY)  += bcm7xxx.o
diff --git a/drivers/net/phy/bcm-phy-lib.c b/drivers/net/phy/bcm-phy-lib.c
new file mode 100644
index 000..13e161e
--- /dev/null
+++ b/drivers/net/phy/bcm-phy-lib.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "bcm-phy-lib.h"
+#include 
+#include 
+#include 
+#include 
+
+#define MII_BCM_CHANNEL_WIDTH 0x2000
+#define BCM_CL45VEN_EEE_ADV   0x3c
+
+int bcm_phy_write_exp(struct phy_device *phydev, u16 reg, u16 val)
+{
+   int rc;
+
+   rc = phy_write(phydev, MII_BCM54XX_EXP_SEL, reg);
+   if (rc < 0)
+   return rc;
+
+   return phy_write(phydev, MII_BCM54XX_EXP_DATA, val);
+}
+EXPORT_SYMBOL_GPL(bcm_phy_write_exp);
+
+int bcm_phy_read_exp(struct phy_device *phydev, u16 reg)
+{
+   int val;
+
+   val = phy_write(phydev, MII_BCM54XX_EXP_SEL, reg);
+   if (val < 0)
+   return val;
+
+   val = phy_read(phydev, MII_BCM54XX_EXP_DATA);
+
+   /* Restore default value.  It's O.K. if this write fails. */
+   phy_write(phydev, MII_BCM54XX_EXP_SEL, 0);
+
+   return val;
+}
+EXPORT_SYMBOL_GPL(bcm_phy_read_exp);
+
+int bcm_phy_write_misc(struct phy_device *phydev,
+  u16 reg, u16 chl, u16 val)
+{
+   int rc;
+   int tmp;
+
+   rc = phy_write(phydev, MII_BCM54XX_AUX_CTL,
+  MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
+   if (rc < 0)
+   return rc;
+
+   tmp = phy_read(phydev, MII_BCM54XX_AUX_CTL);
+   tmp |= MII_BCM54XX_AUXCTL_ACTL_SMDSP_ENA;
+   rc = phy_write(phydev, MII_BCM54XX_AUX_CTL, tmp);
+   if (rc < 0)
+   return rc;
+
+   tmp = (chl * MII_BCM_CHANNEL_WIDTH) | reg;
+   rc = bcm_phy_write_exp(phydev, tmp, val);
+
+   return rc;
+}
+EXPORT_SYMBOL_GPL(bcm_phy_write_misc);
+
+int bcm_phy_read_misc(struct phy_device *phydev,
+ u16 reg, u16 chl)
+{
+   int rc;
+   int tmp;
+
+   rc = phy_write(phydev, MII_BCM54XX_AUX_CTL,
+  MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
+   if (rc < 0)
+   return rc;

Re: [PATCH v4 1/5] Documentation: add DT bindings for ARM SCPI sensors

[Punit Agrawal]

Rob Herring  writes:

> On Tue, Sep 15, 2015 at 11:50 AM, Punit Agrawal  wrote:
>> The System Control Processor (SCP) provides access to SoC sensors via
>> the System Control and Power Interface (SCPI) Message Protocol. Add
>> bindings to allow probing of these sensors. Also support referencing
>> of the sensors for setting up thermal zones via the thermal DT
>> bindings.
>>
>> Signed-off-by: Punit Agrawal 
>> Cc: Rob Herring 
>
> Acked-by: Rob Herring 

Thanks, Rob!

Sudeep, now that we have acks for all the patches, are you OK to take
this patchset along with your series adding support for SCPI?

Punit

>
>> Cc: Mark Rutland 
>> Cc: Sudeep Holla 
>> ---
>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 38 
>> ++
>>  1 file changed, 38 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt 
>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index f002460..86302de 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -72,8 +72,25 @@ Required sub-node properties:
>>  - compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
>>shared memory on Juno platforms
>>
>> +Sensor bindings for the sensors based on SCPI Message Protocol
>> +--
>> +SCPI provides an API to access the various sensors on the SoC.
>> +
>> +Required properties:
>> +- compatible : should be "arm,scpi-sensors".
>> +- #thermal-sensor-cells: should be set to 1. This property follows the
>> +thermal device tree bindings[2].
>> +
>> +Valid cell values are raw identifiers (Sensor
>> +ID) as used by the firmware. Refer to
>> +platform documentation for your
>> +implementation for the IDs to use. For Juno
>> +R0 and Juno R1 refer to [3].
>> +
>>  [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
>>  [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> +[2] Documentation/devicetree/bindings/thermal/thermal.txt
>> +[3] 
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
>>
>>  Example:
>>
>> @@ -122,6 +139,11 @@ scpi_protocol: scpi@2e00 {
>> clock-output-names = "pxlclk0", "pxlclk1";
>> };
>> };
>> +
>> +   scpi_sensors0: sensors {
>> +   compatible = "arm,scpi-sensors";
>> +   #thermal-sensor-cells = <1>;
>> +   };
>>  };
>>
>>  cpu@0 {
>> @@ -136,6 +158,17 @@ hdlcd@7ff6 {
>> clocks = <_clk 4>;
>>  };
>>
>> +thermal-zones {
>> +   soc_thermal {
>> +   polling-delay-passive = <100>;
>> +   polling-delay = <1000>;
>> +
>> +   /* sensor ID */
>> +   thermal-sensors = <_sensors0 3>;
>> +   ...
>> +   };
>> +};
>> +
>>  In the above example, the #clock-cells is set to 1 as required.
>>  scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0,
>>  1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0
>> @@ -148,3 +181,8 @@ scpi_dvfs i.e. "atlclk".
>>  Similarly the second example is hdlcd@7ff6 and it has pxlclk1 as input
>>  clock. '4' in the clock specifier here points to the second entry
>>  in the output clocks of scpi_clocks  i.e. "pxlclk1"
>> +
>> +The thermal-sensors property in the soc_thermal node uses the
>> +temperature sensor provided by SCP firmware to setup a thermal
>> +zone. The ID "3" is the sensor identifier for the temperature sensor
>> +as used by the firmware.
>> --
>> 2.5.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
--
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] soc: mediatek: Fix random hang up issue while kernel init

[Lucas Stach]

Hi Daniel,

Am Dienstag, den 29.09.2015, 18:25 +0800 schrieb Daniel Kurtz:
> Hi Matthias & Lucas,
> 
> On Sun, Sep 27, 2015 at 7:25 PM, Matthias Brugger
>  wrote:
> >
> >
> >
> > On 25/09/15 10:26, Lucas Stach wrote:
> >>
> >> Am Freitag, den 25.09.2015, 14:31 +0800 schrieb James Liao:
> >>>
> >>> In kernel late init, it turns off all unused clocks, which
> >>> needs to access subsystem registers such as VENC and VENC_LT.
> >>>
> >>> Accessing MT8173 VENC registers needs two top clocks, mm_sel and
> >>> venc_sel. Accessing VENC_LT registers needs mm_sel and venclt_sel.
> >>> So we need to keep these clocks on before accessing their registers.
> >>>
> >>> This patch keeps venc_sel / venclt_sel clock on when
> >>> VENC / VENC_LT's power is on, to prevent system hang up while
> >>> accessing its registeres.
> >>>
> >> This changes the binding of an existing driver, so it needs some more
> >> consideration. Are VENC_SEL and VENC_LT_SEL really direct clock inputs
> >> to the VENC module, or are they some kind of parent clock for one of the
> >> existing clocks used by the old VENC binding?
> >>
> >> If they are direct clock inputs to the VENC module, changing the binding
> >> might be still ok at that point, as there shouldn't be many users of
> >> that yet.
> 
> The MT8173 VENC subsystem clock registers are modeled by the vencsys
> clock-controller node:
> 
> vencsys: clock-controller@1800 {
>   compatible = "mediatek,mt8173-vencsys", "syscon";
>   reg = <0 0x1800 0 0x1000>;
>   #clock-cells = <1>;
> };
> 
> These registers, however, are only accessible if:
>   (a) the VENC power domain is enabled, and
>   (b) the "venc_sel" clock is enabled.
> 
> According to James, venc_sel is a direct clock input the VENC module,
> and it is an ancestor to some, but not all, of the subsystem clocks, in
> particular it is not an ancestor to "venc_cke0":
> 
>  static const struct mtk_gate venc_clks[] __initconst = {
>  GATE_VENC(CLK_VENC_CKE0, "venc_cke0", "mm_sel", 0),
>  GATE_VENC(CLK_VENC_CKE1, "venc_cke1", "venc_sel", 4),
>  GATE_VENC(CLK_VENC_CKE2, "venc_cke2", "venc_sel", 8),
>  GATE_VENC(CLK_VENC_CKE3, "venc_cke3", "venc_sel", 12),
>  };
> 
> If the VENC power domain is disabled, then accesses to the vencsys
> registers just silently fail (i.e., reads probably
> return all 0s). 

If this ever happens it is really unfortunate and needs fixing, too. If
you need the power domain to be powered ON to properly read or even
change the clock registers, the clock driver needs to be a consumer of
the power domain, so any clock operations powers the domain up.

> However, if the power domain is ON but venc_sel is
> disabled, then accessing the clock-controller registers results in a
> system hang (until the power domain is disabled).
> 
> At boot the VENC power domain is forced on by scpsys (like all other
> power domains).  Later both unused clocks and power domains get
> disabled. If clocks are disabled first, and venc_sel is disabled
> before venc_cke0, then when unused_clock tries to disable venc_cke0,
> the system will hang when it reads the vencsys "is clock enabled" bit
> since:
>   (a) VENC power domain is still enabled, and
>   (b) venc_sel is already disabled
> 
> In theory, we could add "clocks=< CLK_TOP_VENC_SEL>;" to the
> vencsys clock-controller node.  On initialization, mtk_vencsys_init()
> could then pass venc_sel to the generic MT8173 gate clock driver, and
> it would then clk_enable(venc_sel)/_disable(venc_sel) around any
> access to the clock-controller registers.  James, however, thinks
> this is a lot of extra overhead, and instead has proposed the fix in this 
> patch,
> where venc_sel is forced on whenever the VENC power domain is enabled.
> 
I would still say this is the correct solution. If the vencsys clock
registers are itself clocked by VENC_SEL this driver needs to make sure
this clock is running at the appropriate times. I understand that this
may be a bit of an overhead, but clock enable/disable paths are not
really performance critical.

> So, this patch is a bit of a hack, but the mtk scpsys driver already
> does something similar for the MM & MFG clocks - these clocks are
> always enabled whenever certain power domains are enabled, and they
> are only disabled when all such power domains are disabled.  I'm not
> 100% why these clocks must always be kept on whenever these power
> domains are enabled, but probably to solve a similar problem where
> these clocks are needed to access some registers at a time when these
> clocks would not otherwise be explicitly enabled.
> 
I can't really argue with this being the wrong solution if we already
have precedent of the same solution being used for other domains. But I
would still ask you to re-evaluate with the above in mind.

> Is the above clear?
> 
> >> But then we at least need a corresponding change to the binding 
> >> documentation.
> 
> Agreed.
> 
> > Yes, we will need a really good 

Re: [PATCH 0/3] ARM: dts: Various STi DT clean-ups

[Maxime Coquelin]

On 09/23/2015 09:37 PM, Maxime Coquelin wrote:

This series cleans the STi407 family DTs, by factorizing common nodes between
STiH407 and STiH410, and also by only enabling PWM and USB nodes at board
level, as they could not be exposed on some boards.

Maxime Coquelin (3):
   ARM: dts: stih407: Enable PWM nodes only board level
   ARM: dts: stih407/410: Tidy up display nodes
   ARM: dts: stih410: Enable USB2.0 and related PHY nodes at board level

  arch/arm/boot/dts/stih407-family.dtsi | 19 +--
  arch/arm/boot/dts/stih407.dtsi| 13 -
  arch/arm/boot/dts/stih410-b2120.dts   | 24 
  arch/arm/boot/dts/stih410.dtsi| 23 +++
  arch/arm/boot/dts/stihxxx-b2120.dtsi  |  8 
  5 files changed, 60 insertions(+), 27 deletions(-)


Thanks for the reviews.
Series applied to sti-dt-for-v4.4

Regards,
Maxime
--
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] serial: sh-sci: Add device tree support for r8a7795

[Geert Uytterhoeven]

From: Kuninori Morimoto 

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt 
b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index e84b13a8eda34a15..73f825e5e6448815 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -23,6 +23,8 @@ Required properties:
 - "renesas,scifa-r8a7794" for R8A7794 (R-Car E2) SCIFA compatible UART.
 - "renesas,scifb-r8a7794" for R8A7794 (R-Car E2) SCIFB compatible UART.
 - "renesas,hscif-r8a7794" for R8A7794 (R-Car E2) HSCIF compatible UART.
+- "renesas,scif-r8a7795" for R8A7795 (R-Car H3) SCIF compatible UART.
+- "renesas,hscif-r8a7795" for R8A7795 (R-Car H3) HSCIF compatible UART.
 - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART.
 - "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART.
 - "renesas,scif" for generic SCIF compatible UART.
-- 
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 8/8] arm64: dts: Add Hi6220 mtcmos regulator node

[Fei Wang]

This patch add mtcmos regulator dts file for Hi6220 SoC.

Signed-off-by: Fei Wang 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi |   21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 40f895b..9b1a6ed 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,6 +167,27 @@
clocks = <_ctrl 36>, <_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+   mtcmos {
+   compatible = "hisilicon,hi6220-mtcmos-driver";
+   hisilicon,mtcmos-steady-us = <10>;
+   hisilicon,mtcmos-sc-on-base  = <0xf780>;
+   hisilicon,mtcmos-acpu-on-base = <0xf65a>;
+
+   mtcmos1: regulator@a1{
+   regulator-name = "G3D_PD_VDD";
+   regulator-compatible = "mtcmos1";
+   hisilicon,ctrl-regs = <0x830 0x834 0x83c>;
+   hisilicon,ctrl-data = <1 0x1>;
+   };
+
+   mtcmos2: regulator@a2{
+   regulator-name = "SOC_MED";
+   regulator-compatible = "mtcmos2";
+   hisilicon,ctrl-regs = <0x830 0x834 0x83c>;
+   hisilicon,ctrl-data = <2 0x1>;
+   };
+   };
};
 
pmic: pmic@F800 {
-- 
1.7.9.5


--
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] thermal: Add Mediatek thermal controller support

[Punit Agrawal]

Sascha Hauer  writes:

> Hi Punit,
>
> On Wed, Sep 30, 2015 at 10:36:14AM +0100, Punit Agrawal wrote:
>> Hi Sascha,
>> 
>> Re-posting a comment from v7. Perhaps you missed it...
>
> Uh, sorry. In fact I didn't miss it and I thought I have answered it.
> Appearantly I haven't.
>
>> > +  struct mtk_thermal *mt = bank->mt;
>> > +  int temp, i, max;
>> > +  u32 raw;
>> > +
>> > +  temp = max = INT_MIN;
>> > +
>> > +  for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
>> > +  raw = readl(mt->thermal_base + sensing_points[i].msr);
>> > +
>> > +  temp = raw_to_mcelsius(mt, raw);
>> > +
>> > +  /*
>> > +   * The first read of a sensor often contains very high bogus
>> > +   * temperature value. Filter these out so that the system does
>> > +   * not immediately shut down.
>> > +   */
>> > +  if (temp > 20)
>> > +  temp = 0;
>> > +
>> 
>> If the bogus value is only the first time the sensor is read, instead of
>> filtering here, you could call mtk_thermal_bank_temperature at probe
>> time when you are initialising the banks and ignore the returned value.
>
> It seems that after initialization the hardware needs some time to
> settle before correct values can be read. Doing what you suggest would
> mean we have to delay the boot by several 100ms. I'd rather not do that.

Fair enough. Thanks for clarifying.

>
> Sascha
--
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 1/5] Input: goodix - reset device at init

[Bastien Nocera]

On Tue, 2015-09-29 at 17:47 +, Tirdea, Irina wrote:
> 
> > -Original Message-
> > From: Bastien Nocera [mailto:had...@hadess.net]
> > Sent: 29 September, 2015 5:04
> > To: Tirdea, Irina; linux-in...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org; Rob Herring; Pawel Moll; Ian
> > Campbell; Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark
> > Rutland; devicetree@vger.kernel.org
> > Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init
> > 
> > On Fri, 2015-09-25 at 21:04 +, Tirdea, Irina wrote:
> > > 
> 
> > > 
> > > The warning from your dmesg output will not cause probe to fail.
> > > If you look at the code for byt_gpio_direction_output, it will
> > > just
> > > print
> > > a warning and continue [1]:
> > >   WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN,
> > >   "Potential Error: Setting GPIO with direct_irq_en to
> > > output");
> > > I thought probe finishes successfully, but due to the warning in
> > > dmesg you
> > > are not sure whether the IRQ GPIO pin can be used as output.
> > > If probe fails, it must be for another reason than the
> > > direct_irq_en
> > > warning.
> > > 
> > > > Would you have a patch for me to test that would bypass this
> > > > error,
> > > > or
> > > > at least fallback gracefully to not resetting, not probing
> > > > GPIOs if
> > > > they're badly setup?
> > > 
> > > If the driver fails to initialize the GPIOs, it will at least
> > > print
> > > some
> > > "Failed to get GPIO" warnings in dmesg. Do you have such messages
> > > in
> > > dmesg or any additional information on why probe fails?
> > > 
> > > The current code will ignore GPIOs if they are not defined in
> > > ACPI
> > > (see the check for -ENOENT), but does not ignore other error
> > > codes.
> > > If you want to bypass all GPIO errors, you can use the code
> > > below.
> > 
> > The failure isn't there, it's when running goodix_i2c_test():
> > Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: i2c test
> > failed attempt 1: -121
> > Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: i2c test
> > failed attempt 2: -121
> > Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: I2C
> > communication failure: -121
> > Sep 25 16:39:20 winbook kernel: Goodix-TS: probe of i2c-GDIX1001:00 
> > failed with error -121
> > 
> 
> Are you using v6 of the patches? There was an issue with reset that
> Aleksei reported
> and was fixed in v6 (although he had a different i2c error and a
> different scenario).

Pretty certain. Your current patchset is at:
https://github.com/hadess/gt9xx/tree/irina-tirdea

And the patches are yours, with the prefix and Documentation removed.

> > The GPIO setup seems to work (bar the warnings), and the reset as
> > well,
> > but then the device fails to communicate. Likely a fallout from the
> > reset actually failing.
> > 
> > Swapping around the RST and INT pins leads to the same problem.
> > Either
> > this device's GPIO PINs aren't actually functional, and the
> > firmware
> > contains garbage, or something else is wrong.
> > 
> 
> I agree. Either the interrupt pin cannot be used as output in your
> configuration
> or there are some specifics in the ACPI tables that prevent using
> these pins. 
> 
> > I'm not sure how we can detect, and blacklist, those devices. At
> > least
> > my original device, the Onda v975w, and the WinBook TW100 would
> > have
> > those problems.
> > 
> 
> I can use DMI quirks to exclude these devices from using the features
> that
> depend on the gpio pins. I already have the DMI information for
> WinBook TW100
> and WinBook TW700. Could you tell me the DMI_SYS_VENDOR and
> DMI_PRODUCT_NAME for Onda v975w so I can add it as well?

I don't have access to the Onda v975w anymore, but let me CC: a few
people that could also help with testing.

Carlos, Cosimo, Christian, there's a patchset for you to test on the
Onda v975w at:
https://github.com/hadess/gt9xx/commits/irina-tirdea

Doing an "rmmod goodix ; insmod ./goodix_backport.ko" should be enough
to test whether the patch set works. If it doesn't work correctly,
you'll need to reboot the machine, swap the irq_idx and rst_idx values
at:
https://github.com/hadess/gt9xx/commit/c27de79f494c2b2e7a198ff4d27976ae93669dbd#diff-dddc2849e36327439530f3e2faacec4fR321

and try again.

If all that fails, could you please send the output of "dmidecode" to
Irina?

Cheers
--
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] i2c: at91: add DT property for the HOLD field of TWIHS_CWGR

[Cyrille Pitchen]

Hi all,

it looks good to me.

Le 30/09/2015 10:47, Ludovic Desroches a écrit :
> From: Wenyou Yang 
> 
> Add the HOLD field setting in order to support I2C slave devices which need
> a longer hold time of the data.
> Since it depends on the slave devices connected to the bus, add a DT
> property "atmel,twd-hold-cycles" to specify this HOLD field.
> 
> Signed-off-by: Wenyou Yang 
> Signed-off-by: Ludovic Desroches 

Acked-by: Cyrille Pitchen 

> ---
>  drivers/i2c/busses/i2c-at91.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index 1c758cd..06e66ef 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -64,6 +64,7 @@
>  #define  AT91_TWI_IADR   0x000c  /* Internal Address Register */
>  
>  #define  AT91_TWI_CWGR   0x0010  /* Clock Waveform Generator Reg 
> */
> +#define  AT91_TWI_CWGR_HOLD(x)   (((x) & 0x1f) << 24)
>  
>  #define  AT91_TWI_SR 0x0020  /* Status Register */
>  #define  AT91_TWI_TXCOMP BIT(0)  /* Transmission Complete */
> @@ -185,7 +186,8 @@ static void at91_init_twi_bus(struct at91_twi_dev *dev)
>   * Calculate symmetric clock as stated in datasheet:
>   * twi_clk = F_MAIN / (2 * (cdiv * (1 << ckdiv) + offset))
>   */
> -static void at91_calc_twi_clock(struct at91_twi_dev *dev, int twi_clk)
> +static void at91_calc_twi_clock(struct at91_twi_dev *dev,
> + int twi_clk, u32 twd_hold)
>  {
>   int ckdiv, cdiv, div;
>   struct at91_twi_pdata *pdata = dev->pdata;
> @@ -204,7 +206,9 @@ static void at91_calc_twi_clock(struct at91_twi_dev *dev, 
> int twi_clk)
>   cdiv = 255;
>   }
>  
> - dev->twi_cwgr_reg = (ckdiv << 16) | (cdiv << 8) | cdiv;
> + dev->twi_cwgr_reg = (ckdiv << 16) | (cdiv << 8) | cdiv
> + | AT91_TWI_CWGR_HOLD(twd_hold);
> +
>   dev_dbg(dev->dev, "cdiv %d ckdiv %d\n", cdiv, ckdiv);
>  }
>  
> @@ -936,6 +940,7 @@ static int at91_twi_probe(struct platform_device *pdev)
>   int rc;
>   u32 phy_addr;
>   u32 bus_clk_rate;
> + u32 twd_hold_cycles;
>  
>   dev = devm_kzalloc(>dev, sizeof(*dev), GFP_KERNEL);
>   if (!dev)
> @@ -992,7 +997,12 @@ static int at91_twi_probe(struct platform_device *pdev)
>   if (rc)
>   bus_clk_rate = DEFAULT_TWI_CLK_HZ;
>  
> - at91_calc_twi_clock(dev, bus_clk_rate);
> + rc = of_property_read_u32(dev->dev->of_node,
> +   "atmel,twd-hold-cycles", _hold_cycles);
> + if (rc)
> + twd_hold_cycles = 0;
> +
> + at91_calc_twi_clock(dev, bus_clk_rate, twd_hold_cycles);
>   at91_init_twi_bus(dev);
>  
>   snprintf(dev->adapter.name, sizeof(dev->adapter.name), "AT91");
> 

--
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] thermal: Add Mediatek thermal controller support

[Punit Agrawal]

Hi Sascha,

Re-posting a comment from v7. Perhaps you missed it...

Sascha Hauer  writes:

> This adds support for the Mediatek thermal controller found on MT8173
> and likely other SoCs.
> The controller is a bit special. It does not have its own ADC, instead
> it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> we need the physical address of the AUXADC. Also it controls a mux
> using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
>
> Signed-off-by: Sascha Hauer 
> Reviewed-by: Daniel Kurtz 
> ---
>  drivers/thermal/Kconfig   |   8 +
>  drivers/thermal/Makefile  |   1 +
>  drivers/thermal/mtk_thermal.c | 537 
> ++
>  3 files changed, 546 insertions(+)
>  create mode 100644 drivers/thermal/mtk_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 0390044..dadd1eb 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -348,6 +348,14 @@ config INTEL_PCH_THERMAL
> Thermal reporting device will provide temperature reading,
> programmable trip points and other information.
>  
> +config MTK_THERMAL
> + tristate "Temperature sensor driver for mediatek SoCs"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + default y
> + help
> +   Enable this option if you want to have support for thermal management
> +   controller present in Mediatek SoCs
> +
>  menu "Texas Instruments thermal drivers"
>  source "drivers/thermal/ti-soc-thermal/Kconfig"
>  endmenu
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 26f1608..5f979e7 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -45,3 +45,4 @@ obj-$(CONFIG_INTEL_PCH_THERMAL) += intel_pch_thermal.o
>  obj-$(CONFIG_ST_THERMAL) += st/
>  obj-$(CONFIG_TEGRA_SOCTHERM) += tegra_soctherm.o
>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
> +obj-$(CONFIG_MTK_THERMAL)+= mtk_thermal.o
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> new file mode 100644
> index 000..6be1a6c
> --- /dev/null
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -0,0 +1,537 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Hanyi Wu 
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* AUXADC Registers */
> +#define AUXADC_CON0_V0x000
> +#define AUXADC_CON1_V0x004
> +#define AUXADC_CON1_SET_V0x008
> +#define AUXADC_CON1_CLR_V0x00c
> +#define AUXADC_CON2_V0x010
> +#define AUXADC_DATA(channel) (0x14 + (channel) * 4)
> +#define AUXADC_MISC_V0x094
> +
> +#define AUXADC_CON1_CHANNEL(x)   BIT(x)
> +
> +#define APMIXED_SYS_TS_CON1  0x604
> +
> +/* Thermal Controller Registers */
> +#define TEMP_MONCTL0 0x000
> +#define TEMP_MONCTL1 0x004
> +#define TEMP_MONCTL2 0x008
> +#define TEMP_MONIDET00x014
> +#define TEMP_MONIDET10x018
> +#define TEMP_MSRCTL0 0x038
> +#define TEMP_AHBPOLL 0x040
> +#define TEMP_AHBTO   0x044
> +#define TEMP_ADCPNP0 0x048
> +#define TEMP_ADCPNP1 0x04c
> +#define TEMP_ADCPNP2 0x050
> +#define TEMP_ADCPNP3 0x0b4
> +
> +#define TEMP_ADCMUX  0x054
> +#define TEMP_ADCEN   0x060
> +#define TEMP_PNPMUXADDR  0x064
> +#define TEMP_ADCMUXADDR  0x068
> +#define TEMP_ADCENADDR   0x074
> +#define TEMP_ADCVALIDADDR0x078
> +#define TEMP_ADCVOLTADDR 0x07c
> +#define TEMP_RDCTRL  0x080
> +#define TEMP_ADCVALIDMASK0x084
> +#define TEMP_ADCVOLTAGESHIFT 0x088
> +#define TEMP_ADCWRITECTRL0x08c
> +#define TEMP_MSR00x090
> +#define TEMP_MSR10x094
> +#define TEMP_MSR20x098
> +#define TEMP_MSR30x0B8
> +
> +#define TEMP_SPARE0  0x0f0
> +
> +#define PTPCORESEL   0x400
> +
> +#define TEMP_MONCTL1_PERIOD_UNIT(x)  ((x) & 0x3ff)
> +
> +#define TEMP_MONCTL2_FILTER_INTERVAL(x)  (((x) & 0x3ff)) << 16
> +#define TEMP_MONCTL2_SENSOR_INTERVAL(x)  ((x) & 0x3ff)
> +
> +#define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)(x)
> +
> +#define TEMP_ADCWRITECTRL_ADC_PNP_WRITE  BIT(0)
> +#define 

Re: [PATCH v6 0/22] On-demand device probing

[Greg Kroah-Hartman]

On Wed, Sep 30, 2015 at 12:09:27PM +0200, Tomeu Vizoso wrote:
> On 26 September 2015 at 21:22, Greg Kroah-Hartman
>  wrote:
> > On Sat, Sep 26, 2015 at 01:17:04PM -0500, Rob Herring wrote:
> >> On 09/21/2015 09:02 AM, Tomeu Vizoso wrote:
> >> > Hello,
> >> >
> >> > I have a problem with the panel on my Tegra Chromebook taking longer
> >> > than expected to be ready during boot (Stéphane Marchesin reported what
> >> > is basically the same issue in [0]), and have looked into ordered
> >> > probing as a better way of solving this than moving nodes around in the
> >> > DT or playing with initcall levels and linking order.
> >> >
> >> > While reading the thread [1] that Alexander Holler started with his
> >> > series to make probing order deterministic, it occurred to me that it
> >> > should be possible to achieve the same by probing devices as they are
> >> > referenced by other devices.
> >> >
> >> > This basically reuses the information that is already implicit in the
> >> > probe() implementations, saving us from refactoring existing drivers or
> >> > adding information to DTBs.
> >> >
> >> > During review of v1 of this series Linus Walleij suggested that it
> >> > should be the device driver core to make sure that dependencies are
> >> > ready before probing a device. I gave this idea a try [2] but Mark Brown
> >> > pointed out to the logic duplication between the resource acquisition
> >> > and dependency discovery code paths (though I think it's fairly minor).
> >> >
> >> > To address that code duplication I experimented with Arnd's devm_probe
> >> > [3] concept of having drivers declare their dependencies instead of
> >> > acquiring them during probe, and while it worked [4], I don't think we
> >> > end up winning anything when compared to just probing devices on-demand
> >> > from resource getters.
> >> >
> >> > One remaining objection is to the "sprinkling" of calls to
> >> > of_device_probe() in the resource getters of each subsystem, but I think
> >> > it's the right thing to do given that the storage of resources is
> >> > currently subsystem-specific.
> >> >
> >> > We could avoid the above by moving resource storage into the core, but I
> >> > don't think there's a compelling case for that.
> >> >
> >> > I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
> >> > OMAP SoCs, and these patches were enough to eliminate all the deferred
> >> > probes (except one in PandaBoard because omap_dma_system doesn't have a
> >> > firmware node as of yet).
> >> >
> >> > Have submitted a branch [5][6][7] with these patches on top of today's
> >> > linux-next (20150921) to kernelci.org and I don't see any issues that
> >> > could be caused by them.
> >> >
> >> > With this series I get the kernel to output to the panel in 0.5s,
> >> > instead of 2.8s.
> >>
> >> I think we're pretty close other than some minor comments. I would like
> >> to see ack's from Greg and some reviewed-bys from others. The subsystem
> >> changes are minor and there has been plenty of chance to comment, so I
> >> don't think acks from all subsystems are needed.
> >>
> >> Your branch is based on -next. Is there any dependence on something in
> >> -next? I want to get this into -next soon, but need a branch not based
> >> on -next. Please send me a pull request with the collected acks and
> >> minor comments I have addressed.
> >
> > Let me review this on Monday and I'll let you know...
> 
> Hi Greg, hope you don't mind that I ping you regarding this, just in
> case it fell through some crack.

It's on my todo list, sorry, am at a conference for the next few days,
didn't get to it on Monday, hopefully soon...

greg "my todo list is too long" k-h
--
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/8] Add Support for Hi6220 PMIC Hi6553 MFD Core and Regulator

[Fei Wang]

The patch sets add support for Hi6220 PMIC Hi655x MFD core and its regulator 
driver.
Current testing and support board is Hikey  which is one of Linaro 96boards.
It is an arm64 open source board. For more information about this board,
please access https://www.96boards.org.

This is hardware layout for access PMIC Hi655x from AP SoC Hi6220.
Between PMIC Hi655x and Hi6220, the physical signal channel is SSI.We can use 
memory-mapped I/O to communicate.

++ +-+
|| | |
|Hi6220  |   SSI bus   |   Hi655x|
||-| |
||(REGMAP_MMIO)| |
++ +-+

This patchset are based on 4.3-rc1.

Fei Wang (8):
  dt-bindings: pmic: Document Hi655x pmic driver
  mfd: Hi655x: Add support for PMIC Hi655x MFD
  arm64: dts: add Hi655x pmic node
  regulator: Hi655x: Add support for Hi655x regulator
  arm64: dts: Add Hi655x regulator config node
  dt-bindings: mtcmos: Document Hi6220 mtcmos driver
  mtcmos: Hi6220: Add Hi6220 mtcmos regulator driver
  arm64: dts: Add Hi6220 mtcmos regulator node

 .../devicetree/bindings/mfd/hisilicon,hi655x.txt   |   80 +++
 .../bindings/regulator/hisilicon,hi6220-mtcmos.txt |   32 ++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  275 +++
 drivers/mfd/Kconfig|9 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/hi655x-pmic.c  |  358 ++
 drivers/regulator/Kconfig  |   16 +
 drivers/regulator/Makefile |2 +
 drivers/regulator/hi6220-mtcmos.c  |  281 +++
 drivers/regulator/hi655x-regulator.c   |  517 
 include/linux/mfd/hi655x-pmic.h|   56 +++
 include/linux/regulator/hi655x-regulator.h |   69 +++
 12 files changed, 1696 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
 create mode 100644 drivers/mfd/hi655x-pmic.c
 create mode 100644 drivers/regulator/hi6220-mtcmos.c
 create mode 100644 drivers/regulator/hi655x-regulator.c
 create mode 100644 include/linux/mfd/hi655x-pmic.h
 create mode 100644 include/linux/regulator/hi655x-regulator.h

-- 
1.7.9.5


--
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] ARM: shmobile: r8a7794: add USB PHY DT support

[Sergei Shtylyov]

Hello.

On 9/30/2015 11:33 AM, Simon Horman wrote:


Define the R8A7794 generic part of the USB PHY device node. It is up to the
board file to enable the device.

Signed-off-by: Sergei Shtylyov 

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

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -690,6 +690,25 @@
 0x1000 0 0 2  0 113 IRQ_TYPE_LEVEL_HIGH>;
};

+   usbphy: usb-phy@e6590100 {
+   compatible = "renesas,usb-phy-r8a7794";
+   reg = <0 0xe6590100 0 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <_clks R8A7794_CLK_HSUSB>;
+   clock-names = "usbhs";


Forgot to add "power-domains" prop here. :-(


Are you planning to repost this?


   Yes.

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

Re: [PATCH] ARM: STi: DT: STiH407: Rename incorrect interrupt related binding

[Maxime Coquelin]

Hi Lee,

On 09/29/2015 10:52 AM, Lee Jones wrote:

interrupts-names => interrupt-names

Signed-off-by: Lee Jones 
---
  arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)




Good spot!
Applied to sti-dt-for-v4.4.

thanks,
Maxime
--
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 2/4] PCI: st: Add Device Tree bindings for sti pcie

[Gabriel Fernandez]

Hi Rob,

Thanks for the review.

Best regards

Gabriel

On 28 August 2015 at 02:06, Rob Herring  wrote:
> On Thu, Aug 27, 2015 at 7:34 AM, Gabriel Fernandez
>  wrote:
>> sti pcie is built around a Synopsis Designware PCIe IP.
>>
>> Signed-off-by: Fabrice Gasnier 
>> Signed-off-by: Gabriel Fernandez 
>> ---
>>  Documentation/devicetree/bindings/pci/st-pcie.txt | 53 
>> +++
>>  1 file changed, 53 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/pci/st-pcie.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/st-pcie.txt 
>> b/Documentation/devicetree/bindings/pci/st-pcie.txt
>> new file mode 100644
>> index 000..25fcab3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/st-pcie.txt
>> @@ -0,0 +1,53 @@
>> +STMicroelectronics STi PCIe controller
>> +
>> +This PCIe host controller is based on the Synopsis Designware PCIe IP
>> +and thus inherits all the common properties defined in designware-pcie.txt.
>> +
>> +Required properties:
>> + - compatible: "st,stih407-pcie"
>
> What about "snps,dw-pcie" as well?
>
You are right.

>> + - reg: base address and length of the pcie controller, mem-window address
>> +   and length available to the controller.
>
> What is mem-window? Seems rather large and perhaps should be under ranges.
>
No the purpose is to specify the physical memory available to the controller.
reg property is more appropriate.

>> + - interrupts: A list of interrupt outputs of the controller. Must contain 
>> an
>> +   entry for each entry in the interrupt-names property.
>
> Define how many interrupts.
>
ok i will fix it.

>> + - interrupt-names: Should be "msi". STi interrupt that is asserted when an
>> +   MSI is received.
>
> Kind of pointless with a single interrupt.
>
ok

>> + - st,syscfg : should be a phandle of the syscfg node. Also contains syscfg
>> +   offset for IP configuration.
>> + - resets, reset-names: the power-down and soft-reset lines of PCIe IP.
>> +   Associated names must be "powerdown" and "softreset".
>> + - phys, phy-names: the phandle for the PHY device.
>> +   Associated name must be "pcie"
>
> What does this mean?
>
i will reformulate this paragraph.

>> +
>> +Optional properties:
>> + - reset-gpio: a GPIO spec to define which pin is connected to the bus 
>> reset.
>> +
>> +Example:
>> +
>> +pcie0: pcie@9b0 {
>> +   compatible = "st,pcie", "snps,dw-pcie";
>> +   device_type = "pci";
>> +   reg = <0x09b0 0x4000>,  /* dbi cntrl registers */
>> + <0x2fff 0x0001>,  /* configuration space */
>> + <0x4000 0x8000>;  /* lmi mem window */
>> +   reg-names = "dbi", "config", "mem-window";
>> +   st,syscfg = <_core 0xd8 0xe0>;
>> +   #address-cells = <3>;
>> +   #size-cells = <2>;
>> +   ranges = <0x8200 0 0x2000 0x2000 0 0x0FFF>; /* 
>> non-prefetchable memory */
>
> No i/o support?
>
Exactly there is no i/o support.

>> +   num-lanes = <1>;
>> +   interrupts = ;
>> +   interrupt-names = "msi";
>> +   #interrupt-cells = <1>;
>> +   interrupt-map-mask = <0 0 0 7>;
>> +   interrupt-map = <0 0 0 1  GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, /* 
>> INT A */
>> +   <0 0 0 2  GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, /* 
>> INT B */
>> +   <0 0 0 3  GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>, /* 
>> INT C */
>> +   <0 0 0 4  GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>; /* 
>> INT D */
>> +
>> +   resets = < STIH407_PCIE0_POWERDOWN>,
>> +< STIH407_PCIE0_SOFTRESET>;
>> +   reset-names = "powerdown",
>> + "softreset";
>> +   phys = <_port0 PHY_TYPE_PCIE>;
>> +   phy-names = "pcie";
>> +};
>> --
>> 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 v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Yakir Yang]

Hi Krzysztof,

On 09/30/2015 04:26 PM, Krzysztof Kozlowski wrote:

On 30.09.2015 17:20, Yakir Yang wrote:

Hi Krzysztof,

On 09/30/2015 03:34 PM, Krzysztof Kozlowski wrote:

On 30.09.2015 16:19, Yakir Yang wrote:

Hi Krzysztof,

On 09/30/2015 01:32 PM, Krzysztof Kozlowski wrote:

On 22.09.2015 16:37, Yakir Yang wrote:

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.

But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
   to get the backword timing values.

Okay


Krzysztof suggest me that driver could use
   the "of_property_read_bool" to get backword timing values, but that interfacs
   would modify the original drm_display_mode timing directly (whether those
   properties exists or not).

Hmm, I don't understand. You have a:
struct video_info {
bool h_sync_polarity;
bool v_sync_polarity;
bool interlaced;
};

so what is wrong with:
dp_video_config->h_sync_polarity =
of_property_read_bool(dp_node, "hsync-active-high");

Is it exactly the same binding as previously?

Yes, it is the same binding as previously. But just a note that we already
mark those DT binding as deprecated.

+-interlaced:deprecated prop that can parsed frm drm_display_mode.
+-vsync-active-high: deprecated prop that can parsed frm drm_display_mode.
+-hsync-active-high: deprecated prop that can parsed frm drm_display_mode.


For now those values should come from "struct drm_display_mode",
and we already parsed them out from "drm_display_mode" before
driver provide the backward compatibility.

Let's used the "hsync-active-high" example:
 As for now the code would like:
 static void analogix_dp_bridge_mode_set(...)
 {
 // Parsed timing value from "drm_display_mode"
 video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);

 // Try to detect the deprecated property, providing
 // the backward compatibility
 of_property_read_u32(dp_node, "hsync-active-high",
  >h_sync_polarity);

 /*
  * In this case, if "hsync-active-high" property haven't been
  * found, then the video timing "h_sync_polarity" would  keep
  * no change, keeping the parsed value from "drm_display_mode"
  */
 }

 But if keep the "of_property_read_bool", then code would like:
 static void analogix_dp_bridge_mode_set(...)
 {
 // Parsed timing value from "drm_display_mode"
 video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);

 // Try to detect the deprecated property, providing
 // the backward compatibility
 video->h_sync_polarity =
 of_property_read_bool(dp_node, "hsync-active-high");



 /*
  * In this case, if "hsync-active-high" property haven't been
  * found, then the video timing "h_sync_polarity" would just
  * modify to "false". That is the place we don't want, cause
  * it would always modify the timing value parsed from
  * "drm_display_mode"
  */
 }


OK, I see the point of overwriting values from drm_display_mode. However
I think you changed the binding. I believe the of_property_read_u32()
will behave differently for such DTS:

exynos_dp {
...
hsync-active-high;
}

It will return -EOVERFLOW which means it would be broken now...

Whoops, thanks for your remind, after try that, I do see over flow error.
static void *of_find_property_value_of_size(const struct device_node *np,
 const char *propname, u32 len)
{
 
 if (len > prop->length)
 return ERR_PTR(-EOVERFLOW);
 ...
}

So I though code should be:
 if (of_property_read_bool(dp_node, "hsync-active-high"))
 video->h_sync_polarity = true;

Looks good.


And we can't provide full backward compatibility for this property, cause
the previous exynos_dp driver would set this timing value to "false" when
property not defined, but analogix_dp driver keep this timing value
corresponding to "drm_display_mode" when property not found.

Indeed, the behaviour changes. I don't know if this is important issue...


Hmm... as I know the timing polarity would influence something like:
- CTS test
- HDCP function

But I though it's more likely that driver would made those functions 
failed if

hard code the timing polarity.

And I think it would be better to get timing polarity from 
"drm_display_mode".

Caused the analogix_dp driver have called the drm_add_edid_modes() that
function would parse the EDID "detailed timing" block 

Re: [PATCH v5 2/4] Documentation: arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

Thanks Ben for the details.

On Wed, Sep 30, 2015 at 5:58 AM, Benjamin Herrenschmidt
 wrote:
> On Tue, 2015-09-29 at 14:08 +0530, Ganapatrao Kulkarni wrote:
>> (sending again, by mistake it was set to html mode)
>
> The representation consists of a hierarchy of domains, the idea being
> that resources are grouped in domains of similar average performance
> relative to each other.
>
> The platform decides which "levels" of that hierarchy are significant.
>
> The "ibm,associativity" property allows to determine the associatitivy
> between two resources (ie nodes) at a given level.
>
> Unfortunately that property went through changes, so another property
> in the DT (ibm,architecture-vec-5) contains, among a bunch of other
> things, a bit indicating which form of the ibm,associativity property
> is used. I'm going to stick to the new "form 1" in this description.
>
> The ibm,associativity contains one or more lists of numbers (32-bit
> cells), which represent the domains:
>
> < C1 , L1_1, L1_2, ... , C2, L2_1, L2_2, ... >
>
> Where C1 (count 1) is the number of items for list 1, and L1_1,
> L1_2, ... L1_C1 are the items for list 1, and same for C2/L2.
can you please put some examples for more clarity.
>
> The entries in those lists are domain numbers from the highest level of
> grouping to the lowest (successive numbers are sub divisions)
> for example drawer#, socket#, chip#, core#... with the lowest level
> being the actual resource itself. So within a domain that last number
> is generally unique.
>
> Different resources can have different number of levels, for example if
> we have a grouping of node,socket,chip,core, a CPU core node would have
> a list with all 4 but a memory controller on a chip might have only the
> first 3.
can you please put some examples for more clarity.
>
> This is an important statement in the spec:
>
> <<
> The user of this information is cautioned not to imply
> any specific physical/logical significance of the various intermediate
> levels.
>>>
>
> We can have multiple lists because a given resource can be connected
> via multiple path in the same platform.
>
> That means that to properly calculate the distance to another resource,
> all the path need to be looked at (assuming the HW will pick the
> shortest).
>
> Additionally, to help the OS, another property "ibm,associativity
> -reference-points" property indicates which levels (which indices in
> the above lists) are of biggest significance to the platform. This can
> typically be used by an OS to decide what to consider a "NUMA node"
> if the OS cannot operate on distances alone. This is a list of 1-based
> numbers representing indices in the associativity list. They should
> be in order of significance of the boundary.
some examples please.
>
> Finally, the ibm,max-associativity-domains (in the /rtas node on
> pseries) is an array of cells < C, M1, M2, ... MC > (first is
> count) containing for each domain/level the max number supported
> by the platform.
max number of what/cpu?
how this helps?
please give some examples to understand this!
>
> Ben.
>
>> On Tue, Sep 29, 2015 at 2:05 PM, Ganapatrao Kulkarni
>>  wrote:
>> > Hi Mark,
>> >
>> > I have tried to answer your comments, in the meantime we are
>> > waiting for Ben
>> > to share the details.
>> >
>> > On Fri, Aug 28, 2015 at 6:02 PM, Mark Rutland > > > wrote:
>> > >
>> > > Hi,
>> > >
>> > > On Fri, Aug 14, 2015 at 05:39:32PM +0100, Ganapatrao Kulkarni
>> > > wrote:
>> > > > DT bindings for numa map for memory, cores and IOs using
>> > > > arm,associativity device node property.
>> > >
>> > > Given this is just a copy of ibm,associativity, I'm not sure I
>> > > see much
>> > > point in renaming the properties.
>> > >
>> > > However, (somewhat counter to that) I'm also concerned that this
>> > > isn't
>> > > sufficient for systems we're beginning to see today (more on that
>> > > below), so I don't think a simple copy of ibm,associativity is
>> > > good
>> > > enough.
>> >
>> > it is just copy right now, however it can evolve when we come
>> > across more
>> > arm64 numa platforms
>> > >
>> > >
>> > > >
>> > > > Signed-off-by: Ganapatrao Kulkarni <
>> > > > gkulka...@caviumnetworks.com>
>> > > > ---
>> > > >  Documentation/devicetree/bindings/arm/numa.txt | 212
>> > > > +
>> > > >  1 file changed, 212 insertions(+)
>> > > >  create mode 100644
>> > > > Documentation/devicetree/bindings/arm/numa.txt
>> > > >
>> > > > diff --git a/Documentation/devicetree/bindings/arm/numa.txt
>> > > > b/Documentation/devicetree/bindings/arm/numa.txt
>> > > > new file mode 100644
>> > > > index 000..dc3ef86
>> > > > --- /dev/null
>> > > > +++ b/Documentation/devicetree/bindings/arm/numa.txt
>> > > > @@ -0,0 +1,212 @@
>> > > >
>> > > > +==
>> > > > 
>> > > > +NUMA binding description.
>> > > >
>> > > > 

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

[Roger Quadros]

Tony,

On 18/09/15 17:53, 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

I've verified this series with the following boards
-dra7-evm
-am437x-gp-evm
-am335x-evm
-beagleboard-c4

For legacy boot I've checked only on beagleboard-c4.

Test procedure was to read an existing ubifs partition,
create a new one and read it back.

Need you to Ack if it looks good.
Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
parts?

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.
> 
> Roger Quadros (27):
>   ARM: OMAP2+: gpmc: Add platform data
>   ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
>   memory: omap-gpmc: Introduce GPMC to NAND interface
>   mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers
>   memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status
>   mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty
> check
>   memory: omap-gpmc: Remove NAND IRQ code
>   memory: omap-gpmc: Add IRQ ops for GPMC-NAND interface
>   mtd: nand: omap2: manage NAND interrupts
>   mtd: nand: omap: Copy platform data parameters to omap_nand_info data
>   mtd: nand: omap: Clean up device tree support
>   mtd: nand: omap: Update DT binding documentation
>   memory: omap-gpmc: Prevent mapping into 1st 16MB
>   memory: omap-gpmc: Move device tree binding to correct location
>   memory: omap-gpmc: Support general purpose input for WAITPINs
>   memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring
>   memory: omap-gpmc: Add irqchip support to the gpiochip
>   mtd: nand: omap2: Implement NAND ready using gpiolib
>   memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via
> gpmc_regs
>   ARM: dts: dra7: Fix NAND device nodes.
>   ARM: dts: dra7x-evm: Provide NAND ready pin
>   ARM: dts: am437x: Fix NAND device nodes
>   ARM: dts: am437x-gp-evm: Provide NAND ready pin
>   ARM: dts: am335x: Fix NAND device nodes
>   ARM: dts: am335x: Provide NAND ready pin
>   ARM: dts: dm816x: Fix gpmc and NAND node
>   ARM: dts: omap3: Fix gpmc and NAND nodes
> 
>  Documentation/devicetree/bindings/bus/ti-gpmc.txt  | 130 -
>  .../bindings/memory-controllers/omap-gpmc.txt  | 130 +
>  .../devicetree/bindings/mtd/gpmc-nand.txt  |  16 +-
>  arch/arm/boot/dts/am335x-chilisom.dtsi |   7 +-
>  arch/arm/boot/dts/am335x-evm.dts   |   7 +-
>  arch/arm/boot/dts/am335x-igep0033.dtsi |   7 +-
>  arch/arm/boot/dts/am33xx.dtsi  |   4 +
>  arch/arm/boot/dts/am4372.dtsi  |   4 +
>  arch/arm/boot/dts/am437x-gp-evm.dts|   8 +-
>  arch/arm/boot/dts/am43x-epos-evm.dts   |   8 +-
>  arch/arm/boot/dts/dm8168-evm.dts   |   7 +-
>  arch/arm/boot/dts/dm816x.dtsi  |   4 +
>  arch/arm/boot/dts/dra7-evm.dts |   6 +-
>  arch/arm/boot/dts/dra7.dtsi|   4 +
>  arch/arm/boot/dts/dra72-evm.dts|   6 +-
>  arch/arm/boot/dts/logicpd-torpedo-som.dtsi |   7 +-
>  arch/arm/boot/dts/omap3-beagle.dts |   2 +
>  arch/arm/boot/dts/omap3-cm-t3x.dtsi|   5 +-
>  arch/arm/boot/dts/omap3-devkit8000-common.dtsi |   3 +
>  arch/arm/boot/dts/omap3-evm-37xx.dts   |   7 +-
>  arch/arm/boot/dts/omap3-gta04.dtsi |   3 +
>  arch/arm/boot/dts/omap3-igep.dtsi  |   5 +-
>  arch/arm/boot/dts/omap3-igep0020-common.dtsi   |   4 +-
>  arch/arm/boot/dts/omap3-igep0030-common.dtsi   |   4 +
>  arch/arm/boot/dts/omap3-ldp.dts|  

[PATCH 3/8] arm64: dts: add Hi655x pmic node

[Fei Wang]

This patch add Hi655x device node for pmic in dts.

Signed-off-by: Fei Wang 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi |9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..4e4830b 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -168,4 +168,13 @@
clock-names = "uartclk", "apb_pclk";
};
};
+
+   pmic: pmic@F800 {
+compatible = "hisilicon,hi655x-pmic-driver";
+reg = <0x0 0xf800 0x0 0x1000>;
+#interrupt-cells = <2>;
+interrupt-controller;
+pmu_irq_gpio = <_pmu_irq_n>;
+status = "ok";
+   };
 };
-- 
1.7.9.5


--
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 0/22] On-demand device probing

[Tomeu Vizoso]

On 26 September 2015 at 21:22, Greg Kroah-Hartman
 wrote:
> On Sat, Sep 26, 2015 at 01:17:04PM -0500, Rob Herring wrote:
>> On 09/21/2015 09:02 AM, Tomeu Vizoso wrote:
>> > Hello,
>> >
>> > I have a problem with the panel on my Tegra Chromebook taking longer
>> > than expected to be ready during boot (Stéphane Marchesin reported what
>> > is basically the same issue in [0]), and have looked into ordered
>> > probing as a better way of solving this than moving nodes around in the
>> > DT or playing with initcall levels and linking order.
>> >
>> > While reading the thread [1] that Alexander Holler started with his
>> > series to make probing order deterministic, it occurred to me that it
>> > should be possible to achieve the same by probing devices as they are
>> > referenced by other devices.
>> >
>> > This basically reuses the information that is already implicit in the
>> > probe() implementations, saving us from refactoring existing drivers or
>> > adding information to DTBs.
>> >
>> > During review of v1 of this series Linus Walleij suggested that it
>> > should be the device driver core to make sure that dependencies are
>> > ready before probing a device. I gave this idea a try [2] but Mark Brown
>> > pointed out to the logic duplication between the resource acquisition
>> > and dependency discovery code paths (though I think it's fairly minor).
>> >
>> > To address that code duplication I experimented with Arnd's devm_probe
>> > [3] concept of having drivers declare their dependencies instead of
>> > acquiring them during probe, and while it worked [4], I don't think we
>> > end up winning anything when compared to just probing devices on-demand
>> > from resource getters.
>> >
>> > One remaining objection is to the "sprinkling" of calls to
>> > of_device_probe() in the resource getters of each subsystem, but I think
>> > it's the right thing to do given that the storage of resources is
>> > currently subsystem-specific.
>> >
>> > We could avoid the above by moving resource storage into the core, but I
>> > don't think there's a compelling case for that.
>> >
>> > I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
>> > OMAP SoCs, and these patches were enough to eliminate all the deferred
>> > probes (except one in PandaBoard because omap_dma_system doesn't have a
>> > firmware node as of yet).
>> >
>> > Have submitted a branch [5][6][7] with these patches on top of today's
>> > linux-next (20150921) to kernelci.org and I don't see any issues that
>> > could be caused by them.
>> >
>> > With this series I get the kernel to output to the panel in 0.5s,
>> > instead of 2.8s.
>>
>> I think we're pretty close other than some minor comments. I would like
>> to see ack's from Greg and some reviewed-bys from others. The subsystem
>> changes are minor and there has been plenty of chance to comment, so I
>> don't think acks from all subsystems are needed.
>>
>> Your branch is based on -next. Is there any dependence on something in
>> -next? I want to get this into -next soon, but need a branch not based
>> on -next. Please send me a pull request with the collected acks and
>> minor comments I have addressed.
>
> Let me review this on Monday and I'll let you know...

Hi Greg, hope you don't mind that I ping you regarding this, just in
case it fell through some crack.

Regards,

Tomeu

> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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 v5 2/4] Documentation: arm64/arm: dt bindings for numa.

[Mark Rutland]

On Tue, Sep 29, 2015 at 09:38:04AM +0100, Ganapatrao Kulkarni wrote:
> (sending again, by mistake it was set to html mode)
> 
> On Tue, Sep 29, 2015 at 2:05 PM, Ganapatrao Kulkarni
>  wrote:
> > Hi Mark,
> >
> > I have tried to answer your comments, in the meantime we are waiting for Ben
> > to share the details.
> >
> > On Fri, Aug 28, 2015 at 6:02 PM, Mark Rutland  wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Aug 14, 2015 at 05:39:32PM +0100, Ganapatrao Kulkarni wrote:
> >> > DT bindings for numa map for memory, cores and IOs using
> >> > arm,associativity device node property.
> >>
> >> Given this is just a copy of ibm,associativity, I'm not sure I see much
> >> point in renaming the properties.
> >>
> >> However, (somewhat counter to that) I'm also concerned that this isn't
> >> sufficient for systems we're beginning to see today (more on that
> >> below), so I don't think a simple copy of ibm,associativity is good
> >> enough.
> >
> > it is just copy right now, however it can evolve when we come across more
> > arm64 numa platforms

Whatever we do I suspect we'll have to evolve it as new platforms
appear. As I mentioned there are contemporary NUMA ARM64 platforms (e.g.
those with CCN) that I don't think we can ignore now given we'll have to
cater for them.

> >> > +==
> >> > +2 - arm,associativity
> >> >
> >> > +==
> >> > +The mapping is done using arm,associativity device property.
> >> > +this property needs to be present in every device node which needs to
> >> > to be
> >> > +mapped to numa nodes.
> >>
> >> Can't there be some inheritance? e.g. all devices on a bus with an
> >> arm,associativity property being assumed to share that value?
> >
> > yes there is inheritance and respective bus drivers should take care of it,
> > like pci driver does at present.

Ok. 

That seems counter to my initial interpretation of the wording that the
property must be present on device nodes that need to be mapped to NUMA
nodes.

Is there any simple way of describing the set of nodes that need this
property?

> >> > +topology and boundary in the system at which a significant difference
> >> > in
> >> > +performance can be measured between cross-device accesses within
> >> > +a single location and those spanning multiple locations.
> >> > +The first cell always contains the broadest subdivision within the
> >> > system,
> >> > +while the last cell enumerates the individual devices, such as an SMT
> >> > thread
> >> > +of a CPU, or a bus bridge within an SoC".
> >>
> >> While this gives us some hierarchy, this doesn't seem to encode relative
> >> distances at all. That seems like an oversight.
> >
> >
> > distance is computed, will add the details to document.
> > local nodes will have distance as 10(LOCAL_DISTANCE) and every level, the
> > distance multiplies by 2.
> > for example, for level 1 numa topology, distance from local node to remote
> > node will be 20.

This seems arbitrary.

Why not always have this explicitly described?

> >> Additionally, I'm somewhat unclear on how what you'd be expected to
> >> provide for this property in cases like ring or mesh interconnects,
> >> where there isn't a strict hierarchy (see systems with ARM's own CCN, or
> >> Tilera's TILE-Mx), but there is some measure of closeness.
> >
> >
> > IIUC, as per ARMs CCN architecture, all core/clusters are at equal distance
> > of DDR, i dont see any NUMA topology.

The CCN is a ring interconnect, so CPU clusters (henceforth CPUs) can be
connected with differing distances to RAM instances (or devices).

Consider the simplified network below:

  +---+  ++  +---+
  | CPU 0 |--| DRAM A |--| CPU 1 |
  +---+  ++  +---+
  |  |
  |  |
  ++ ++
  | DRAM B | | DRAM C |
  ++ ++
  |  |
  |  |
  +---+  ++  +---+
  | CPU 2 |--| DRAM D |--| CPU 3 |
  +---+  ++  +---+

In this case CPUs and DRAMs are spaced evenly on the ring, but the
distance between an arbitrary CPU and DRAM is not uniform.

CPU 0 can access DRAM A or DRAM B with a single hop, but accesses to
DRAM C or DRAM D take three hops.

An access from CPU 0 to DRAM C could contend with accesses from CPU 1 to
DRAM D, as they share hops on the ring.

There is definitely a NUMA topology here, but there's not a strict
hierarchy. I don't see how you would represent this with the proposed
binding.

Likewise for the mesh networks (e.g. that of TILE-Mx)

> > however, if there are 2 SoC connected thorough the CCN, then it is very much
> > similar to cavium topology.
> >
> >> Must all of 

[PATCH v4 0/3] ARM: uniphier: add outer cache support and rework SMP operations

[Masahiro Yamada]

Hi Olof,

Now Linux 4.3-rc1 is out, so I am back to this.

1/3: add outer cache support
2/3: rework SMP operations
3/3: add device tree nodes

Because 2/3 highly depends on 1/3, I hope whole of this series
is applied through ARM-SOC tree.


Changes in v4:
  - Add more detailed comments to explain why no spin lock is needed
  - Add two examples to the binding document

Changes in v3:
  - Drop bogus includes

Changes in v2:
  - Use pr_fmt() to have pr_ are automatically prefixed
  - Re-design to initialize the outer cache earlier in init_IRQ()
  - Require DT properties such as "cacne-unified", "cache-size",
"cache-sets", "cache-size", "cache-line-size".
  - Follow "next-level-cache" property to search further outer caches

Masahiro Yamada (3):
  ARM: uniphier: add outer cache support
  ARM: uniphier: rework SMP operations to use trampoline code
  ARM: dts: uniphier: add outer cache controller nodes

 .../bindings/arm/uniphier/cache-uniphier.txt   |  60 +++
 MAINTAINERS|   2 +
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi|  13 +
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi   |  14 +
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi   |  27 +
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi   |  14 +
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi   |  13 +
 arch/arm/boot/dts/uniphier-proxstream2.dtsi|  16 +
 arch/arm/include/asm/hardware/cache-uniphier.h |  46 ++
 arch/arm/kernel/irq.c  |   3 +
 arch/arm/mach-uniphier/Makefile|   2 +-
 arch/arm/mach-uniphier/headsmp.S   |  43 ++
 arch/arm/mach-uniphier/platsmp.c   | 185 +--
 arch/arm/mm/Kconfig|  10 +
 arch/arm/mm/Makefile   |   1 +
 arch/arm/mm/cache-uniphier.c   | 554 +
 16 files changed, 972 insertions(+), 31 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
 create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h
 create mode 100644 arch/arm/mach-uniphier/headsmp.S
 create mode 100644 arch/arm/mm/cache-uniphier.c

-- 
1.9.1

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

[PATCH v4 1/3] ARM: uniphier: add outer cache support

[Masahiro Yamada]

This commit adds support for UniPhier outer cache controller.
All the UniPhier SoCs are equipped with the L2 cache, while the L3
cache is currently only integrated on PH1-Pro5 SoC.

Signed-off-by: Masahiro Yamada 
Acked-by: Rob Herring 
---

 .../bindings/arm/uniphier/cache-uniphier.txt   |  60 +++
 MAINTAINERS|   2 +
 arch/arm/include/asm/hardware/cache-uniphier.h |  46 ++
 arch/arm/kernel/irq.c  |   3 +
 arch/arm/mm/Kconfig|  10 +
 arch/arm/mm/Makefile   |   1 +
 arch/arm/mm/cache-uniphier.c   | 554 +
 7 files changed, 676 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
 create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h
 create mode 100644 arch/arm/mm/cache-uniphier.c

diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt 
b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
new file mode 100644
index 000..668a18f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
@@ -0,0 +1,60 @@
+UniPhier outer cache controller
+
+UniPhier SoCs are integrated with a full-custom outer cache controller system.
+All of them have a level 2 cache controller, and some have a level 3 cache
+controller as well.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-cache"
+- reg: offsets and lengths of the register sets for the device.  It should
+  contain 3 regions: control register, revision register, operation register,
+  in this order.
+- cache-unified: specifies the cache is a unified cache.
+- cache-size: specifies the size in bytes of the cache
+- cache-sets: specifies the number of associativity sets of the cache
+- cache-line-size: specifies the line size in bytes
+- cache-level: specifies the level in the cache hierarchy.  The value should
+  be 2 for L2 cache, 3 for L3 cache, etc.
+
+Optional properties:
+- next-level-cache: phandle to the next level cache if present.  The next level
+  cache should be also compatible with "socionext,uniphier-system-cache".
+
+The L2 cache must exist to use the L3 cache; the cache hierarchy must be
+indicated correctly with "next-level-cache" properties.
+
+Example 1 (L2 for outer cache):
+   l2: l2-cache@500c {
+   compatible = "socionext,uniphier-system-cache";
+   reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+   cache-unified;
+   cache-size = <0x20>;
+   cache-sets = <512>;
+   cache-line-size = <128>;
+   cache-level = <2>;
+   };
+
+Example 2 (L2 and L3 for outer cache):
+   l2: l2-cache@500c {
+   compatible = "socionext,uniphier-system-cache";
+   reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+   cache-unified;
+   cache-size = <0x20>;
+   cache-sets = <512>;
+   cache-line-size = <128>;
+   cache-level = <2>;
+   next-level-cache = <>;
+   };
+
+   l3: l3-cache@500c8000 {
+   compatible = "socionext,uniphier-system-cache";
+   reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
+ <0x506c8000 0x400>;
+   cache-unified;
+   cache-size = <0x40>;
+   cache-sets = <512>;
+   cache-line-size = <256>;
+   cache-level = <3>;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 9f6685f..bced05f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1606,7 +1606,9 @@ M:Masahiro Yamada 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/boot/dts/uniphier*
+F: arch/arm/include/asm/hardware/cache-uniphier.h
 F: arch/arm/mach-uniphier/
+F: arch/arm/mm/cache-uniphier.c
 F: drivers/pinctrl/uniphier/
 F: drivers/tty/serial/8250/8250_uniphier.c
 N: uniphier
diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h 
b/arch/arm/include/asm/hardware/cache-uniphier.h
new file mode 100644
index 000..102e3fb
--- /dev/null
+++ b/arch/arm/include/asm/hardware/cache-uniphier.h
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * 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 

[PATCH v4 3/3] ARM: dts: uniphier: add outer cache controller nodes

[Masahiro Yamada]

Add L2 cache controller nodes for all the UniPhier SoC DTSI.
Also, add an L3 cache controller node for PH1-Pro5 DTSI.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 13 +
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 14 ++
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 27 +++
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 14 ++
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 13 +
 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 16 
 6 files changed, 97 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index a6a185f..ae13469 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -55,6 +55,7 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+   next-level-cache = <>;
};
};
 
@@ -91,6 +92,18 @@
#size-cells = <1>;
};
 
+   l2: l2-cache@500c {
+   compatible = "socionext,uniphier-system-cache";
+   reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+   interrupts = <0 174 4>, <0 175 4>;
+   cache-unified;
+   cache-size = <(512 * 1024)>;
+   cache-sets = <256>;
+   cache-line-size = <128>;
+   cache-level = <2>;
+   };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index e8bbc45..85377b2 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+   next-level-cache = <>;
};
 
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+   next-level-cache = <>;
};
};
 
@@ -98,6 +100,18 @@
#size-cells = <1>;
};
 
+   l2: l2-cache@500c {
+   compatible = "socionext,uniphier-system-cache";
+   reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+   interrupts = <0 174 4>, <0 175 4>;
+   cache-unified;
+   cache-size = <(768 * 1024)>;
+   cache-sets = <256>;
+   cache-line-size = <128>;
+   cache-level = <2>;
+   };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 59c2b12..96da01e 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+   next-level-cache = <>;
};
 
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+   next-level-cache = <>;
};
};
 
@@ -98,6 +100,31 @@
#size-cells = <1>;
};
 
+   l2: l2-cache@500c {
+   compatible = "socionext,uniphier-system-cache";
+   reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+   interrupts = <0 190 4>, <0 191 4>;
+   cache-unified;
+   cache-size = <(2 * 1024 * 1024)>;
+   cache-sets = <512>;
+   cache-line-size = <128>;
+   cache-level = <2>;
+   next-level-cache = <>;
+   };
+
+   l3: l3-cache@500c8000 {
+   compatible = "socionext,uniphier-system-cache";
+   reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
+ <0x506c8000 0x400>;
+   interrupts = <0 174 4>, <0 175 4>;
+   cache-unified;
+

Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey

[Lee Jones]

On Tue, 29 Sep 2015, Dmitry Torokhov wrote:

> On Mon, Sep 28, 2015 at 08:19:27AM +, Opensource [Steve Twiss] wrote:
> > 
> > > Subject: Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings 
> > > for DA9062 OnKey
> > > 
> > > On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> > > > On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > > > > From: S Twiss 
> > > > >
> > > > > Add device tree bindings for the DA9062 OnKey driver component
> > > > >
> > > > > Signed-off-by: Steve Twiss 
> > > > >
> > > > > ---
> > > > > Changes in V3:
> > > > >  - Child driver specifics separated out into separate document
> > > > >in this case ../input/da9062-onkey.txt
> > > > > Changes in V2:
> > > > >  - No change
> > > > >
> > > > > This patch applies against linux-next and next-20150708
> > > > >
> > > > >
> > > > >  .../devicetree/bindings/input/da9062-onkey.txt | 36
> > > ++
> > > > >  Documentation/devicetree/bindings/mfd/da9062.txt   |  3 ++
> > > >
> > > > I dropped bits for mfd/da9062.txt, changed to mention both 9062 and
> > > > 9063, folded into the onkey patch and applied.
> > > 
> > > Argh, da9062 core is not in mainline yet... OK, below is the patch I
> > > had; if Lee does not pick it up I'll re-apply it when da9062 core hits
> > > mainline.
> > > 
> > 
> > Hi Lee and Dmitry,
> > 
> > This patch seems to have been missed. It is the main OnKey driver for 
> > DA9062 and this
> > component was waiting for the DA9062 MFD core to make it into 
> > linux-mainline/v4.3-rc1.
> > 
> > Is there any reply on this yet please? There just seems to be a little 
> > patch administration
> > problem holding things up.
> 
> I queued it for 4.4.

Thanks Dmitry.

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

Re: [PATCH v4 3/4] PCI: st: Provide support for the sti PCIe controller

[Gabriel Fernandez]

Hi Pratyush,

Thanks for the review.

Best regards

Gabriel

On 27 August 2015 at 19:31, Pratyush Anand  wrote:
> Hi Gabriel,
>
> Looks good to me.
>
> On Thu, Aug 27, 2015 at 6:04 PM, Gabriel Fernandez
>  wrote:
>> sti pcie is built around a Synopsis Designware PCIe IP.
>>
>> Signed-off-by: Fabrice Gasnier 
>> Signed-off-by: Gabriel Fernandez 
>
>
>> +static int st_pcie_link_up(struct pcie_port *pp)
>> +{
>> +   u32 status;
>> +   int link_up;
>
> nit: why not bool

i prefer to keep it as 'int' because the prototype of link_up callback
is an 'int'.

>
>> +   int count = 0;
>
> [...]
>
>> +static void st_pcie_board_reset(struct pcie_port *pp)
>> +{
>> +   struct st_pcie *pcie = to_st_pcie(pp);
>> +
>> +   if (!gpio_is_valid(pcie->reset_gpio))
>> +   return;
>> +
>> +   if (gpio_direction_output(pcie->reset_gpio, 0)) {
>> +   dev_err(pp->dev, "Cannot set PERST# (gpio %u) to output\n",
>> +   pcie->reset_gpio);
>> +   return;
>> +   }
>> +
>> +   /* From PCIe spec */
>> +   msleep(2);
>> +   gpio_direction_output(pcie->reset_gpio, 1);
>> +
>> +   /*
>> +* PCIe specification states that you should not issue any config
>> +* requests until 100ms after asserting reset, so we enforce that 
>> here
>> +*/
>> +   msleep(100);
>
> IIRC, specification says to wait after link training completes. So
> shouldn't it be after st_pcie_enable_ltssm. Moreover, I wonder why
> others do not need it.
>
Ok i will fix it.

> Reviewed-by: Pratyush Anand 
--
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

[PATCHv4 3/3] devicetree: Add led-backlight binding

[Tomi Valkeinen]

Add DT binding for led-backlight.

Signed-off-by: Tomi Valkeinen 
Cc: devicetree@vger.kernel.org
---
 .../bindings/video/backlight/led-backlight.txt | 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/backlight/led-backlight.txt

diff --git 
a/Documentation/devicetree/bindings/video/backlight/led-backlight.txt 
b/Documentation/devicetree/bindings/video/backlight/led-backlight.txt
new file mode 100644
index ..d4621d7414bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/led-backlight.txt
@@ -0,0 +1,30 @@
+led-backlight bindings
+
+Required properties:
+  - compatible: "led-backlight"
+  - leds: phandle to a led OF node [0]
+  - brightness-levels: Array of distinct LED brightness levels. These
+  are in the range from 0 to 255, passed to the LED class driver.
+  - default-brightness-level: the default brightness level (index into the
+  array defined by the "brightness-levels" property)
+
+Optional properties:
+  - power-supply: regulator for supply voltage
+  - enable-gpios: contains a single GPIO specifier for the GPIO which enables
+  and disables the backlight (see GPIO binding[1])
+
+[0]: Documentation/devicetree/bindings/leds/common.txt
+[1]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+
+   backlight {
+   compatible = "led-backlight";
+   leds = <_led>;
+
+   brightness-levels = <0 4 8 16 32 64 128 255>;
+   default-brightness-level = <6>;
+
+   power-supply = <_bl_reg>;
+   enable-gpios = < 58 0>;
+   };
-- 
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 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

Hi Punit,

On Wed, Sep 30, 2015 at 10:36:14AM +0100, Punit Agrawal wrote:
> Hi Sascha,
> 
> Re-posting a comment from v7. Perhaps you missed it...

Uh, sorry. In fact I didn't miss it and I thought I have answered it.
Appearantly I haven't.

> > +   struct mtk_thermal *mt = bank->mt;
> > +   int temp, i, max;
> > +   u32 raw;
> > +
> > +   temp = max = INT_MIN;
> > +
> > +   for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
> > +   raw = readl(mt->thermal_base + sensing_points[i].msr);
> > +
> > +   temp = raw_to_mcelsius(mt, raw);
> > +
> > +   /*
> > +* The first read of a sensor often contains very high bogus
> > +* temperature value. Filter these out so that the system does
> > +* not immediately shut down.
> > +*/
> > +   if (temp > 20)
> > +   temp = 0;
> > +
> 
> If the bogus value is only the first time the sensor is read, instead of
> filtering here, you could call mtk_thermal_bank_temperature at probe
> time when you are initialising the banks and ignore the returned value.

It seems that after initialization the hardware needs some time to
settle before correct values can be read. Doing what you suggest would
mean we have to delay the boot by several 100ms. I'd rather not do that.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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 4/8] regulator: Hi655x: Add support for Hi655x regulator

[Fei Wang]

Add Hi655x regulator driver.

Signed-off-by: Fei Wang 
---
 drivers/regulator/Kconfig  |8 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/hi655x-regulator.c   |  517 
 include/linux/regulator/hi655x-regulator.h |   69 
 4 files changed, 595 insertions(+)
 create mode 100644 drivers/regulator/hi655x-regulator.c
 create mode 100644 include/linux/regulator/hi655x-regulator.h

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 64bccff..d13210b 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -261,6 +261,14 @@ config REGULATOR_HI6421
  21 general purpose LDOs, 3 dedicated LDOs, and 5 BUCKs. All
  of them come with support to either ECO (idle) or sleep mode.
 
+config REGULATOR_HI655X
+tristate "Hisilicon HI655X PMIC regulators support"
+depends on ARCH_HISI
+   depends on MFD_HI655X_PMIC && OF
+help
+  This driver provides support for the voltage regulators of the
+  Hisilicon Hi655x PMIC device.
+
 config REGULATOR_ISL9305
tristate "Intersil ISL9305 regulator"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 0f81749..8e4db96 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
 obj-$(CONFIG_REGULATOR_FAN53555) += fan53555.o
 obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
 obj-$(CONFIG_REGULATOR_HI6421) += hi6421-regulator.o
+obj-$(CONFIG_REGULATOR_HI655X) += hi655x-regulator.o
 obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
 obj-$(CONFIG_REGULATOR_ISL9305) += isl9305.o
 obj-$(CONFIG_REGULATOR_LP3971) += lp3971.o
diff --git a/drivers/regulator/hi655x-regulator.c 
b/drivers/regulator/hi655x-regulator.c
new file mode 100644
index 000..3423a84
--- /dev/null
+++ b/drivers/regulator/hi655x-regulator.c
@@ -0,0 +1,517 @@
+/*
+ * Device driver for regulators in HI655X IC
+ *
+ * Copyright (c) 2015 Hisilicon.
+ *
+ * Fei Wang 
+ *
+ * this regulator's probe function will be called lots of times,,
+ * because of there are lots of regulator nodes in dtb.
+ * so,that's say, the driver must be inited before the regulator nodes
+ * registor to system.
+ *
+ * Makefile have proved my guess, please refor to the makefile.
+ * when the code is rebuild i hope we can build pmu sub_system.
+ * init order can not base on compile
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_VALUE_SETBITS(reg_value, pos, bits, bits_value) \
+   (reg_value = (reg_value & \
+   ~unsigned int)1 << bits) - 1) << pos)) | \
+   ((unsigned int)(bits_value & \
+   (((unsigned int)1 << bits) - 1)) << pos))
+
+#define REG_VALUE_GETBITS(reg_value, pos, bits) \
+   ((reg_value >> pos) & (((unsigned int)1 << bits) - 1))
+
+static int hi655x_regulator_pmic_is_enabled(struct regulator_dev *rdev)
+{
+   int ret = 0;
+   unsigned int value = 0;
+
+   struct hi655x_regulator *sreg = rdev_get_drvdata(rdev);
+   struct hi655x_regulator_ctrl_regs  *ctrl_regs = &(sreg->ctrl_regs);
+   struct hi655x_regulator_ctrl_data  *ctrl_data = &(sreg->ctrl_data);
+
+   /*
+   * regulator is all set,but the pmu is only subset.
+   * maybe this "buck"/"ldo"/"lvs" is not contrl by a core.
+   * and in regulator have a "status" member ("okey" or "disable").
+   */
+   regmap_read(rdev->regmap, ctrl_regs->status_reg, );
+   ret = (int)REG_VALUE_GETBITS(value, ctrl_data->shift,
+   ctrl_data->mask);
+
+   return ret;
+}
+
+static int hi655x_regulator_pmic_enable(struct regulator_dev *rdev)
+{
+   int ret = 0;
+   unsigned char value_u8 = 0;
+   unsigned int value_u32 = 0;
+   struct hi655x_regulator *sreg = rdev_get_drvdata(rdev);
+   struct hi655x_regulator_ctrl_regs  *ctrl_regs = &(sreg->ctrl_regs);
+   struct hi655x_regulator_ctrl_data  *ctrl_data = &(sreg->ctrl_data);
+
+   REG_VALUE_SETBITS(value_u32, ctrl_data->shift, ctrl_data->mask, 0x1);
+   value_u8  = (unsigned char)value_u32;
+   regmap_write(rdev->regmap, ctrl_regs->enable_reg, value_u8);
+   udelay(sreg->off_on_delay);
+
+   return ret;
+}
+
+static int hi655x_regulator_pmic_disable(struct regulator_dev *rdev)
+{
+   int ret = 0;
+   int flag = 1;
+   unsigned char value_u8 = 0;
+   unsigned int value_u32 = 0;
+
+   struct hi655x_regulator *sreg = rdev_get_drvdata(rdev);
+   struct hi655x_regulator_ctrl_regs  *ctrl_regs = &(sreg->ctrl_regs);
+   struct hi655x_regulator_ctrl_data  *ctrl_data = &(sreg->ctrl_data);
+
+   /*
+   * regulator is 

[PATCH 2/8] mfd: Hi655x: Add support for PMIC Hi655x MFD

[Fei Wang]

Add core files for Hi655x MFD driver.

Signed-off-by: Fei Wang 
---
 drivers/mfd/Kconfig |9 +
 drivers/mfd/Makefile|1 +
 drivers/mfd/hi655x-pmic.c   |  358 +++
 include/linux/mfd/hi655x-pmic.h |   56 ++
 4 files changed, 424 insertions(+)
 create mode 100644 drivers/mfd/hi655x-pmic.c
 create mode 100644 include/linux/mfd/hi655x-pmic.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 99d6367..d320def 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -273,6 +273,15 @@ config MFD_HI6421_PMIC
  menus in order to enable them.
  We communicate with the Hi6421 via memory-mapped I/O.
 
+config MFD_HI655X_PMIC
+   tristate "HiSilicon Hi655X series PMU/Codec IC"
+   depends on ARCH_HISI
+   depends on OF
+   select MFD_CORE
+   select REGMAP_MMIO
+   help
+ Select this option to enable Hisilicon hi655x series pmic driver.
+
 config HTC_EGPIO
bool "HTC EGPIO support"
depends on GPIOLIB && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a59e3fc..11ec427 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -185,6 +185,7 @@ obj-$(CONFIG_MFD_STW481X)   += stw481x.o
 obj-$(CONFIG_MFD_IPAQ_MICRO)   += ipaq-micro.o
 obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
 obj-$(CONFIG_MFD_HI6421_PMIC)  += hi6421-pmic-core.o
+obj-$(CONFIG_MFD_HI655X_PMIC)   += hi655x-pmic.o
 obj-$(CONFIG_MFD_DLN2) += dln2.o
 obj-$(CONFIG_MFD_RT5033)   += rt5033.o
 obj-$(CONFIG_MFD_SKY81452) += sky81452.o
diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
new file mode 100644
index 000..caeca4e
--- /dev/null
+++ b/drivers/mfd/hi655x-pmic.c
@@ -0,0 +1,358 @@
+/*
+ * Device driver for PMIC DRIVER in HI655X IC
+ *
+ * Copyright (c) 2015 Hisilicon Co. Ltd
+ *
+ * Fei Wang  
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+static const struct of_device_id of_hi655x_pmic_child_match_tbl[] = {
+   { .compatible = "hisilicon,hi655x-regulator-pmic", },
+   { .compatible = "hisilicon,hi655x-powerkey", },
+   { .compatible = "hisilicon,hi655x-usbvbus", },
+   { .compatible = "hisilicon,hi655x-coul", },
+   { .compatible = "hisilicon,hi655x-pmu-rtc", },
+   {},
+};
+
+static const struct of_device_id of_hi655x_pmic_match_tbl[] = {
+   { .compatible = "hisilicon,hi655x-pmic-driver", },
+   {},
+};
+
+static unsigned int hi655x_pmic_get_version(struct hi655x_pmic *pmic)
+{
+   u32 val;
+
+   regmap_read(pmic->regmap,
+   HI655X_REG_TO_BUS_ADDR(HI655X_VER_REG), );
+
+   return val;
+}
+
+static irqreturn_t hi655x_pmic_irq_handler(int irq, void *data)
+{
+   struct hi655x_pmic *pmic = (struct hi655x_pmic *)data;
+   u32 pending;
+   u32 ret = IRQ_NONE;
+   unsigned long offset;
+   int i;
+
+   for (i = 0; i < HI655X_IRQ_ARRAY; i++) {
+   regmap_read(pmic->regmap,
+   HI655X_REG_TO_BUS_ADDR(i + HI655X_IRQ_STAT_BASE),
+   );
+   if (pending != 0)
+   pr_debug("pending[%d]=0x%x\n\r", i, pending);
+
+   /* clear pmic-sub-interrupt */
+   regmap_write(pmic->regmap,
+   HI655X_REG_TO_BUS_ADDR(i + HI655X_IRQ_STAT_BASE),
+   pending);
+
+   if (pending) {
+   for_each_set_bit(offset, (unsigned long *),
+   HI655X_BITS)
+   generic_handle_irq(pmic->irqs[offset +
+   i * HI655X_BITS]);
+   ret = IRQ_HANDLED;
+   }
+   }
+   return ret;
+}
+
+
+static void hi655x_pmic_irq_mask(struct irq_data *d)
+{
+
+   u32 data, offset;
+   unsigned long pmic_spin_flag = 0;
+   struct hi655x_pmic *pmic = irq_data_get_irq_chip_data(d);
+
+   offset = ((irqd_to_hwirq(d) >> 3) + HI655X_IRQ_MASK_BASE);
+   spin_lock_irqsave(>ssi_hw_lock, pmic_spin_flag);
+   regmap_read(pmic->regmap,