Re: [PATCH] cs-2000-cp: keep Reserved bit on each register

[Kuninori Morimoto]

Hi Stephen

> > From: Kuninori Morimoto 
> > 
> > Thus CS2000 datasheet is indicating below, this patch
> > follows it.
> > 
> > WARNING: All "Reserved" registers must maintain their default
> >  state to ensure proper functional operation.
> > 
> > Signed-off-by: Kuninori Morimoto 
> 
> Is this v2? I see two of these from different days.

Oops ?
I'm sorry,  I thought I didn't post this.
These are same patch.

Best regards
---
Kuninori Morimoto

Re: [git pull] clk: renesas: Updates for v4.12 (take two)

[Stephen Boyd]

On 04/05, Geert Uytterhoeven wrote:
> Hi Stephen,
> 
> On Wed, Apr 5, 2017 at 9:56 PM, Stephen Boyd  wrote:
> > On 03/31, Geert Uytterhoeven wrote:
> >> The following changes since commit 
> >> cecbe87d73006cb321dec79b349e3fefd1a80962:
> >>
> >>   clk: renesas: rcar-gen3: Add workaround for PLL0/2/4 errata on H3 ES1.0 
> >> (2017-03-21 11:12:23 +0100)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> >> tags/clk-renesas-for-v4.12-tag2
> >>
> >> for you to fetch changes up to bb1953067c05be30a605ee1d5b05a2677735bb37:
> >>
> >>   clk: renesas: rcar-gen3-cpg: Add support for RCLK on R-Car H3 ES2.0 
> >> (2017-03-30 13:26:02 +0200)
> >>
> >> 
> >> clk: renesas: Updates for v4.12 (take two)
> >>
> >>   - Add support for the Clock Pulse Generator / Module Standby and
> >> Software Reset module on revision ES2.0 of the R-Car H3 SoC, which
> >> differs from ES1.x in some areas.
> >>
> >> Note that this pull request is on top of my previous pull request for
> >> v4.12, which accidentally had a wrong version number in the subject
> >> line, and which I believe you haven't pulled yet.
> >
> > Thanks. I pulled both by pulling this one tag.
> 
> Thanks, but if you pull the second tag only, you don't record the contents
> of the first tag, do you?
> 

I copied the words into the commit message. Not sure anyone cares
that the first tag signature is lost.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [git pull] clk: renesas: Updates for v4.12 (take two)

[Geert Uytterhoeven]

Hi Stephen,

On Wed, Apr 5, 2017 at 9:56 PM, Stephen Boyd  wrote:
> On 03/31, Geert Uytterhoeven wrote:
>> The following changes since commit cecbe87d73006cb321dec79b349e3fefd1a80962:
>>
>>   clk: renesas: rcar-gen3: Add workaround for PLL0/2/4 errata on H3 ES1.0 
>> (2017-03-21 11:12:23 +0100)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
>> tags/clk-renesas-for-v4.12-tag2
>>
>> for you to fetch changes up to bb1953067c05be30a605ee1d5b05a2677735bb37:
>>
>>   clk: renesas: rcar-gen3-cpg: Add support for RCLK on R-Car H3 ES2.0 
>> (2017-03-30 13:26:02 +0200)
>>
>> 
>> clk: renesas: Updates for v4.12 (take two)
>>
>>   - Add support for the Clock Pulse Generator / Module Standby and
>> Software Reset module on revision ES2.0 of the R-Car H3 SoC, which
>> differs from ES1.x in some areas.
>>
>> Note that this pull request is on top of my previous pull request for
>> v4.12, which accidentally had a wrong version number in the subject
>> line, and which I believe you haven't pulled yet.
>
> Thanks. I pulled both by pulling this one tag.

Thanks, but if you pull the second tag only, you don't record the contents
of the first tag, do you?

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: [git pull] clk: renesas: Updates for v4.12 (take two)

[Stephen Boyd]

On 03/31, Geert Uytterhoeven wrote:
>   Hi Mike, Stephen,
> 
> The following changes since commit cecbe87d73006cb321dec79b349e3fefd1a80962:
> 
>   clk: renesas: rcar-gen3: Add workaround for PLL0/2/4 errata on H3 ES1.0 
> (2017-03-21 11:12:23 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.12-tag2
> 
> for you to fetch changes up to bb1953067c05be30a605ee1d5b05a2677735bb37:
> 
>   clk: renesas: rcar-gen3-cpg: Add support for RCLK on R-Car H3 ES2.0 
> (2017-03-30 13:26:02 +0200)
> 
> 
> clk: renesas: Updates for v4.12 (take two)
> 
>   - Add support for the Clock Pulse Generator / Module Standby and
> Software Reset module on revision ES2.0 of the R-Car H3 SoC, which
> differs from ES1.x in some areas.
> 
> Note that this pull request is on top of my previous pull request for
> v4.12, which accidentally had a wrong version number in the subject
> line, and which I believe you haven't pulled yet.

Thanks. I pulled both by pulling this one tag.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] cs-2000-cp: keep Reserved bit on each register

[Stephen Boyd]

On 04/05, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> Thus CS2000 datasheet is indicating below, this patch
> follows it.
> 
> WARNING: All "Reserved" registers must maintain their default
>  state to ensure proper functional operation.
> 
> Signed-off-by: Kuninori Morimoto 

Is this v2? I see two of these from different days.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 09/13] arm64: dts: r8a7795: salvator-x: Add panel backlight support

[Simon Horman]

