Re: [alsa-devel] [PATCH][RFC] ASoC: core: remove pointless auxiliary from snd_soc_component

2017-03-22 Thread Kuninori Morimoto

Hi Sylwester

> > Can you test this patch if possible ?
> 
> My apologies for the delay, I just tested the patch
> and it seems all correct.

Thank you !
So, I will post it as non-RFC patch and add your Tested-by

Best regards
---
Kuninori Morimoto


Re: [PATCH 2/4] iio: Documentation: Add max961x sysfs documentation

2017-03-22 Thread Jonathan Cameron
On 21/03/17 16:09, jacopo wrote:
> Hi Jonathan,
> 
> On Sat, Feb 25, 2017 at 03:54:45PM +, Jonathan Cameron wrote:
>> On 24/02/17 15:05, Jacopo Mondi wrote:
>>> Add documentation for max961x driver.
>>> The only attribute to document is the current sense shunt resistor
>>> value.
>>>
>>> Signed-off-by: Jacopo Mondi 
>> Interestingly generic as it only applies to some of the channels.
>> We might need to have the channel where it is effecting the output specified 
>> in the
>> name, even if we end up with several repeats of the same thing for different
>> computed channels.
>>
> 
> Sorry, I'm getting on this a bit late...
> 
> Do you still think we should have an attribute for each of the
> channels this values affects?
> We will end up having 2 distinct processed channels (power and
> current) that depends on this value.
> I can expose them as 2 distinct attributes if you think this is the
> case...
Better to have two attributes exposing the same thing than imply it
is relevant to more of channels than it is...
> 
> A note on the series in general: given the lack of comments, I will
> send v2 exposing two processed channels, with no buffered reads, and
> gain selection performed in kernel space.
> If we will have to add buffered reads to accomodate higher sampling
> frequency we'll do that later on eventually.
Great.

Jonathan
> 
> Thanks
>   j
> 
>> Jonathan
>>> ---
>>>  Documentation/ABI/testing/sysfs-bus-iio-adc-max961x | 5 +
>>>  1 file changed, 5 insertions(+)
>>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-max961x
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-max961x 
>>> b/Documentation/ABI/testing/sysfs-bus-iio-adc-max961x
>>> new file mode 100644
>>> index 000..dbd5e75
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-max961x
>>> @@ -0,0 +1,5 @@
>>> +What:  /sys/bus/iio/devices/iio:deviceX/in_shunt_resistor
>>> +Date:  February 2017
>>> +KernelVersion: 4.10
>>> +Contact:   linux-...@vger.kernel.org
>>> +Description:   The value of the shunt resistor in micro Ohms.
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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 0/7] Renesas RZ/A1 pin and gpio controller

2017-03-22 Thread Chris Brandt
Hi Jacopo,

On Monday, March 20, 2017, Jacopo Mondi wrote:
> Chris: it would be great if you could give this another spin on RSK board.


I tested these patches on an RZ/A1H RSK board after modifying the DT for
the RSK vs the GENMAI board.

The following worked fine:
 * SCIF
 * I2C
 * SDHI
 * Ethernet

I see Geert has already responded with mostly text (grammar) changes.
As for the "API" of the driver from a user perspective, I think it should
cover all the use cases of the peripherals.


For your reference, here was my pin config for the RSK board testing. Once
this driver is (hopefully) accepted, I will update the upstream rskrza1 DT. 


--- RSK BOARD PIN SETUP ---

 {

scif2_pins: serial2 {
/* P3_0 as TxD2; P3_2 as RxD2 */
renesas,pins = ,
   ;
};

/* RIIC Ch 3 */
i2c3_pins: i2c3 {
/* RIIC3: P1_6 as SCL, P1_7 as SDA */
renesas,pins = ,
   ;
};

/* SHDI ch1 on CN1 */
sdhi1_pins: sdhi1 {
/* SHDI ch1 on Port 3 */
renesas,pins = , /* SDHI1 CD */
,/* SDHI1 WP */
,  /* SDHI1 DAT1 */
,  /* SDHI1 DAT0 */
,   /* SDHI1 CLK */
,  /* SDHI1 CMD */
,  /* SDHI1 DAT3 */
;  /* SDHI1 DAT2 */
};

/* Ethernet */
ether_pins: ether {
/* Ethernet on Ports 1,2,3,5 */
renesas,pins = , /* P1_14 = ET_COL */
,/* P5_9 = ET_MDC */
,   /* P3_3 = ET_MDIO (bi 
dir) */
,/* P3_4 = ET_RXCLK */
,/* P3_5 = ET_RXER */
,/* P3_6 = ET_RXDV */
,/* P2_0 = ET_TXCLK */
,/* P2_1 = ET_TXER */
,/* P2_2 = ET_TXEN */
,/* P2_3 = ET_CRS */
,/* P2_4 = ET_TXD0 */
,/* P2_5 = ET_TXD1 */
,/* P2_6 = ET_TXD2 */
,/* P2_7 = ET_TXD3 */
,/* P2_8 = ET_RXD0 */
,/* P2_9 = ET_RXD1 */
, /* P2_10 = ET_RXD2 */
; /* P2_11 = ET_RXD3 */
};
};

 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
};

 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
};

 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
};

 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
};

/ {
leds {
status = "okay";
compatible = "gpio-leds";

led1 {
gpios = < 1 GPIO_ACTIVE_LOW>;
};
};
};



Thank you,
Chris



[PATCH] backlight: pwm_bl: Fix GPIO out for unimplemented .get_direction()

2017-03-22 Thread Geert Uytterhoeven
Commit 7613c922315e308a ("backlight: pwm_bl: Move the checks for initial
power state to a separate function") not just moved some code, but made
slight changes in semantics.

If a gpiochip doesn't implement the optional .get_direction() callback,
gpiod_get_direction always returns -EINVAL, which is never equal to
GPIOF_DIR_IN, leading to the GPIO not being configured for output.

To avoid this, invert the test and check for not GPIOF_DIR_OUT instead,
like the original code did.

This restores the display on r8a7740/armadillo.

Fixes: 7613c922315e308a ("backlight: pwm_bl: Move the checks for initial power 
state to a separate function")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/video/backlight/pwm_bl.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index d7efcb632f7d9dde..002f1ce22bd02032 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -297,14 +297,15 @@ static int pwm_backlight_probe(struct platform_device 
*pdev)
}
 