On Wed, Apr 05, 2017 at 10:55:32AM +0200, Geert Uytterhoeven wrote:
> Hi Laurent,
> 
> On Wed, Apr 5, 2017 at 10:45 AM, Laurent Pinchart
>  wrote:
> > On Monday 21 Nov 2016 11:59:47 Laurent Pinchart wrote:
> >> On Monday 21 Nov 2016 10:23:46 Geert Uytterhoeven wrote:
> >> > On Mon, Nov 21, 2016 at 10:19 AM, Laurent Pinchart wrote:
> >> >> On Monday 21 Nov 2016 09:36:22 Geert Uytterhoeven wrote:
> >> >>> On Sat, Nov 19, 2016 at 4:28 AM, Laurent Pinchart wrote:
> >>  The panel backlight is controlled through a GPIO and a PWM channel.
> >> 
> >>  --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> >>  +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> >>  @@ -178,6 +178,16 @@
> >>  };
> >>  };
> >>  };
> >>  +
> >>  +   backlight: backlight {
> >>  +   compatible = "pwm-backlight";
> >>  +   pwms = < 0 5>;
> >>  +
> >>  +   brightness-levels = <256 128 64 16 8 4 0>;
> >> >>>
> >> >>> Would it make sense to define more and/or linear levels?
> >> >>
> >> >> Possibly, this is pretty arbitrary. Linear levels might not be the best
> >> >> option given that the human eye doesn't have a linear response to light
> >> >> power, but we
> >> >
> >> > It not only depends on the human eye, but also on the backlight hardware
> >> > (is the conversion from voltage (L_VBRT) to light linear?).
> >>
> >> So we need to specify transfer functions in DT ;-)
> >>
> >> >> could certainly have more levels. In that case I'd prefer modifying the
> >> >> pwm- backlight DT bindings though, and specifying the PWM resolution
> >> >> instead of discrete levels.
> >> >>
> >> >> Note that the LVDS panel backlight PWM control signal is multiplexed
> >> >> with the external memory A21 signal on the Salvator-X board, with SW5
> >> >> selecting which how to route the signal. When using backlight control we
> >> >> can't access the whole NOR flash anymore, so I'm not sure this patch
> >> >> should be merged.
> >> >
> >> > That NOR flash is also optional, right?
> >> > My Ex Memory Connector is not populated.
> >>
> >> That's correct. The Salvator-X DT file in mainline is just an example
> >> anyway, and we should pick the most useful peripherals for that purpose.
> >
> > Would you like me to include this in my next Salvator-X DT patch series for
> > upstream merge ?
> 
> That's fine for me (CC Simon). Thx!

Sounds good to me.

Re: [PATCH 0/3] arm: dts: renesas: Drop _clk suffix from clock node names

[Simon Horman]

On Wed, Apr 05, 2017 at 09:09:20AM +0200, Geert Uytterhoeven wrote:
> Hi Stephen,
> 
> On Wed, Apr 5, 2017 at 3:38 AM, Stephen Boyd  wrote:
> > On 04/03, Geert Uytterhoeven wrote:
> >> The current practice is to not add _clk suffixes to clock node names in
> >> DT, as these names are used as the actual clock names.
> >>
> >> This patch removes the remaining offenders in the various Renesas DTSes.
> >
> > This changes the names in the clk framework too though? If you're
> > ok with that I'm ok too.
> 
> Yes, that's my main motivation doing this: it's a bit silly to have some 
> clocks
> show up in /sys/kernel/debug/clk/clk_summary with a "_clk" suffix.
> 
> > Acked-by: Stephen Boyd 
> 
> Thanks!

Thanks, I have queued these up.

Applied "ASoC: soc-core: verify Sound Card normality" to the asoc tree

[Mark Brown]

The patch

   ASoC: soc-core: verify Sound Card normality

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From c12c1aad98bb75b435e79c6208b56d2018b42f8b Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Mon, 3 Apr 2017 06:31:22 +
Subject: [PATCH] ASoC: soc-core: verify Sound Card normality

Current ALSA SoC Sound Card basically consists of CPU/Codec/Platform
components. If system uses Kernel modules, we can disable these drivers
by using rmmod command. In such case, we can't disable
CPU/Codec/Platform driver without disabling Sound Card driver.

But on the other hand, we can disable these drivers by using unbind
command. In such case, we can disable these drivers randomly.
In this case, we can create dirty Sound Card which is missing necessary
components.

(1) If user disabled Sound Card first, but did nothing to other drivers,
user can't use Sound because Sound Card is no longer exists.
(2) If user disabled CPU/Codec/Platform driver randomly, but did nothing
to Sound Card, user still be able to use Sound Card, because dirty Sound
Card still exists. In this case, Sound system will be crashed if user
started sound playback/capture. But we can't block such random unbind
now.

To avoid Sound Card crash in (2) case, we need to unregister Sound Card
whenever CPU/Codec/Platform component were unregistered.
This patch solves this issue.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 sound/soc/soc-core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index f1901bb1466e..de6d5609c252 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3076,6 +3076,11 @@ static void snd_soc_component_cleanup(struct 
snd_soc_component *component)
 
 static void snd_soc_component_del_unlocked(struct snd_soc_component *component)
 {
+   struct snd_soc_card *card = component->card;
+
+   if (card)
+   snd_soc_unregister_card(card);
+
list_del(>list);
 }
 
-- 
2.11.0

Re: [PATCH v4 4/9] arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header

[Geert Uytterhoeven]

On Wed, Apr 5, 2017 at 4:07 PM, Jacopo Mondi  wrote:
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/r7s72100-pinctrl.h
> @@ -0,0 +1,16 @@
> +/*
> + * 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 its bank and position numbers and store in
> + * the upper 16 bits the alternate function identifier
> + */
> +#define RZA1_PINMUX(b, p, f)   ((b) * RZA1_PINS_PER_PORT + (p) | (f << 16))

... | (f) << 16)

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 0/9] Renesas RZ/A1 pin and gpio controller

[Jacopo Mondi]

Hi Linus,
   this is 4th round of gpio/pincontroller for RZ/A1 devices.

As you suggested in v3 review, I have now added what we called pinmux flags
to the list of standard pinconf generic properties, and we're now using
generic parsing routines to collect them and apply them when multiplexing
pins.

The device tree bindings changed significantly, and as anticipated I have not
incorporated Rob's ack as I would like him to have a look there again.

As a bonus, parsing of pin mux nodes now happens at dt_node_to_map() time, and
not at probe time. This makes the driver play nicely with device tree
overlays, that as Geert pointed out, were not supported in v3.

Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.

Thanks
   j


v1 -> v2:
- change pin configuration flags as suggested by Chris
- gpio set direction function fixed as suggested by Chris
- add some more example on pin configuration flag usage to dt-binding doc
- fix gpio-controller names to remove unit address as suggested by Geert
- some comments chopped here and there to make the driver less verbose