/*
-* If the GPIO is configured as input, change the direction to output
-* and set the GPIO as active.
+* If the GPIO is not known to be already configured as output, that
+* is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL,
+* change the direction to output and set the GPIO as active.
 * Do not force the GPIO to active when it was already output as it
 * could cause backlight flickering or we would enable the backlight too
 * early. Leave the decision of the initial backlight state for later.
 */
if (pb->enable_gpio &&
-   gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_IN)
+   gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
gpiod_direction_output(pb->enable_gpio, 1);
 
pb->power_supply = devm_regulator_get(>dev, "power");
-- 
2.7.4



Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

2017-03-22 Thread Geert Uytterhoeven
Hi Jacopo,

On Wed, Mar 22, 2017 at 4:36 PM, jacopo  wrote:
> On Wed, Mar 22, 2017 at 02:20:08PM +0100, Geert Uytterhoeven wrote:
>> On Wed, Mar 22, 2017 at 11:33 AM, Geert Uytterhoeven
>>  wrote:
>> > On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  
>> > wrote:
>> >> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
>>
>> ulating the pin index from its position
>> >> +  (port where it sits on and pin offset), and alternate function
>> >> +  configuration options are provided in pin controller header file 
>> >> at:
>> >
>> > the pin ... file
>> >
>> >> +  include/dt-bindings/pinctrl/r7s72100-pinctrl.h
>> >
>> > Hence I'd include that file in this patch, as it's part of the bindings.
>>
>> Ah, that would create a hard dependency between the DTS files and the
>> DT bindings, which typically go in through different trees.
>> As the driver replicates the definitions from the header, the include file
>> can go in with the DTS updates.
>>
>
> Sorry, got confused by multiple reviews here..
> Are you suggesting to squash [03/07] in [04/07] here?

No, I suggested to squash [03/07] into [02/07].

But upon second thought, that's not such a good idea, as it creates an
additional dependency.

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


Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

2017-03-22 Thread jacopo
Hi Geert,
thanks for reviews

On Wed, Mar 22, 2017 at 02:20:08PM +0100, Geert Uytterhoeven wrote:
> On Wed, Mar 22, 2017 at 11:33 AM, Geert Uytterhoeven
>  wrote:
> > On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  
> > wrote:
> >> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> 
> ulating the pin index from its position
> >> +  (port where it sits on and pin offset), and alternate function
> >> +  configuration options are provided in pin controller header file at:
> >
> > the pin ... file
> >
> >> +  include/dt-bindings/pinctrl/r7s72100-pinctrl.h
> >
> > Hence I'd include that file in this patch, as it's part of the bindings.
> 
> Ah, that would create a hard dependency between the DTS files and the
> DT bindings, which typically go in through different trees.
> As the driver replicates the definitions from the header, the include file
> can go in with the DTS updates.
> 

Sorry, got confused by multiple reviews here..
Are you suggesting to squash [03/07] in [04/07] here?

Thanks
   j

> 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


[PATCH v4] mmc: sh_mmcif: Document r7s72100 DT bindings

2017-03-22 Thread Chris Brandt
Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
Acked-by: Rob Herring 
---
v4:
* added Reviewed-by and Acked-by
v3:
* added list of how many interrupts each SOC has
v2:
* added interrupt description
---
 Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt 
b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
index e4ba92aa..c32dc5a 100644
--- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
+++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
@@ -8,6 +8,7 @@ Required properties:
 
 - compatible: should be "renesas,mmcif-", "renesas,sh-mmcif" as a
   fallback. Examples with  are:
+   - "renesas,mmcif-r7s72100" for the MMCIF found in r7s72100 SoCs
- "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs
- "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
- "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs
@@ -17,6 +18,13 @@ Required properties:
- "renesas,mmcif-r8a7794" for the MMCIF found in r8a7794 SoCs
- "renesas,mmcif-sh73a0" for the MMCIF found in sh73a0 SoCs
 
+- interrupts: Some SoCs have only 1 shared interrupt, while others have either
+  2 or 3 individual interrupts (error, int, card detect). Below is the number
+  of interrupts for each SoC:
+1: r8a73a4, r8a7778, r8a7790, r8a7791, r8a7793, r8a7794
+2: r8a7740, sh73a0
+3: r7s72100
+
 - clocks: reference to the functional clock
 
 - dmas: reference to the DMA channels, one per channel name listed in the
-- 
2.10.1




Re: [PATCH v3 0/3] iommu/ipmmu-vmsa: r8a7796 support V3

2017-03-22 Thread Geert Uytterhoeven
Hi Jörg,

On Wed, Mar 22, 2017 at 3:23 PM, Joerg Roedel  wrote:
> On Sun, Mar 12, 2017 at 02:38:20PM +0900, Magnus Damm wrote:
>> iommu/ipmmu-vmsa: r8a7796 support V3
>>
>> [PATCH v3 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
>> [PATCH v3 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
>> [PATCH v3 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
>
> I just tried to apply a few of your patch-sets, but failed because they
> don't apply cleanly and it is not clear what the dependencies are and in
> which order they need to be applied.
>
> So for now I skipped all ipmmu-vmsa patches that are currently in my
> inbox. Please rebase your different series to v4.11-rc3 and resend them
> in the right order, with all Reviewed-bys and other tags that people
> gave you included. Then I am taking another look into applying them.

For the record, they apply cleanly on v4.11-rc1, cfr.
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/r8a7796-ipmmu-v3

As I had no conflicts when creating
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tag/?h=renesas-drivers-2017-03-21-v4.11-rc3
I expect them to apply cleanly to your next branch, too.

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


[PATCH v2 1/7] rtc: rtc-sh: add support for rza series

2017-03-22 Thread Chris Brandt
This same RTC is used in RZ/A series MPUs, therefore with some slight
changes, this driver can be reused. Additionally, since ARM architectures
require Device Tree configurations, device tree support has been added.

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
---
v2:
* removed HAVE_CLK from Kconfig
* when using DT, look for "fck" instead of "rtc0"
* changed (res == NULL) to (!res)
* added Reviewed-by
---
 drivers/rtc/Kconfig  |  4 ++--
 drivers/rtc/rtc-sh.c | 33 -
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index ee1b0e9..c2d1f0e 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1303,10 +1303,10 @@ config RTC_DRV_SA1100
 
 config RTC_DRV_SH
tristate "SuperH On-Chip RTC"
-   depends on SUPERH && HAVE_CLK
+   depends on SUPERH || ARCH_RENESAS
help
  Say Y here to enable support for the on-chip RTC found in
- most SuperH processors.
+ most SuperH processors. This RTC is also found in RZ/A SoCs.
 
  To compile this driver as a module, choose M here: the
  module will be called rtc-sh.
diff --git a/drivers/rtc/rtc-sh.c b/drivers/rtc/rtc-sh.c
index c626e43..00b396e 100644
--- a/drivers/rtc/rtc-sh.c
+++ b/drivers/rtc/rtc-sh.c
@@ -27,7 +27,15 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_SUPERH
 #include 
+#else
+/* Default values for RZ/A RTC */
+#define rtc_reg_size   sizeof(u16)
+#define RTC_BIT_INVERTED0  /* no chip bugs */
+#define RTC_CAP_4_DIGIT_YEAR(1 << 0)
+#define RTC_DEF_CAPABILITIESRTC_CAP_4_DIGIT_YEAR
+#endif
 
 #define DRV_NAME   "sh-rtc"
 
@@ -570,6 +578,8 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
rtc->alarm_irq = platform_get_irq(pdev, 2);
 
res = platform_get_resource(pdev, IORESOURCE_IO, 0);
+   if (!res)
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (unlikely(res == NULL)) {
dev_err(>dev, "No IO resource\n");
return -ENOENT;
@@ -587,12 +597,15 @@ static int __init sh_rtc_probe(struct platform_device 
*pdev)
if (unlikely(!rtc->regbase))
return -EINVAL;
 
-   clk_id = pdev->id;
-   /* With a single device, the clock id is still "rtc0" */
-   if (clk_id < 0)
-   clk_id = 0;
+   if (!pdev->dev.of_node) {
+   clk_id = pdev->id;
+   /* With a single device, the clock id is still "rtc0" */
+   if (clk_id < 0)
+   clk_id = 0;
 
-   snprintf(clk_name, sizeof(clk_name), "rtc%d", clk_id);
+   snprintf(clk_name, sizeof(clk_name), "rtc%d", clk_id);
+   } else
+   snprintf(clk_name, sizeof(clk_name), "fck");
 
rtc->clk = devm_clk_get(>dev, clk_name);
if (IS_ERR(rtc->clk)) {
@@ -608,6 +621,8 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
clk_enable(rtc->clk);
 
rtc->capabilities = RTC_DEF_CAPABILITIES;
+
+#ifdef CONFIG_SUPERH
if (dev_get_platdata(>dev)) {
struct sh_rtc_platform_info *pinfo =
dev_get_platdata(>dev);
@@ -618,6 +633,7 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
 */
rtc->capabilities |= pinfo->capabilities;
}
+#endif
 
if (rtc->carry_irq <= 0) {
/* register shared periodic/carry/alarm irq */
@@ -738,10 +754,17 @@ static int sh_rtc_resume(struct device *dev)
 
 static SIMPLE_DEV_PM_OPS(sh_rtc_pm_ops, sh_rtc_suspend, sh_rtc_resume);
 
+static const struct of_device_id sh_rtc_of_match[] = {
+   { .compatible = "renesas,sh-rtc", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sh_rtc_of_match);
+
 static struct platform_driver sh_rtc_platform_driver = {
.driver = {
.name   = DRV_NAME,
.pm = _rtc_pm_ops,
+   .of_match_table = sh_rtc_of_match,
},
.remove = __exit_p(sh_rtc_remove),
 };
-- 
2.10.1




[PATCH v2 0/7] rtc: Reuse rtc-sh driver to support RZ/A1

2017-03-22 Thread Chris Brandt
Basically, the same RTC that was used in SuperH devices is now used in
RZ/A1 devices. Therefore with some slight changes, that driver can be
reused.

Additionally, since ARM architectures require Device Tree configurations,
device tree support has been added.

This was tested on RZ/A1H RSK board. Once the correct time was programmed
into the RTC running off a 32.768kHz crystal, you can retain an accurate
system clock between reboots (hard and soft) until power is finally removed
from the board (there is no batter backup on the RSK board).

v2:
* removed HAVE_CLK from Kconfig
* when using DT, look for "fck" instead of "rtc0"
* changed (res == NULL) to (!res)
* added Reviewed-by for rtc-sh.c
* added interrupt-names and clock-names
* clocks now include counting sources
* added clock-names "fck", "rtc_x1", "rtc_x3", "extal"
* changed 'is a RTC' to 'is an RTC' in commit message
* changed "rtc0" to "rtc"
* Added clock nodes for RTC_X1 and RTC_X3 pin inputs
* each commit now has a log message


Chris Brandt (7):
  rtc: rtc-sh: add support for rza series
  rtc: Add rtc-sh
  ARM: dts: r7s72100: add rtc clock to device tree
  ARM: dts: r7s72100: add RTC_X clock inputs to device tree
  ARM: dts: r7s72100: add rtc to device tree
  ARM: dts: rskrza1: set rtc_x1 clock value
  ARM: dts: rskrza1: add rtc DT support

 Documentation/devicetree/bindings/rtc/rtc-sh.txt | 29 +++
 arch/arm/boot/dts/r7s72100-rskrza1.dts   |  8 +
 arch/arm/boot/dts/r7s72100.dtsi  | 37 
 drivers/rtc/Kconfig  |  4 +--
 drivers/rtc/rtc-sh.c | 33 +
 include/dt-bindings/clock/r7s72100-clock.h   |  3 ++
 6 files changed, 107 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-sh.txt

-- 
2.10.1




[PATCH v2 4/7] ARM: dts: r7s72100: add RTC_X clock inputs to device tree

2017-03-22 Thread Chris Brandt
Add the RTC clocks to device tree. The frequencies must be fixed values
according to the hardware manual.

Signed-off-by: Chris Brandt 
---
 arch/arm/boot/dts/r7s72100.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 6a1448b..632a6a4 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -51,6 +51,20 @@
clock-frequency = <0>;
};
 
+   rtc_x1_clk: rtc_x1 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   /* If clk present, value must be set by board to 32678 
*/
+   clock-frequency = <0>;
+   };
+
+   rtc_x3_clk: rtc_x3 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   /* If clk present, value must be set by board to 
400 */
+   clock-frequency = <0>;
+   };
+
/* Fixed factor clocks */
b_clk: b {
#clock-cells = <0>;
-- 
2.10.1




[PATCH v2 6/7] ARM: dts: rskrza1: set rtc_x1 clock value

2017-03-22 Thread Chris Brandt
Enable the 32.768 kHz RTC_X1 clock by setting the frequency value to
non-zero.

Signed-off-by: Chris Brandt 
---
 arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts 
b/arch/arm/boot/dts/r7s72100-rskrza1.dts
index 02b59c5..cab5857 100644
--- a/arch/arm/boot/dts/r7s72100-rskrza1.dts
+++ b/arch/arm/boot/dts/r7s72100-rskrza1.dts
@@ -43,6 +43,10 @@
clock-frequency = <4800>;
 };
 
+_x1_clk {
+   clock-frequency = <32768>;
+};
+
  {
status = "okay";
 };
-- 
2.10.1




[PATCH v2 7/7] ARM: dts: rskrza1: add rtc DT support

2017-03-22 Thread Chris Brandt
Enable the realtime clock.

Signed-off-by: Chris Brandt 
---
 arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts 
b/arch/arm/boot/dts/r7s72100-rskrza1.dts
index cab5857..72df20a 100644
--- a/arch/arm/boot/dts/r7s72100-rskrza1.dts
+++ b/arch/arm/boot/dts/r7s72100-rskrza1.dts
@@ -73,6 +73,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.10.1




[PATCH v2 5/7] ARM: dts: r7s72100: add rtc to device tree

2017-03-22 Thread Chris Brandt
Add the realtime clock device node.

Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
---
v2:
* added interrupt-names
* added clock counting sources
* added clock-names "fck", "rtc_x1", "rtc_x3", "extal"
---
 arch/arm/boot/dts/r7s72100.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 632a6a4..f74a8ec 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -652,4 +652,18 @@
power-domains = <_clocks>;
status = "disabled";
};
+
+   rtc: rtc@fcff1000 {
+   compatible = "renesas,r7s72100-rtc", "renesas,sh-rtc";
+   reg = <0xfcff1000 0x2e>;
+   interrupts = ;
+   interrupt-names = "alarm", "period", "carry";
+   clocks = <_clks R7S72100_CLK_RTC>, <_x1_clk>,
+<_x3_clk>, <_clk>;
+   clock-names = "fck", "rtc_x1", "rtc_x3", "extal";
+   power-domains = <_clocks>;
+   status = "disabled";
+   };
 };
-- 
2.10.1




Re: [PATCH/RFC v2 0/4] iommu/ipmmu-vmsa: IPMMU slave device whitelist V2

2017-03-22 Thread Joerg Roedel
On Fri, Jan 27, 2017 at 03:14:07PM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: IPMMU slave device whitelist V2
> 
> [PATCH/RFC v2 1/4] iommu/of: Skip IOMMU devices disabled in DT
> [PATCH/RFC v2 2/4] iommu/ipmmu-vmsa: Get rid of disabled device check
> [PATCH/RFC v2 3/4] iommu/ipmmu-vmsa: Check devices in xlate()
> [PATCH/RFC v2 3/4] iommu/ipmmu-vmsa: Opt-in slave devices based on ES version
> 
> Here's an updated prototype that shows how DT integration of IPMMU details
> may be integrated and merged upstream based on SoC data sheet ahead of
> time followed by enablement in the IPMMU driver code once the appropriate
> SoC ES version has been released and the hardware has been tested.
> 
> Changes since V1:
>  - Broke out patch 1 from the IPMMU driver
>  - Moved slave device check from ->add_device() to ->xlate() (Thanks Robin!)
>  - Updated white list patch to hook into ->xlate()
> 
> Patch 1 may be suitable for upstream merge, however other patches should
> in the future if agreed on be rolled into the IPMMU driver series.
> 
> Signed-off-by: Magnus Damm 
> ---
> 
>  Developed on top of renesas-drivers-2017-01-24-v4.10-rc5
> 
>  drivers/iommu/ipmmu-vmsa.c |   59 
> +++-
>  drivers/iommu/of_iommu.c   |2 -
>  2 files changed, 33 insertions(+), 28 deletions(-)

For the series:

Reviewed-by: Joerg Roedel 


Re: [PATCH v7 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

2017-03-22 Thread Joerg Roedel
On Tue, Mar 07, 2017 at 12:17:33PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Introduce an alternative set of iommu_ops suitable for 64-bit ARM
> as well as 32-bit ARM when CONFIG_IOMMU_DMA=y. Also adjust the
> Kconfig to depend on ARM or IOMMU_DMA. Initialize the device
> from ->xlate() when CONFIG_IOMMU_DMA=y.
> 
> Signed-off-by: Magnus Damm 
> ---
> 
>  Changes since V6:
>  - Rolled in the following patches from "r8a7795 support V2":
>[PATCH v2 04/11] iommu/ipmmu-vmsa: Reuse iommu groups
>[PATCH v2 06/11] iommu/ipmmu-vmsa: Teach xlate() to skip disabled iommus
>  - Moved find_group() implementation to prevent warning on 32-bit ARM
>  - Rolled in the following patch from "IPMMU slave device whitelist V2":
>[PATCH/RFC v2 3/4] iommu/ipmmu-vmsa: Check devices in xlate()
> 
>  drivers/iommu/Kconfig  |1 
>  drivers/iommu/ipmmu-vmsa.c |  164 
> +---
>  2 files changed, 157 insertions(+), 8 deletions(-)

Reviewed-by: Joerg Roedel 


Re: [PATCH v3 0/3] iommu/ipmmu-vmsa: r8a7796 support V3

2017-03-22 Thread Joerg Roedel
Hey Magnus,

On Sun, Mar 12, 2017 at 02:38:20PM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: r8a7796 support V3
> 
> [PATCH v3 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
> [PATCH v3 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
> [PATCH v3 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code

I just tried to apply a few of your patch-sets, but failed because they
don't apply cleanly and it is not clear what the dependencies are and in
which order they need to be applied.

So for now I skipped all ipmmu-vmsa patches that are currently in my
inbox. Please rebase your different series to v4.11-rc3 and resend them
in the right order, with all Reviewed-bys and other tags that people
gave you included. Then I am taking another look into applying them.


Thanks,

Joerg


RE: [PATCH v3] mmc: sh_mmcif: Document r7s72100 DT bindings

2017-03-22 Thread Chris Brandt
On Wednesday, March 22, 2017, Ulf Hansson wrote:
> On 22 March 2017 at 14:17, Chris Brandt  wrote:
> > This one seems to have been forgotten.
> >
> > Should I resend with all the acks and reviews?
> 
> Seems like you didn't send it to linux-mmc, so it wasn't picked up by the
> patchtracker. Please re-send so I can pick it up.
> 
> Kind regards
> Uffe

OK. Thank you.

Chris


Re: [PATCH v3] mmc: sh_mmcif: Document r7s72100 DT bindings

2017-03-22 Thread Ulf Hansson
On 22 March 2017 at 14:17, Chris Brandt  wrote:
> This one seems to have been forgotten.
>
> Should I resend with all the acks and reviews?

Seems like you didn't send it to linux-mmc, so it wasn't picked up by
the patchtracker. Please re-send so I can pick it up.

Kind regards
Uffe

>
> Chris
>
>
>
> On Wednesday, January 18, 2017, Rob Herring wrote:
>> On Wed, Jan 11, 2017 at 11:14:52PM -0500, Chris Brandt wrote:
>> > Signed-off-by: Chris Brandt 
>> >
>> > ---
>> > v3:
>> > * added list of how many interrupts each SOC has
>> > v2:
>> > * added interrupt description
>> > ---
>> >  Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 8 
>> >  1 file changed, 8 insertions(+)
>>
>> Acked-by: Rob Herring 
>
>
>
> On Thursday, January 12, 2017, Simon Horman wrote:
>> On Thu, Jan 12, 2017 at 08:36:10AM +0100, Geert Uytterhoeven wrote:
>> > Hi Chris,
>> >
>> > On Thu, Jan 12, 2017 at 5:14 AM, Chris Brandt 
>> wrote:
>> > > Signed-off-by: Chris Brandt 
>> > >
>> > > ---
>> > > v3:
>> > > * added list of how many interrupts each SOC has
>> > > v2:
>> > > * added interrupt description
>> >
>> > Thanks or the update!
>> >
>> > Reviewed-by: Geert Uytterhoeven 
>>
>> Reviewed-by: Simon Horman 
>
>
> On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
>> On Thu, Jan 12, 2017 at 5:14 AM, Chris Brandt 
>> wrote:
>> > Signed-off-by: Chris Brandt 
>> >
>> > ---
>> > v3:
>> > * added list of how many interrupts each SOC has
>> > v2:
>> > * added interrupt description
>>
>> Thanks or the update!
>>
>> Reviewed-by: Geert Uytterhoeven 
>


Re: [PATCH 06/15] ARM: dts: r8a779x: fix PCI bus dtc warnings

2017-03-22 Thread Rob Herring
On Wed, Mar 22, 2017 at 3:58 AM, Geert Uytterhoeven
 wrote:
> Hi Rob,
>
> On Wed, Mar 22, 2017 at 3:03 AM, Rob Herring  wrote:
>> dtc recently added PCI bus checks. Fix these warnings.
>
> It's always a good idea to put the warnings in the commit message:

Well, the warnings are a bit noisy in that they get repeated, can be
misleading, change as I fix problems (device nodes are not checked if
the bridge node fails), and most importantly I'm lazy having fixed
these treewide. Sub-arch maintainers are welcome to make better
patches. :)

> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee09/usb@0,1 node name is not "pci" or "pcie"
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee09/usb@0,1 missing ranges for PCI bridge (or not a bridge)
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee09/usb@0,1 incorrect #address-cells for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee09/usb@0,1 incorrect #size-cells for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee09/usb@0,1 missing bus-range for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee09/usb@0,2 node name is not "pci" or "pcie"
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee09/usb@0,2 missing ranges for PCI bridge (or not a bridge)
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee09/usb@0,2 incorrect #address-cells for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee09/usb@0,2 incorrect #size-cells for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee09/usb@0,2 missing bus-range for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee0d/usb@0,1 node name is not "pci" or "pcie"
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee0d/usb@0,1 missing ranges for PCI bridge (or not a bridge)
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee0d/usb@0,1 incorrect #address-cells for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee0d/usb@0,1 incorrect #size-cells for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee0d/usb@0,1 missing bus-range for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee0d/usb@0,2 node name is not "pci" or "pcie"
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee0d/usb@0,2 missing ranges for PCI bridge (or not a bridge)
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee0d/usb@0,2 incorrect #address-cells for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee0d/usb@0,2 incorrect #size-cells for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
> /pci@ee0d/usb@0,2 missing bus-range for PCI bridge
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (unit_address_format):
> Failed prerequisite 'pci_bridge'
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_device_reg): Failed
> prerequisite 'pci_bridge'
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_device_bus_num):
> Failed prerequisite 'pci_bridge'
>
> The above indeed go away with your patch, but I don't know why ;-)

Most of these are because 'device_type = "pci";' should only be on PCI
bridges, not PCI devices.

>
>> Signed-off-by: Rob Herring 
>> Cc: Simon Horman 
>> Cc: Magnus Damm 
>> Cc: linux-renesas-soc@vger.kernel.org
>> ---
>> Sub-arch maintainers, please apply to your trees unless arm-soc wants
>> to take the whole lot.
>>
>>  arch/arm/boot/dts/r8a7790.dtsi | 16 ++--
>>  arch/arm/boot/dts/r8a7791.dtsi | 16 ++--
>>  arch/arm/boot/dts/r8a7794.dtsi | 16 ++--
>>  3 files changed, 18 insertions(+), 30 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
>> index 6d10450de6d7..c16a37e9fb5d 100644
>> --- a/arch/arm/boot/dts/r8a7790.dtsi
>> +++ b/arch/arm/boot/dts/r8a7790.dtsi
>> @@ -1598,16 +1598,14 @@
>>  0x0800 0 0 1  GIC_SPI 108 
>> IRQ_TYPE_LEVEL_HIGH
>>  0x1000 0 0 2  GIC_SPI 108 
>> IRQ_TYPE_LEVEL_HIGH>;
>>
>> -   usb@0,1 {
>> +   usb@1,0 {
>> reg = <0x800 0 0 0 0>;
>> -   device_type = "pci";
>> phys = < 0>;
>> phy-names = "usb";
>> };
>
> Both Documentation/devicetree/bindings/pci/pci.txt and ePAPR refer to
> http://www.firmware.org/1275/bindings/pci/pci2_1.pdf
> http://www.firmware.org/1275/practice/imap/imap0_9d.pdf
> 

Re: [PATCH 06/15] ARM: dts: r8a779x: fix PCI bus dtc warnings

2017-03-22 Thread Geert Uytterhoeven
Hi Rob,

On Wed, Mar 22, 2017 at 2:47 PM, Rob Herring  wrote:
> On Wed, Mar 22, 2017 at 3:58 AM, Geert Uytterhoeven
>  wrote:
>> On Wed, Mar 22, 2017 at 3:03 AM, Rob Herring  wrote:
>>> dtc recently added PCI bus checks. Fix these warnings.
>>
>> It's always a good idea to put the warnings in the commit message:
>
> Well, the warnings are a bit noisy in that they get repeated, can be
> misleading, change as I fix problems (device nodes are not checked if
> the bridge node fails), and most importantly I'm lazy having fixed
> these treewide. Sub-arch maintainers are welcome to make better
> patches. :)
>
>> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_bridge): Node
>> /pci@ee09/usb@0,1 node name is not "pci" or "pcie"

[...]

>> The above indeed go away with your patch, but I don't know why ;-)
>
> Most of these are because 'device_type = "pci";' should only be on PCI
> bridges, not PCI devices.

Thanks, retrying...

arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_device_reg): Node
/pci@ee09/usb@0,1 PCI unit address format error, expected "1,0"
arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_device_reg): Node
/pci@ee09/usb@0,2 PCI unit address format error, expected "2,0"
arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_device_reg): Node
/pci@ee0d/usb@0,1 PCI unit address format error, expected "1,0"
arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_device_reg): Node
/pci@ee0d/usb@0,2 PCI unit address format error, expected "2,0"
arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_device_bus_num):
Node /pci@ee0d/usb@0,1 PCI bus number 0 out of range, expected (2
- 2)
arch/arm/boot/dts/r8a7790-lager.dtb: Warning (pci_device_bus_num):
Node /pci@ee0d/usb@0,2 PCI bus number 0 out of range, expected (2
- 2)