v2 -> v3:
- fix grammar and syntax in comment and documentation
- fix code style (reverse xmas tree ordering in variable declaration)
- use irqsave/irqrestore in spinlock lock/unlock
- use devm_ version of kasprintf (memory returned was not properly free)
- use bitops.h operation ffs and fls to make sure a single bit is set in pmx
  mask
- Add Geert's reviewed-by to DTS patches

v3 -> v4:
- use "pinmux" property in pmx sub-nodes in place of "renesas,pins"
- use pinconf standard properties to set pin mux additional flags
- add "bi-directional" and "output-enable" to pinconf generic properties
- perform pmx function parsing at dt_node_to_map() time
- change DT bindings to use GENERIC_PINCONF
- change DT bindings to allow sub-nodes to have "pinmux" property specified
- several renames (register names, DT parse functions, set_mux() function)

Jacopo Mondi (9):
  pinctrl: generic: Add bi-directional and output-enable
  pinctrl: Renesas RZ/A1 pin and gpio controller
  dt-bindings: pinctrl: Add RZ/A1 bindings doc
  arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
  arm: dts: r7s72100: Add pin controller node
  arm: dts: genmai: Add SCIF2 pin group
  arm: dts: genmai: Add RIIC2 pin group
  arm: dts: genmai: Add user led device nodes
  arm: dts: genmai: Add ethernet pin group

 .../bindings/pinctrl/pinctrl-bindings.txt  |   2 +
 .../bindings/pinctrl/renesas,rza1-pinctrl.txt  | 218 +
 arch/arm/boot/dts/r7s72100-genmai.dts  |  76 ++
 arch/arm/boot/dts/r7s72100.dtsi|  78 ++
 drivers/pinctrl/Kconfig|  11 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/pinconf-generic.c  |   3 +
 drivers/pinctrl/pinctrl-rza1.c | 995 +
 include/dt-bindings/pinctrl/r7s72100-pinctrl.h |  16 +
 include/linux/pinctrl/pinconf-generic.h|   3 +
 10 files changed, 1403 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-rza1.c
 create mode 100644 include/dt-bindings/pinctrl/r7s72100-pinctrl.h

--
2.7.4

[PATCH v4 6/9] arm: dts: genmai: Add SCIF2 pin group

[Jacopo Mondi]

Add pin configuration subnode for SCIF2 serial debug interface.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r7s72100-genmai.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts 
b/arch/arm/boot/dts/r7s72100-genmai.dts
index 118a8e2..c28d74b 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "r7s72100.dtsi"
+#include 
 
 / {
model = "Genmai";
@@ -36,6 +37,14 @@
};
 };
 
+ {
+
+   scif2_pins: serial2 {
+   /* P3_0 as TxD2; P3_2 as RxD2 */
+   pinmux = , ;
+   };
+};
+
 _clk {
clock-frequency = <1333>;
 };
@@ -60,6 +69,9 @@
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
status = "okay";
 };
 
-- 
2.7.4

[PATCH v4 9/9] arm: dts: genmai: Add ethernet pin group

[Jacopo Mondi]

Add pin configuration subnode for ETHER ethernet controller.

Signed-off-by: Jacopo Mondi 
---
 arch/arm/boot/dts/r7s72100-genmai.dts | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts 
b/arch/arm/boot/dts/r7s72100-genmai.dts
index f7c512e..328f4c9 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -63,6 +63,34 @@
pinmux = , ;
bi-directional;
};
+
+   ether_pins: ether {
+   pins {
+   /* Ethernet on Ports 1,2,3,5 */
+   pinmux = ,/* P1_14 = ET_COL  */
+, /* P5_9 = ET_MDC   */
+, /* 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 */
+   };
+
+   pins_bidir {
+   pinmux = ;/* P3_3 = ET_MDIO  */
+   bi-directional;
+   };
+   };
 };
 
 _clk {
@@ -77,6 +105,19 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+
+   renesas,no-ether-link;
+   phy-handle = <>;
+   phy0: ethernet-phy@0 {
+   reg = <0>;
+   };
+};
+
  {
status = "okay";
clock-frequency = <40>;
-- 
2.7.4

[PATCH v4 8/9] arm: dts: genmai: Add user led device nodes

[Jacopo Mondi]

Add device nodes for user leds on Genmai board.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r7s72100-genmai.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts 
b/arch/arm/boot/dts/r7s72100-genmai.dts
index 9add1b6..f7c512e 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "r7s72100.dtsi"
+#include 
 #include 
 
 / {
@@ -35,6 +36,19 @@
#address-cells = <1>;
#size-cells = <1>;
};
+
+   leds {
+   status = "okay";
+   compatible = "gpio-leds";
+
+   led1 {
+   gpios = < 10 GPIO_ACTIVE_LOW>;
+   };
+
+   led2 {
+   gpios = < 11 GPIO_ACTIVE_LOW>;
+   };
+   };
 };
 
  {
-- 
2.7.4

[PATCH v4 7/9] arm: dts: genmai: Add RIIC2 pin group

[Jacopo Mondi]

Add pin configuration subnode for RIIC2 interface.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r7s72100-genmai.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts 
b/arch/arm/boot/dts/r7s72100-genmai.dts
index c28d74b..9add1b6 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -43,6 +43,12 @@
/* P3_0 as TxD2; P3_2 as RxD2 */
pinmux = , ;
};
+
+   i2c2_pins: i2c2 {
+   /* RIIC2: P1_4 as SCL, P1_5 as SDA */
+   pinmux = , ;
+   bi-directional;
+   };
 };
 
 _clk {
@@ -61,6 +67,9 @@
status = "okay";
clock-frequency = <40>;
 
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
eeprom@50 {
compatible = "renesas,24c128";
reg = <0x50>;
-- 
2.7.4

[PATCH v4 1/9] pinctrl: generic: Add bi-directional and output-enable

[Jacopo Mondi]

Add bi-directional and output-enable pin configuration properties.

bi-directional allows to specify when a pin shall operate in input and
output mode at the same time. This is particularly useful in platforms
where input and output buffers have to be manually enabled.

output-enable is just syntactic sugar to specify that a pin shall
operate in output mode, ignoring the provided argument.
This pairs with input-enable pin configuration option.

Signed-off-by: Jacopo Mondi 
---
 Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 2 ++
 drivers/pinctrl/pinconf-generic.c  | 3 +++
 include/linux/pinctrl/pinconf-generic.h| 3 +++
 3 files changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index bf3f7b0..f2ed458 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -222,6 +222,7 @@ bias-bus-hold   - latch weakly
 bias-pull-up   - pull up the pin
 bias-pull-down - pull down the pin
 bias-pull-pin-default  - use pin-default pull state
+bi-directional - pin supports simultaneous input/output operations
 drive-push-pull- drive actively high and low
 drive-open-drain   - drive with open drain
 drive-open-source  - drive with open source
@@ -234,6 +235,7 @@ input-debounce  - debounce mode with debound 
time X
 power-source   - select between different power supplies
 low-power-enable   - enable low power mode
 low-power-disable  - disable low power mode
+output-enable  - enable output on pin regardless of output value
 output-low - set the pin to output mode with low level
 output-high- set the pin to output mode with high level
 slew-rate  - set the slew rate
diff --git a/drivers/pinctrl/pinconf-generic.c 
b/drivers/pinctrl/pinconf-generic.c
index ce3335a..03e6808 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -35,6 +35,7 @@ static const struct pin_config_item conf_items[] = {
PCONFDUMP(PIN_CONFIG_BIAS_PULL_PIN_DEFAULT,
"input bias pull to pin specific state", NULL, 
false),
PCONFDUMP(PIN_CONFIG_BIAS_PULL_UP, "input bias pull up", NULL, false),
+   PCONFDUMP(PIN_CONFIG_BIDIRECTIONAL, "bi-directional pin operations", 
NULL, false),
PCONFDUMP(PIN_CONFIG_DRIVE_OPEN_DRAIN, "output drive open drain", NULL, 
false),
PCONFDUMP(PIN_CONFIG_DRIVE_OPEN_SOURCE, "output drive open source", 
NULL, false),
PCONFDUMP(PIN_CONFIG_DRIVE_PUSH_PULL, "output drive push pull", NULL, 
false),
@@ -160,6 +161,7 @@ static const struct pinconf_generic_params dt_params[] = {
{ "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
{ "bias-pull-pin-default", PIN_CONFIG_BIAS_PULL_PIN_DEFAULT, 1 },
{ "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 1 },
+   { "bi-directional", PIN_CONFIG_BIDIRECTIONAL, 1 },
{ "drive-open-drain", PIN_CONFIG_DRIVE_OPEN_DRAIN, 0 },
{ "drive-open-source", PIN_CONFIG_DRIVE_OPEN_SOURCE, 0 },
{ "drive-push-pull", PIN_CONFIG_DRIVE_PUSH_PULL, 0 },
@@ -172,6 +174,7 @@ static const struct pinconf_generic_params dt_params[] = {
{ "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
{ "low-power-disable", PIN_CONFIG_LOW_POWER_MODE, 0 },
{ "low-power-enable", PIN_CONFIG_LOW_POWER_MODE, 1 },
+   { "output-enable", PIN_CONFIG_OUTPUT, 1, },
{ "output-high", PIN_CONFIG_OUTPUT, 1, },
{ "output-low", PIN_CONFIG_OUTPUT, 0, },
{ "power-source", PIN_CONFIG_POWER_SOURCE, 0 },
diff --git a/include/linux/pinctrl/pinconf-generic.h 
b/include/linux/pinctrl/pinconf-generic.h
index 7620eb1..279e3c5 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -42,6 +42,8 @@
  * @PIN_CONFIG_BIAS_PULL_UP: the pin will be pulled up (usually with high
  * impedance to VDD). If the argument is != 0 pull-up is enabled,
  * if it is 0, pull-up is total, i.e. the pin is connected to VDD.
+ * @PIN_CONFIG_BIDIRECTIONAL: the pin will be configured to allow simultaneous
+ * input and output operations.
  * @PIN_CONFIG_DRIVE_OPEN_DRAIN: the pin will be driven with open drain (open
  * collector) which means it is usually wired with other output ports
  * which are then pulled up with an external resistor. Setting this
@@ -96,6 +98,7 @@ enum pin_config_param {
PIN_CONFIG_BIAS_PULL_DOWN,
PIN_CONFIG_BIAS_PULL_PIN_DEFAULT,
PIN_CONFIG_BIAS_PULL_UP,
+   PIN_CONFIG_BIDIRECTIONAL,
PIN_CONFIG_DRIVE_OPEN_DRAIN,
PIN_CONFIG_DRIVE_OPEN_SOURCE,
PIN_CONFIG_DRIVE_PUSH_PULL,
-- 
2.7.4

Re: [PATCH v4 0/3] phy: Group phy drivers based on vendor listing

[Kishon Vijay Abraham I]

Hi Vivek,

On Wednesday 05 April 2017 05:07 PM, Vivek Gautam wrote:
> Hi Kishon,
> 
> 
> On 04/05/2017 04:34 PM, Kishon Vijay Abraham I wrote:
>> Hi Vivek,
>>
>> On Monday 20 March 2017 06:49 PM, Vivek Gautam wrote:
>>> This is the next version to an earlier posted series [1].
>>> Missed Cc'ing the first patch of the previous series [1] to lkml.
>>> Posting out this series now after addressing comments
>>> and after adding the received 'Acked-by' and 'Reviewed-by'
>>> tags.
>>>
>>> This series is based on linux-phy/next branch.
>>>
>>> [1] https://www.spinics.net/lists/arm-kernel/msg568370.html
>>>
>>> Signed-off-by: Vivek Gautam 
>>> Cc: Kishon Vijay Abraham I 
>>> Cc: linux-arm-ker...@lists.infradead.org
>>> Cc: linux-arm-...@vger.kernel.org
>>> Cc: linux-ker...@vger.kernel.org
>>> Cc: linux-...@vger.kernel.org
>> The best time to merge this would be immediately after -rc1 is tagged. Can 
>> you
>> resend when 4.12-rc1 is tagged?
> 
> Sure, I will send the series when 4.12-rc1 is out.
> I am also planning to send qcom phy's next version and i had rebased the
> earlier version on this patch series. Should i just rebase those patches on
> top of phy/next, or on this series?

phy/next please..

-Kishon

> 
> 
> Best Regards
> Vivek
> 
>>
>> Thanks
>> Kishon
>>
>>> -- 
>>> Vivek Gautam (3):
>>>phy: qcom-usb: Remove unused ulpi phy header
>>>phy: Move ULPI phy header out of drivers to include path
>>>phy: Group vendor specific phy drivers
>>>
>>>   MAINTAINERS|  18 +-
>>>   drivers/phy/Kconfig| 471
>>> +
>>>   drivers/phy/Makefile   |  67 +--
>>>   drivers/phy/allwinner/Kconfig  |  31 ++
>>>   drivers/phy/allwinner/Makefile |   2 +
>>>   drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
>>>   drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
>>>   drivers/phy/broadcom/Kconfig   |  64 +++
>>>   drivers/phy/broadcom/Makefile  |   7 +
>>>   drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
>>>   drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
>>>   drivers/phy/hisilicon/Kconfig  |  20 +
>>>   drivers/phy/hisilicon/Makefile |   2 +
>>>   drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
>>>   drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
>>>   drivers/phy/marvell/Kconfig|  50 +++
>>>   drivers/phy/marvell/Makefile   |   6 +
>>>   drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
>>>   drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
>>>   drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
>>>   drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
>>>   drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
>>>   drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
>>>   drivers/phy/qualcomm/Kconfig   |  38 ++
>>>   drivers/phy/qualcomm/Makefile  |   7 +
>>>   drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   2 -
>>>   drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   2 -
>>>   drivers/phy/renesas/Kconfig|  17 +
>>>   drivers/phy/renesas/Makefile   |   2 +
>>>   drivers/phy/{ => renesas}/phy-rcar-gen2.c  |   0
>>>   drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c |   0
>>>   drivers/phy/rockchip/Kconfig   |  51 +++
>>>   drivers/phy/rockchip/Makefile  |   6 +
>>>   drivers/phy/{ => rockchip}/phy-rockchip-dp.c   |   0
>>>   drivers/phy/{ => rockchip}/phy-rockchip-emmc.c |   0
>>>   .../phy/{ => rockchip}/phy-rockchip-inno-usb2.c|   0
>>>   drivers/phy/{ => rockchip}/phy-rockchip-pcie.c |   0
>>>   drivers/phy/{ => rockchip}/phy-rockchip-typec.c|   0
>>>   drivers/phy/{ => rockchip}/phy-rockchip-usb.c  |   0
>>>   drivers/phy/samsung/Kconfig|  96 +
>>>   drivers/phy/samsung/Makefile   |  

Re: [PATCH v4 0/3] phy: Group phy drivers based on vendor listing

[Kishon Vijay Abraham I]

Hi Vivek,

On Monday 20 March 2017 06:49 PM, Vivek Gautam wrote:
> This is the next version to an earlier posted series [1].
> Missed Cc'ing the first patch of the previous series [1] to lkml.
> Posting out this series now after addressing comments
> and after adding the received 'Acked-by' and 'Reviewed-by'
> tags.
> 
> This series is based on linux-phy/next branch.
> 
> [1] https://www.spinics.net/lists/arm-kernel/msg568370.html
> 
> Signed-off-by: Vivek Gautam 
> Cc: Kishon Vijay Abraham I 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-...@vger.kernel.org

The best time to merge this would be immediately after -rc1 is tagged. Can you
resend when 4.12-rc1 is tagged?

Thanks
Kishon

> 
> --
> Vivek Gautam (3):
>   phy: qcom-usb: Remove unused ulpi phy header
>   phy: Move ULPI phy header out of drivers to include path
>   phy: Group vendor specific phy drivers
> 
>  MAINTAINERS|  18 +-
>  drivers/phy/Kconfig| 471 
> +
>  drivers/phy/Makefile   |  67 +--
>  drivers/phy/allwinner/Kconfig  |  31 ++
>  drivers/phy/allwinner/Makefile |   2 +
>  drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
>  drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
>  drivers/phy/broadcom/Kconfig   |  64 +++
>  drivers/phy/broadcom/Makefile  |   7 +
>  drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
>  drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
>  drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
>  drivers/phy/hisilicon/Kconfig  |  20 +
>  drivers/phy/hisilicon/Makefile |   2 +
>  drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
>  drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
>  drivers/phy/marvell/Kconfig|  50 +++
>  drivers/phy/marvell/Makefile   |   6 +
>  drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
>  drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
>  drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
>  drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
>  drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
>  drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
>  drivers/phy/qualcomm/Kconfig   |  38 ++
>  drivers/phy/qualcomm/Makefile  |   7 +
>  drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   2 -
>  drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   2 -
>  drivers/phy/renesas/Kconfig|  17 +
>  drivers/phy/renesas/Makefile   |   2 +
>  drivers/phy/{ => renesas}/phy-rcar-gen2.c  |   0
>  drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c |   0
>  drivers/phy/rockchip/Kconfig   |  51 +++
>  drivers/phy/rockchip/Makefile  |   6 +
>  drivers/phy/{ => rockchip}/phy-rockchip-dp.c   |   0
>  drivers/phy/{ => rockchip}/phy-rockchip-emmc.c |   0
>  .../phy/{ => rockchip}/phy-rockchip-inno-usb2.c|   0
>  drivers/phy/{ => rockchip}/phy-rockchip-pcie.c |   0
>  drivers/phy/{ => rockchip}/phy-rockchip-typec.c|   0
>  drivers/phy/{ => rockchip}/phy-rockchip-usb.c  |   0
>  drivers/phy/samsung/Kconfig|  96 +
>  drivers/phy/samsung/Makefile   |  11 +
>  drivers/phy/{ => samsung}/phy-exynos-dp-video.c|   0
>  drivers/phy/{ => samsung}/phy-exynos-mipi-video.c  |   0
>  drivers/phy/{ => samsung}/phy-exynos-pcie.c|   0
>  drivers/phy/{ => samsung}/phy-exynos4210-usb2.c|   0
>  drivers/phy/{ => samsung}/phy-exynos4x12-usb2.c|   0
>  drivers/phy/{ => samsung}/phy-exynos5-usbdrd.c |   0
>  drivers/phy/{ => samsung}/phy-exynos5250-sata.c|   0
>  drivers/phy/{ => samsung}/phy-exynos5250-usb2.c|   0
>  drivers/phy/{ => samsung}/phy-s5pv210-usb2.c   |   0
>  drivers/phy/{ => samsung}/phy-samsung-usb2.c   |   0
>  drivers/phy/{ => samsung}/phy-samsung-usb2.h   |   0
>  

Re: [PATCH 3/3] dmaengine: rcar-dmac: wait for ISR to finish before freeing resources

[Geert Uytterhoeven]

Hi Niklas,

(CC Laurent)

On Wed, Apr 5, 2017 at 11:14 AM, Niklas Söderlund
 wrote:
> On 2017-04-05 08:55:31 +0530, Vinod Koul wrote:
>> On Thu, Mar 30, 2017 at 09:38:39AM +0200, Niklas Söderlund wrote:
>> > On 2017-03-29 15:30:42 +0200, Niklas Söderlund wrote:
>> > > On 2017-03-29 14:31:33 +0200, Geert Uytterhoeven wrote:
>> > > > On Wed, Mar 29, 2017 at 12:40 AM, Niklas Söderlund
>> > > >  wrote:
>> > > > > This fixes a race condition where the channel resources could be 
>> > > > > freed
>> > > > > before the ISR had finished running resulting in a NULL pointer
>> > > > > reference from the ISR.
>> > > > >
>> > > > > [  167.148934] Unable to handle kernel NULL pointer dereference at 
>> > > > > virtual address 
>> > > > > [  167.157051] pgd = 80003c641000
>> > > > > [  167.160449] [] *pgd=7c507003, 
>> > > > > *pud=7c4ff003, *pmd=
>> > > > > [  167.168719] Internal error: Oops: 9646 [#1] PREEMPT SMP
>> > > > > [  167.174289] Modules linked in:
>> > > > > [  167.177348] CPU: 3 PID: 10547 Comm: dma_ioctl Not tainted 
>> > > > > 4.11.0-rc1-1-g8d92afddc2f6633a #73
>> > > > > [  167.186131] Hardware name: Renesas Salvator-X board based on 
>> > > > > r8a7795 (DT)
>> > > > > [  167.192917] task: 80003a411a00 task.stack: 80003bcd4000
>> > > > > [  167.198850] PC is at rcar_dmac_chan_prep_sg+0xe0/0x400
>> > > > > [  167.203985] LR is at rcar_dmac_chan_prep_sg+0x48/0x400
>> > > >
>> > > > Do you have a test case to trigger this?
>> > >
>> > > Yes I have a testcase, it's rather complex and involves both a kernel
>> > > module and a userspaces application to stress the rcar-dmac. I'm
>> > > checking if I can share this publicly or not, please hold :-)
>> >
>> > I have now received feedback that I'm unfortunately not allowed to share
>> > the test case :-(
>> >
>> > The big picture in how to trigger this problem is that you start a DMA
>> > transfer like this:
>> >
>> > struct dma_async_tx_descriptor *tx = ...;
>> >
>> > ...
>> >
>> > tx->tx_submit(tx);
>> >
>> > And then you directly call dma_release_channel() on this channel without
>> > making sure the completion callback ran or anything. Now if you are
>> > unlucky the ISR have not finished running for the DMA when
>> > dma_release_channel() starts to clean up resources. The synchronisation
>> > point in the dma_release_channel() call path fixes this.
>>
>> Well the API expectation would be you abort the txn before calling release.
>> So the expected order should be:
>>
>> dmaengine_terminate_all();
>> dma_release_channel();
>
> Agree this is the correct way and in this case patch 3/3 in this series
> could be dropped. Then device_synchronize() would added to rcar-dmac,
> dmaengine_terminate_all() would turn of the IRQ and
> dma_release_channel() would ensure that device_synchronize() is called
> prior to calling rcar-dmac device_free_chan_resources().
>
>>
>> Terminate should then stop the channel, ie abort the pending descriptors..
>>
>
> However for reasons unknown to me the rcar-dmac
> device_free_chan_resources() implementation implements logic to turn of
> IRQs before it frees the resources. And it's because of this patch 3/3
> is needed so that it can be sure no ISR is running before it frees
> resources.
>
> I don't know how to best proceed here. I agree it feels a bit odd that
> device_free_chan_resources() is dealing with the IRQs as such things
> should be done before it's called. But on the other hand that code has
> been part of the driver since it was added upstream. I feel a bit
> uncomfortable just removing that part from the
> device_free_chan_resources() since the driver have been in use with it
> for such a long time.
>
> How would you prefer I try and resolve this?

Perhaps Laurent knows why it was implemented this way?

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 3/3] dmaengine: rcar-dmac: wait for ISR to finish before freeing resources

[Niklas Söderlund]

Hi Vinod,

On 2017-04-05 08:55:31 +0530, Vinod Koul wrote:
> On Thu, Mar 30, 2017 at 09:38:39AM +0200, Niklas Söderlund wrote:
> > Hi Geert,
> > 
> > On 2017-03-29 15:30:42 +0200, Niklas Söderlund wrote:
> > > Hi Geert,
> > > 
> > > On 2017-03-29 14:31:33 +0200, Geert Uytterhoeven wrote:
> > > > Hi Niklas,
> > > > 
> > > > On Wed, Mar 29, 2017 at 12:40 AM, Niklas Söderlund
> > > >  wrote:
> > > > > This fixes a race condition where the channel resources could be freed
> > > > > before the ISR had finished running resulting in a NULL pointer
> > > > > reference from the ISR.
> > > > >
> > > > > [  167.148934] Unable to handle kernel NULL pointer dereference at 
> > > > > virtual address 
> > > > > [  167.157051] pgd = 80003c641000
> > > > > [  167.160449] [] *pgd=7c507003, 
> > > > > *pud=7c4ff003, *pmd=
> > > > > [  167.168719] Internal error: Oops: 9646 [#1] PREEMPT SMP
> > > > > [  167.174289] Modules linked in:
> > > > > [  167.177348] CPU: 3 PID: 10547 Comm: dma_ioctl Not tainted 
> > > > > 4.11.0-rc1-1-g8d92afddc2f6633a #73
> > > > > [  167.186131] Hardware name: Renesas Salvator-X board based on 
> > > > > r8a7795 (DT)
> > > > > [  167.192917] task: 80003a411a00 task.stack: 80003bcd4000
> > > > > [  167.198850] PC is at rcar_dmac_chan_prep_sg+0xe0/0x400
> > > > > [  167.203985] LR is at rcar_dmac_chan_prep_sg+0x48/0x400
> > > > 
> > > > Do you have a test case to trigger this?
> > > 
> > > Yes I have a testcase, it's rather complex and involves both a kernel 
> > > module and a userspaces application to stress the rcar-dmac. I'm 
> > > checking if I can share this publicly or not, please hold :-)
> > 
> > I have now received feedback that I'm unfortunately not allowed to share 
> > the test case :-(
> > 
> > The big picture in how to trigger this problem is that you start a DMA 
> > transfer like this:
> > 
> > struct dma_async_tx_descriptor *tx = ...;
> > 
> > ...
> > 
> > tx->tx_submit(tx);
> > 
> > And then you directly call dma_release_channel() on this channel without 
> > making sure the completion callback ran or anything. Now if you are 
> > unlucky the ISR have not finished running for the DMA when 
> > dma_release_channel() starts to clean up resources. The synchronisation 
> > point in the dma_release_channel() call path fixes this.
> 
> Well the API expectation would be you abort the txn before calling release.
> So the expected order should be:
> 
> dmaengine_terminate_all();
> dma_release_channel();

Agree this is the correct way and in this case patch 3/3 in this series 
could be dropped. Then device_synchronize() would added to rcar-dmac, 
dmaengine_terminate_all() would turn of the IRQ and 
dma_release_channel() would ensure that device_synchronize() is called 
prior to calling rcar-dmac device_free_chan_resources().

> 
> Terminate should then stop the channel, ie abort the pending descriptors..
> 

However for reasons unknown to me the rcar-dmac 
device_free_chan_resources() implementation implements logic to turn of 
IRQs before it frees the resources. And it's because of this patch 3/3 
is needed so that it can be sure no ISR is running before it frees 
resources.

I don't know how to best proceed here. I agree it feels a bit odd that 
device_free_chan_resources() is dealing with the IRQs as such things 
should be done before it's called. But on the other hand that code has 
been part of the driver since it was added upstream. I feel a bit 
uncomfortable just removing that part from the 
device_free_chan_resources() since the driver have been in use with it 
for such a long time.

How would you prefer I try and resolve this?

-- 
Regards,
Niklas Söderlund

Re: [PATCH v2 09/13] arm64: dts: r8a7795: salvator-x: Add panel backlight support

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Apr 5, 2017 at 10:45 AM, Laurent Pinchart
 wrote:
> On Monday 21 Nov 2016 11:59:47 Laurent Pinchart wrote:
>> On Monday 21 Nov 2016 10:23:46 Geert Uytterhoeven wrote:
>> > On Mon, Nov 21, 2016 at 10:19 AM, Laurent Pinchart wrote:
>> >> On Monday 21 Nov 2016 09:36:22 Geert Uytterhoeven wrote:
>> >>> On Sat, Nov 19, 2016 at 4:28 AM, Laurent Pinchart wrote:
>>  The panel backlight is controlled through a GPIO and a PWM channel.
>> 
>>  --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
>>  +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
>>  @@ -178,6 +178,16 @@
>>  };
>>  };
>>  };
>>  +
>>  +   backlight: backlight {
>>  +   compatible = "pwm-backlight";
>>  +   pwms = < 0 5>;
>>  +
>>  +   brightness-levels = <256 128 64 16 8 4 0>;
>> >>>
>> >>> Would it make sense to define more and/or linear levels?
>> >>
>> >> Possibly, this is pretty arbitrary. Linear levels might not be the best
>> >> option given that the human eye doesn't have a linear response to light
>> >> power, but we
>> >
>> > It not only depends on the human eye, but also on the backlight hardware
>> > (is the conversion from voltage (L_VBRT) to light linear?).
>>
>> So we need to specify transfer functions in DT ;-)
>>
>> >> could certainly have more levels. In that case I'd prefer modifying the
>> >> pwm- backlight DT bindings though, and specifying the PWM resolution
>> >> instead of discrete levels.
>> >>
>> >> Note that the LVDS panel backlight PWM control signal is multiplexed
>> >> with the external memory A21 signal on the Salvator-X board, with SW5
>> >> selecting which how to route the signal. When using backlight control we
>> >> can't access the whole NOR flash anymore, so I'm not sure this patch
>> >> should be merged.
>> >
>> > That NOR flash is also optional, right?
>> > My Ex Memory Connector is not populated.
>>
>> That's correct. The Salvator-X DT file in mainline is just an example
>> anyway, and we should pick the most useful peripherals for that purpose.
>
> Would you like me to include this in my next Salvator-X DT patch series for
> upstream merge ?

That's fine for me (CC Simon). Thx!

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 09/13] arm64: dts: r8a7795: salvator-x: Add panel backlight support

[Laurent Pinchart]

Hi Geert,

On Monday 21 Nov 2016 11:59:47 Laurent Pinchart wrote:
> On Monday 21 Nov 2016 10:23:46 Geert Uytterhoeven wrote:
> > On Mon, Nov 21, 2016 at 10:19 AM, Laurent Pinchart wrote:
> >> On Monday 21 Nov 2016 09:36:22 Geert Uytterhoeven wrote:
> >>> On Sat, Nov 19, 2016 at 4:28 AM, Laurent Pinchart wrote:
>  The panel backlight is controlled through a GPIO and a PWM channel.
>  
>  --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
>  +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
>  @@ -178,6 +178,16 @@
>  };
>  };
>  };
>  +
>  +   backlight: backlight {
>  +   compatible = "pwm-backlight";
>  +   pwms = < 0 5>;
>  +
>  +   brightness-levels = <256 128 64 16 8 4 0>;
> >>> 
> >>> Would it make sense to define more and/or linear levels?
> >> 
> >> Possibly, this is pretty arbitrary. Linear levels might not be the best
> >> option given that the human eye doesn't have a linear response to light
> >> power, but we
> > 
> > It not only depends on the human eye, but also on the backlight hardware
> > (is the conversion from voltage (L_VBRT) to light linear?).
> 
> So we need to specify transfer functions in DT ;-)
> 
> >> could certainly have more levels. In that case I'd prefer modifying the
> >> pwm- backlight DT bindings though, and specifying the PWM resolution
> >> instead of discrete levels.
> >> 
> >> Note that the LVDS panel backlight PWM control signal is multiplexed
> >> with the external memory A21 signal on the Salvator-X board, with SW5
> >> selecting which how to route the signal. When using backlight control we
> >> can't access the whole NOR flash anymore, so I'm not sure this patch
> >> should be merged.
> > 
> > That NOR flash is also optional, right?
> > My Ex Memory Connector is not populated.
> 
> That's correct. The Salvator-X DT file in mainline is just an example
> anyway, and we should pick the most useful peripherals for that purpose.

Would you like me to include this in my next Salvator-X DT patch series for 
upstream merge ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: rcar-du: Document the vsps property in the DT bindings

[Laurent Pinchart]

Hi Geert,

On Wednesday 05 Apr 2017 09:54:38 Geert Uytterhoeven wrote:
> On Fri, Mar 31, 2017 at 11:21 AM, Geert Uytterhoeven wrote:
> > On Fri, Mar 31, 2017 at 11:19 AM, Laurent Pinchart wrote:
> >> On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
> >>> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
>  The property is used by the driver but is missing from the DT
>  bindings. Document it.
>  
>  Reported-by: Geert Uytterhoeven 
>  Signed-off-by: Laurent Pinchart
>  
>  ---
>  
>   Documentation/devicetree/bindings/display/renesas,du.txt | 5 +
>   1 file changed, 5 insertions(+)
>  
>  diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
>  b/Documentation/devicetree/bindings/display/renesas,du.txt index
>  1a02f099a0ff..cf34893a1b53 100644
>  --- a/Documentation/devicetree/bindings/display/renesas,du.txt
>  +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
>  
>  @@ -36,6 +36,11 @@ Required Properties:
> When supplied they must be named "dclkin.x" with "x" being the
> input clock numerical index.
> >>> > 
> >>> > +Optional Properties:
> >>> > +
> >>> > +  - vsps: A list of phandles to the VSP nodes that handle the memory
> >>> > +interfaces for the DU channels (Gen3 only).
> >>> 
> >>> ", one per channel"?
> >>> 
> >>> Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
> >> 
> >> How about making it mandatory on Gen2 as well ? The VSPs are there, even
> >> if the driver doesn't use them, it makes sense to describe the
> >> connection. Of
> > 
> > Fine for me, as this is hardware description.
> > 
> >> course the driver will treat the property as optional for backward
> >> compatibility.
> > 
> > OK.
> 
> Will you do this as an incremental update?
> I noticed the initial version is now in drm-next.

I've included it in the pull request by mistake and realized that too late, 
sorry :-/ I will send an incremental update.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: rcar-du: Document the vsps property in the DT bindings

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Mar 31, 2017 at 11:21 AM, Geert Uytterhoeven
 wrote:
> On Fri, Mar 31, 2017 at 11:19 AM, Laurent Pinchart
>  wrote:
>> On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
>>> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
>>> > The property is used by the driver but is missing from the DT bindings.
>>> > Document it.
>>> >
>>> > Reported-by: Geert Uytterhoeven 
>>> > Signed-off-by: Laurent Pinchart
>>> > 
>>> > ---
>>> >  Documentation/devicetree/bindings/display/renesas,du.txt | 5 +
>>> >  1 file changed, 5 insertions(+)
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
>>> > b/Documentation/devicetree/bindings/display/renesas,du.txt index
>>> > 1a02f099a0ff..cf34893a1b53 100644
>>> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
>>> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
>>> >
>>> > @@ -36,6 +36,11 @@ Required Properties:
>>> >When supplied they must be named "dclkin.x" with "x" being the
>>> >input
>>> >clock numerical index.
>>> >
>>> > +Optional Properties:
>>> > +
>>> > +  - vsps: A list of phandles to the VSP nodes that handle the memory
>>> > +interfaces for the DU channels (Gen3 only).
>>>
>>> ", one per channel"?
>>>
>>> Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
>>
>> How about making it mandatory on Gen2 as well ? The VSPs are there, even if
>> the driver doesn't use them, it makes sense to describe the connection. Of
>
> Fine for me, as this is hardware description.
>
>> course the driver will treat the property as optional for backward
>> compatibility.
>
> OK.

Will you do this as an incremental update?
I noticed the initial version is now in drm-next.

Thanks!

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] pinctrl: sh-pfc: r8a7794: swap ATA signals

[Geert Uytterhoeven]

Hi Sergei,

On Tue, Apr 4, 2017 at 10:22 PM, Sergei Shtylyov
 wrote:
> On 04/04/2017 11:20 PM, Sergei Shtylyov wrote:
>> All R8A7794 manuals  I have here (0.50 and 1.10) agree that the PFC driver
>> has ATAG0#  and ATAWR# signals in IPSR12 swapped -- fix this.

Thanks!

>Oops, ATAWR0#. Do I need to resend?

No, I can handle that.

>> Fixes: 43c4436e2f18 ("pinctrl: sh-pfc: add R8A7794 PFC support")
>> Signed-off-by: Sergei Shtylyov 

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 0/3] arm: dts: renesas: Drop _clk suffix from clock node names

[Geert Uytterhoeven]

Hi Stephen,

On Wed, Apr 5, 2017 at 3:38 AM, Stephen Boyd  wrote:
> On 04/03, Geert Uytterhoeven wrote:
>> The current practice is to not add _clk suffixes to clock node names in
>> DT, as these names are used as the actual clock names.
>>
>> This patch removes the remaining offenders in the various Renesas DTSes.
>
> This changes the names in the clk framework too though? If you're
> ok with that I'm ok too.

Yes, that's my main motivation doing this: it's a bit silly to have some clocks
show up in /sys/kernel/debug/clk/clk_summary with a "_clk" suffix.

> Acked-by: Stephen Boyd 

Thanks!

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