OK, without 'device_type = "pci"' it makes much more sense...

>> Both Documentation/devicetree/bindings/pci/pci.txt and ePAPR refer to
>> http://www.firmware.org/1275/bindings/pci/pci2_1.pdf
>> http://www.firmware.org/1275/practice/imap/imap0_9d.pdf
>> which no longer exist.
>
> Yeah, they are still out there. Just need to google "PCI supplement 1275". :)
>
> I have the full archive saved off. I need to get them added to devicetree.org.

Having working links in the DT bindings would be great.

BTW, seems like I still have an offline copy of v2.0 of the PCI spec in
PostScript format, from my CHRP days[*], when hard disks where smaller
than CD-Rs ;-)

[*] I never managed to memorize the PCI DT bindings, though.

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


Re: [PATCH 0/7] clk: renesas: rcar-gen3: Misc fixes and cleanups

2017-03-22 Thread Geert Uytterhoeven
On Mon, Mar 13, 2017 at 5:19 PM, Geert Uytterhoeven
 wrote:
> This patch series contains miscellaneous fixes and cleanups for the
> Renesas R-Car Gen3 (H3 and M3-W) clock drivers:
>   - Correct parent clock for Audio DMACs,
>   - Correct names of watchdog clocks,
>   - Reformat core clock tables for easier comparisons between drivers,
>   - Add workaround for PLL0/2/4 errata on R-Car H3 ES1.0.
>
> I plan to queue these up in clk-renesas-for-v4.12.

Queued up with Morimoto-san's grammar fix and Acked-by.

> Geert Uytterhoeven (7):
>   clk: renesas: r8a7795: Correct parent clock and sort order for Audio
> DMACs
>   clk: renesas: r8a7795: Correct name of watchdog clock
>   clk: renesas: r8a7796: Correct name of watchdog clock
>   clk: renesas: r8a7795: Reformat core clock table
>   clk: renesas: r8a7796: Reformat core clock table
>   clk: renesas: rcar-gen3-cpg: Pass mode pins to rcar_gen3_cpg_init()
>   clk: renesas: rcar-gen3: Add workaround for PLL0/2/4 errata on H3
> ES1.0

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


Re: [PATCH 0/2] pinctrl: sh-pfc: r8a7795: Misc fixes and cleanups

2017-03-22 Thread Geert Uytterhoeven
On Mon, Mar 13, 2017 at 5:41 PM, Geert Uytterhoeven
 wrote:
> This patch series contains miscellaneous fixes and cleanups for the
> Renesas R-Car H3 pinctrl driver:
>
> I plan to queue these up in sh-pfc-for-v4.12.

Queued in sh-pfc-for-v4.12, after adressing Sergei's comment.

> Geert Uytterhoeven (2):
>   pinctrl: sh-pfc: r8a7795: Fix hscif2_clk_b and hscif4_ctrl
>   pinctrl: sh-pfc: r8a7795: Restore sort order

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


Re: [PATCH v2 1/4] pinctrl: sh-pfc: Update info pointer after SoC-specific init

2017-03-22 Thread Geert Uytterhoeven
On Mon, Mar 13, 2017 at 6:12 PM, Geert Uytterhoeven
 wrote:
> Update the sh_pfc_soc_info pointer after calling the SoC-specific
> initialization function, as it may have been updated to e.g. handle
> different SoC revisions.  This makes sure the correct subdriver name is
> printed later.
>
> Signed-off-by: Geert Uytterhoeven 

Queued in sh-pfc-for-v4.12 with
Fixes: 0c151062f32c9db8 ("sh-pfc: Add support for SoC-specific initialization")
as this has been reported independently afterwards.

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


Re: [PATCH] ARM: dts: r7s72100: add power-domains to sdhi

2017-03-22 Thread Geert Uytterhoeven
(this time reply-to-all)

On Thu, Feb 9, 2017 at 2:38 PM, Chris Brandt  wrote:
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Chris Brandt 
> Fixes: 66474697923c ("ARM: dts: r7s72100: add sdhi to device tree")

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


Re: [PATCH v2 7/7] arm: dts: genmai: Add user led device nodes

2017-03-22 Thread Geert Uytterhoeven
On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  wrote:
> Add device nodes for user leds on Genmai board.
>
> Signed-off-by: Jacopo Mondi 

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


Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

2017-03-22 Thread Geert Uytterhoeven
On Wed, Mar 22, 2017 at 11:33 AM, Geert Uytterhoeven
 wrote:
> On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  
> wrote:
>> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt

ulating the pin index from its position
>> +  (port where it sits on and pin offset), and alternate function
>> +  configuration options are provided in pin controller header file at:
>
> the pin ... file
>
>> +  include/dt-bindings/pinctrl/r7s72100-pinctrl.h
>
> Hence I'd include that file in this patch, as it's part of the bindings.

Ah, that would create a hard dependency between the DTS files and the
DT bindings, which typically go in through different trees.
As the driver replicates the definitions from the header, the include file
can go in with the DTS updates.

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


RE: [PATCH v3] mmc: sh_mmcif: Document r7s72100 DT bindings

2017-03-22 Thread Chris Brandt
This one seems to have been forgotten.

Should I resend with all the acks and reviews?

Chris



On Wednesday, January 18, 2017, Rob Herring wrote:
> On Wed, Jan 11, 2017 at 11:14:52PM -0500, Chris Brandt wrote:
> > Signed-off-by: Chris Brandt 
> >
> > ---
> > v3:
> > * added list of how many interrupts each SOC has
> > v2:
> > * added interrupt description
> > ---
> >  Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 8 
> >  1 file changed, 8 insertions(+)
> 
> Acked-by: Rob Herring 



On Thursday, January 12, 2017, Simon Horman wrote:
> On Thu, Jan 12, 2017 at 08:36:10AM +0100, Geert Uytterhoeven wrote:
> > Hi Chris,
> >
> > On Thu, Jan 12, 2017 at 5:14 AM, Chris Brandt 
> wrote:
> > > Signed-off-by: Chris Brandt 
> > >
> > > ---
> > > v3:
> > > * added list of how many interrupts each SOC has
> > > v2:
> > > * added interrupt description
> >
> > Thanks or the update!
> >
> > Reviewed-by: Geert Uytterhoeven 
> 
> Reviewed-by: Simon Horman 


On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
> On Thu, Jan 12, 2017 at 5:14 AM, Chris Brandt 
> wrote:
> > Signed-off-by: Chris Brandt 
> >
> > ---
> > v3:
> > * added list of how many interrupts each SOC has
> > v2:
> > * added interrupt description
> 
> Thanks or the update!
> 
> Reviewed-by: Geert Uytterhoeven 



Re: [PATCH v2 6/7] arm: dts: genmai: Add RIIC2 pin group

2017-03-22 Thread Geert Uytterhoeven
On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  wrote:
> Add pin configuration subnode for RIIC2 interface.
>
> Signed-off-by: Jacopo Mondi 

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


Re: [PATCH v2 5/7] arm: dts: genmai: Add SCIF2 pin group

2017-03-22 Thread Geert Uytterhoeven
On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  wrote:
> Add pin configuration subnode for SCIF2 serial debug interface.
>
> Signed-off-by: Jacopo Mondi 

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


Re: [PATCH v2 4/7] arm: dts: r7s72100: Add pin controller node

2017-03-22 Thread Geert Uytterhoeven
Hi Jacopo,

On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  wrote:
> Add pin controller node with 12 gpio controller sub-nodes to
> r7s72100 dtsi.
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -183,6 +183,86 @@
> };
> };
>
> +   pinctrl: pinctrl@fcfe3000 {
> +   compatible = "renesas,r7s72100-ports";
> +
> +   #pinctrl-cells = <1>;
> +
> +   reg = <0xfcfe3000 0x4248>;

How did you get to 0x4248? I had expected 0x4230.
Not that it matters much, Linux rounds it up to a multiple of PAGE_SIZE anyway.

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


Re: [PATCH v4 1/2] backlight: pwm_bl: Move the checks for initial power state to a separate function

2017-03-22 Thread Geert Uytterhoeven
Hi Philip,

On Wed, Mar 22, 2017 at 11:46 AM, Philipp Zabel  wrote:
> On Tue, 2017-03-21 at 19:48 +0100, Geert Uytterhoeven wrote:
>> On Tue, Nov 22, 2016 at 2:41 PM, Peter Ujfalusi  
>> wrote:
>> > Move the checks to select the initial state for the backlight to a new
>> > function and document the checks we are doing.
>>
>> This is far from a simple "move"...
>>
>> > With the separate function it is going to be easier to fix or improve the
>> > initial power state configuration later and it is easier to read the code.
>> >
>> > Signed-off-by: Peter Ujfalusi 
>> > Reviewed-by: Philipp Zabel 
>> > Reviewed-by: Thierry Reding 
>>
>> This patch (commit 7613c922315e308a in v4.11-rc1) broke the display on
>> r8a7740/armadillo.
>>
>> > @@ -267,20 +292,16 @@ static int pwm_backlight_probe(struct 
>> > platform_device *pdev)
>> > pb->enable_gpio = gpio_to_desc(data->enable_gpio);
>> > }
>> >
>> > -   if (pb->enable_gpio) {
>> > -   /*
>> > -* If the driver is probed from the device tree and there 
>> > is a
>> > -* phandle link pointing to the backlight node, it is safe 
>> > to
>> > -* assume that another driver will enable the backlight at 
>> > the
>> > -* appropriate time. Therefore, if it is disabled, keep it 
>> > so.
>> > -*/
>> > -   if (node && node->phandle &&
>> > -   gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_OUT 
>> > &&
>> > -   gpiod_get_value(pb->enable_gpio) == 0)
>> > -   initial_blank = FB_BLANK_POWERDOWN;
>> > -   else
>> > -   gpiod_direction_output(pb->enable_gpio, 1);
>>
>> In my case, "node" points to the "/backlight" node, but phandle is NULL.
>> Hence before, gpiod_direction_output() was called to enable the GPIO...
>>
>> > -   }
>> > +   /*
>> > +* If the GPIO is configured as input, change the direction to 
>> > output
>> > +* and set the GPIO as active.
>> > +* Do not force the GPIO to active when it was already output as it
>> > +* could cause backlight flickering or we would enable the 
>> > backlight too
>> > +* early. Leave the decision of the initial backlight state for 
>> > later.
>> > +*/
>> > +   if (pb->enable_gpio &&
>> > +   gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_IN)
>> > +   gpiod_direction_output(pb->enable_gpio, 1);
>>
>> ... while now it's no longer called, as gpiod_get_direction() returns
>> -EINVAL.
>>
>> Indeed, r8a7740_pfc does not implement the .get_direction() callback,
>> so gpiod_get_direction() always returns -EINVAL, which is never equal
>> to GPIOF_DIR_IN.
>
> Oh, I didn't think about this at all, anymore. Though I believe to
> remember that this was the reason that I checked for
> (gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_OUT) before, so ...
>
>> Restoring the old behavior by changing the above test to
>>
>> if (pb->enable_gpio &&
>> (!node || !node->phandle ||
>>  gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_IN))
>>
>> fixes the display for me, but leads to a more complex expression.
>>
>> However, changing the test to
>>
>> if (pb->enable_gpio &&
>> gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
>>
>> also fixes the display, as an error is always different from GPIOF_DIR_OUT.
>>
>> Anyone with comments or suggestions to fix this for real?
>
> ... I'm in favor of the latter, as this is closer to the initial
> intention. I'd also mention this in the comment:
>
>/*
> * If the GPIO is not known to be already configured as output, that 
> is,
> * if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL, 
> change
> * the direction to output and set the GPIO as active.
> * Do not force the GPIO to active when it was already output as it
> * could cause backlight flickering or we would enable the backlight 
> too
> * early. Leave the decision of the initial backlight state for later.
> */

Thanks, I'll cook up a patch.

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


Re: [alsa-devel] [PATCH][RFC] ASoC: core: remove pointless auxiliary from snd_soc_component

2017-03-22 Thread Sylwester Nawrocki

Hi Morimoto-san,

On 03/22/2017 05:24 AM, Kuninori Morimoto wrote:

Can you test this patch if possible ?


My apologies for the delay, I just tested the patch
and it seems all correct.

--
Regards,
Sylwester


Re: [PATCH][RFC] ASoC: core: remove pointless auxiliary from snd_soc_component

2017-03-22 Thread Sylwester Nawrocki

On 03/08/2017 08:26 AM, Kuninori Morimoto wrote:

From: Kuninori Morimoto 

commit 1a653aa44725 ("ASoC: core: replace aux_comp_list to ...")
tried to replace aux_comp_list to component_dev_list,
but it failed because of binding timing. Thus, Sylwester fixuped it by
commit d2e3a1358c37 ("ASoC: Fix binding and probing of auxiliary...").

One of main purpose of commit 1a653aa44725 ("ASoC: core: replace...")
was remove replaceable list (= list_aux) from snd_soc_component by using
new "auxiliary" flags (but it failed).
Because of this background, current code has reborned card_aux_list
(= same as original list_aux), and almost pointless "auxiliary" flags.

Let's remove pointless "auxiliary" flags by this patch
This means, it is same as revert both
commit 1a653aa44725 ("ASoC: core: replace aux_comp_list to ...") and
commit d2e3a1358c37 ("ASoC: Fix binding and probing of auxiliary...").

Not-yet-Signed-off-by: Kuninori Morimoto 
request-Tested-by-from: Sylwester Nawrocki 


I tested in on top of v4.11-rc3 on the TM2 board and didn't notice any issues,
the sound card got initialized properly.

Tested-by: Sylwester Nawrocki 


Re: [PATCH v2 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

2017-03-22 Thread Geert Uytterhoeven
On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  wrote:
> Add dt-bindings for Renesas r7s72100 pin controller header file.
>
> Signed-off-by: Jacopo Mondi 
> ---
>  include/dt-bindings/pinctrl/r7s72100-pinctrl.h | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644 include/dt-bindings/pinctrl/r7s72100-pinctrl.h
>
> diff --git a/include/dt-bindings/pinctrl/r7s72100-pinctrl.h 
> b/include/dt-bindings/pinctrl/r7s72100-pinctrl.h
> new file mode 100644
> index 000..98852d3
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/r7s72100-pinctrl.h
> @@ -0,0 +1,36 @@
> +/*
> + * Defines macros and constants for Renesas RZ/A1 pin controller pin
> + * muxing functions.
> + */
> +#ifndef __DT_BINDINGS_PINCTRL_RENESAS_RZA1_H
> +#define __DT_BINDINGS_PINCTRL_RENESAS_RZA1_H
> +
> +#define RZA1_PINS_PER_PORT 16
> +
> +/* Create the pin index from it's bank and position numbers */

its bank

> +#define PIN(b, p)  ((b) * RZA1_PINS_PER_PORT + (p))
> +
> +/*
> + * Flags to apply to alternate function configuration
> + * All of the following are mutually exclusive.
> + */
> +
> +/*
> + * Pin is bi-directional.
> + * Alternate function that need both input/outpu functionalities shall

An alternate function that needs ... output

> + * be configured as bidirectional.
> + * Eg. SDA/SCL pins of an I2c interface.
> + */
> +#define BI_DIR (1 << 3)
> +
> +/*
> + * Flags used to ask software drive the pin I/O direction overriding the

to drive

> + * alternate function configuration.
> + * Some alternate function requires software to force I/O direction of a pin,

functions require

> + * ovverriding the designated one.

overriding

> + * Reference to the HW manual to know when this flag shall be used.

Refer

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


audio clk warnings during system suspend on Salvator-X

2017-03-22 Thread Geert Uytterhoeven
Hi Morimoto-san, Wolfram,

During the second system suspend (suspend to mem, "deep") on H3 Salvator-X,
the clk subsystem prints warnings due to enable and prepare count imbalances.

With some additional debug code, I discovered the issue is caused by the
CS2000 clock driver failing to resume:

suspend #1:

rsnd_adg_clk_control: called by rsnd_suspend
rsnd_adg_clk_control: Disable audio_clk_a
rsnd_adg_clk_control: Disable clk_multiplier
rsnd_adg_clk_control: Disable audio_clk_c
rsnd_adg_clk_control: Disable s0d4

resume #1:

dpm_run_callback(): cs2000_resume+0x0/0x20 returns -6
PM: Device 2-004f failed to resume early: error -6

rsnd_adg_clk_control: called by rsnd_resume
rsnd_adg_clk_control: Enable audio_clk_a
rsnd_adg_clk_control: Enable clk_multiplier
rcar_sound ec50.sound: can't use clk 1
rsnd_adg_clk_control: Enable audio_clk_c
rsnd_adg_clk_control: Enable s0d4


suspend #2:

rsnd_adg_clk_control: called by rsnd_suspend
rsnd_adg_clk_control: Disable audio_clk_a
rsnd_adg_clk_control: Disable clk_multiplier
WARNING: CPU: 0 PID: 1943 at drivers/clk/clk.c:594
clk_core_disable+0x44/0x254
[...]
WARNING: CPU: 0 PID: 1943 at drivers/clk/clk.c:476
clk_core_unprepare+0x48/0x36c
[...]
rsnd_adg_clk_control: Disable audio_clk_c
rsnd_adg_clk_control: Disable s0d4

resume #2:

dpm_run_callback(): cs2000_resume+0x0/0x20 returns -6
PM: Device 2-004f failed to resume early: error -6

rsnd_adg_clk_control: called by rsnd_resume
rsnd_adg_clk_control: Enable audio_clk_a
rsnd_adg_clk_control: Enable clk_multiplier
rcar_sound ec50.sound: can't use clk 1
rsnd_adg_clk_control: Enable audio_clk_c
rsnd_adg_clk_control: Enable s0d4


The CS2000 driver fails to send an i2c message, probably because the
rcar-i2c driver lost some register settings during system suspend.  This does
not happen with s2idle.

I guess this is also the reason for this warning:

ak4613-codec 2-0010: Unable to sync registers 0x0-0x2. -6

as the ak4613 is connected to the same i2c bus.

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