[renesas-drivers:topic/vsp1/tlb-optimise-v2-rebased1 6/8] drivers/media/platform/vsp1/vsp1_video.c:808:8: error: implicit declaration of function 'vsp1_dl_list_get_body'

[kbuild test robot]

tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
topic/vsp1/tlb-optimise-v2-rebased1
head:   b027d5857edb7bc9fa19b8605fb6b98f6479a05e
commit: a7855204b1ca49db2543fb861fa852ce8d280fd0 [6/8] v4l: vsp1: Adapt 
entities to configure into a body
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a7855204b1ca49db2543fb861fa852ce8d280fd0
# save the attached .config to linux build tree
make.cross ARCH=arm64 

Note: the renesas-drivers/topic/vsp1/tlb-optimise-v2-rebased1 HEAD 
b027d5857edb7bc9fa19b8605fb6b98f6479a05e builds fine.
  It only hurts bisectibility.

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

   drivers/media/platform/vsp1/vsp1_video.c: In function 
'vsp1_video_setup_pipeline':
>> drivers/media/platform/vsp1/vsp1_video.c:808:8: error: implicit declaration 
>> of function 'vsp1_dl_list_get_body' [-Werror=implicit-function-declaration]
 dlb = vsp1_dl_list_get_body(pipe->dl);
   ^
>> drivers/media/platform/vsp1/vsp1_video.c:808:6: warning: assignment makes 
>> pointer from integer without a cast [-Wint-conversion]
 dlb = vsp1_dl_list_get_body(pipe->dl);
 ^
   cc1: some warnings being treated as errors

vim +/vsp1_dl_list_get_body +808 drivers/media/platform/vsp1/vsp1_video.c

   790  
   791  static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
   792  {
   793  struct vsp1_entity *entity;
   794  struct vsp1_dl_body *dlb;
   795  int ret;
   796  
   797  /* Determine this pipelines sizes for image partitioning 
support. */
   798  ret = vsp1_video_pipeline_setup_partitions(pipe);
   799  if (ret < 0)
   800  return ret;
   801  
   802  /* Prepare the display list. */
   803  pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
   804  if (!pipe->dl)
   805  return -ENOMEM;
   806  
   807  /* Retrieve the default DLB from the list */
 > 808  dlb = vsp1_dl_list_get_body(pipe->dl);
   809  
   810  if (pipe->uds) {
   811  struct vsp1_uds *uds = to_uds(>uds->subdev);
   812  
   813  /*
   814   * If a BRU or BRS is present in the pipeline before 
the UDS,
   815   * the alpha component doesn't need to be scaled as the 
BRU and
   816   * BRS output alpha value is fixed to 255. Otherwise we 
need to
   817   * scale the alpha component only when available at the 
input
   818   * RPF.
   819   */
   820  if (pipe->uds_input->type == VSP1_ENTITY_BRU ||
   821  pipe->uds_input->type == VSP1_ENTITY_BRS) {
   822  uds->scale_alpha = false;
   823  } else {
   824  struct vsp1_rwpf *rpf =
   825  to_rwpf(>uds_input->subdev);
   826  
   827  uds->scale_alpha = rpf->fmtinfo->alpha;
   828  }
   829  }
   830  
   831  list_for_each_entry(entity, >entities, list_pipe) {
   832  vsp1_entity_route_setup(entity, pipe, dlb);
   833  vsp1_entity_prepare(entity, pipe, dlb);
   834  }
   835  
   836  return 0;
   837  }
   838  

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


.config.gz
Description: application/gzip

Re: [PATCH/RFC 1/3] dt-bindings: i2c: i2c-gpio: Add support for named gpios

[Rob Herring]

On Mon, Sep 18, 2017 at 2:45 PM, Linus Walleij  wrote:
> On Mon, Sep 18, 2017 at 6:52 PM, Rob Herring  wrote:
>
>> In theory yes, but reality is pretty much everyone follows it. There's
>> no other way to specify active high vs. low for example. Furthermore,
>> if someone wanted to do flags in their own custom way, that would
>> still work. It is still the controller (or GPIO core) that interprets
>> the flags, not the client.
>>
>> This is a new binding, so only new DT will have it and we can apply
>> new standards.
>
> I'd like to get a picture of any one-cell GPIO DTS:es and/or drivers
> still around.

$ git grep '#gpio-cells.*1'
Documentation/devicetree/bindings/gpio/gpio.txt:
#gpio-cells = <1>;
Documentation/devicetree/bindings/gpio/spear_spics.txt:  *
#gpio-cells: should be 1 and will mention chip select number
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt:
 #gpio-cells = <1>;
Documentation/devicetree/bindings/mfd/twl6040.txt:- #gpio-cells = <1>:
twl6040 provides GPO lines.
arch/mips/boot/dts/xilfpga/nexys4ddr.dts:   #gpio-cells = <1>;

...and this one may be out of date. All other instances for Xilinx
gpio use 2 cells.

We also have to look for custom translate functions of which there are
a handful, but they all use standard flags.

>
> I would like to deal with them somehow.

Looks like we already warn in the kernel if <2. Might be worth adding
this to dtc, then I can get the warning without booting a kernel on
platforms I don't have.

> When we started the big DT migration this was one of the areas
> we made some screwups in, admittedly, but someone just has to
> go first, and that was incidentally GPIO controllers.

The move to standardize flags started before the Great ARM Conversion,
so I would have expected some old PPC DTs. But it looks like we are
good.

Rob

Re: [PATCH v2 02/18] dt: arm: shmobile: add H3ULCB Kingfisher board DT bindings

[Rob Herring]

On Thu, Sep 14, 2017 at 05:18:46PM +0300, Vladimir Barinov wrote:
> Add H3ULCB Kingfisher Device tree bindings Documentation, listing it as a
> supported board.
> 
> Signed-off-by: Vladimir Barinov 
> ---
> Changes in version 2:
> - added own compatible value "shimafuji,kingfisher"
> 
>  Documentation/devicetree/bindings/arm/shmobile.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH] dt: Add vendor prefix 'shimafuji'

[Rob Herring]

On Thu, Sep 14, 2017 at 05:18:30PM +0300, Vladimir Barinov wrote:
> Add Shimafuji Electric, Inc. to the list of device tree vendor
> prefixes
> 
> Signed-off-by: Vladimir Barinov 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

Rob

[PATCH] serial: sh-sci: Support for variable HSCIF hardware RX timeout

[Ulrich Hecht]

HSCIF has facilities that allow changing the timeout after which an RX
interrupt is triggered even if the FIFO is not filled. This patch allows
changing the default (15 bits of silence) using the existing sysfs
attribute "rx_fifo_timeout".

Signed-off-by: Ulrich Hecht 
---
 drivers/tty/serial/sh-sci.c | 51 -
 drivers/tty/serial/sh-sci.h |  3 +++
 2 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 784dd42..99eac92 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -152,6 +152,7 @@ struct sci_port {
int rx_trigger;
struct timer_list   rx_fifo_timer;
int rx_fifo_timeout;
+   u16 hscif_tot;
 
bool has_rtscts;
bool autorts;
@@ -1107,8 +1108,14 @@ static ssize_t rx_fifo_timeout_show(struct device *dev,
 {
struct uart_port *port = dev_get_drvdata(dev);
struct sci_port *sci = to_sci_port(port);
+   u16 v;
 
-   return sprintf(buf, "%d\n", sci->rx_fifo_timeout);
+   if (port->type == PORT_HSCIF)
+   v = sci->hscif_tot >> HSSCR_TOT_SHIFT;
+   else
+   v = sci->rx_fifo_timeout;
+
+   return sprintf(buf, "%d\n", v);
 }
 
 static ssize_t rx_fifo_timeout_store(struct device *dev,
@@ -1124,11 +1131,19 @@ static ssize_t rx_fifo_timeout_store(struct device *dev,
ret = kstrtol(buf, 0, );
if (ret)
return ret;
-   sci->rx_fifo_timeout = r;
-   scif_set_rtrg(port, 1);
-   if (r > 0)
-   setup_timer(>rx_fifo_timer, rx_fifo_timer_fn,
-   (unsigned long)sci);
+
+   if (port->type == PORT_HSCIF) {
+   if (r < 0 || r > 3)
+   return -EINVAL;
+   sci->hscif_tot = r << HSSCR_TOT_SHIFT;
+   } else {
+   sci->rx_fifo_timeout = r;
+   scif_set_rtrg(port, 1);
+   if (r > 0)
+   setup_timer(>rx_fifo_timer, rx_fifo_timer_fn,
+   (unsigned long)sci);
+   }
+
return count;
 }
 
@@ -2037,9 +2052,13 @@ static void sci_shutdown(struct uart_port *port)
spin_lock_irqsave(>lock, flags);
sci_stop_rx(port);
sci_stop_tx(port);
-   /* Stop RX and TX, disable related interrupts, keep clock source */
+   /*
+* Stop RX and TX, disable related interrupts, keep clock source
+* and HSCIF TOT bits
+*/
scr = serial_port_in(port, SCSCR);
-   serial_port_out(port, SCSCR, scr & (SCSCR_CKE1 | SCSCR_CKE0));
+   serial_port_out(port, SCSCR, scr &
+   (SCSCR_CKE1 | SCSCR_CKE0 | s->hscif_tot));
spin_unlock_irqrestore(>lock, flags);
 
 #ifdef CONFIG_SERIAL_SH_SCI_DMA
@@ -2186,7 +2205,7 @@ static void sci_reset(struct uart_port *port)
unsigned int status;
struct sci_port *s = to_sci_port(port);
 
-   serial_port_out(port, SCSCR, 0x00); /* TE=0, RE=0, CKE1=0 */
+   serial_port_out(port, SCSCR, s->hscif_tot); /* TE=0, RE=0, CKE1=0 */
 
reg = sci_getreg(port, SCFCR);
if (reg->size)
@@ -2356,7 +2375,7 @@ static void sci_set_termios(struct uart_port *port, 
struct ktermios *termios,
dev_dbg(port->dev,
 "SCR 0x%x SMR 0x%x BRR %u CKS 0x%x DL %u SRR %u\n",
 scr_val, smr_val, brr, sccks, dl, srr);
-   serial_port_out(port, SCSCR, scr_val);
+   serial_port_out(port, SCSCR, scr_val | s->hscif_tot);
serial_port_out(port, SCSMR, smr_val);
serial_port_out(port, SCBRR, brr);
if (sci_getreg(port, HSSRR)->size)
@@ -2370,7 +2389,7 @@ static void sci_set_termios(struct uart_port *port, 
struct ktermios *termios,
smr_val |= serial_port_in(port, SCSMR) &
   (SCSMR_CKEDG | SCSMR_SRC_MASK | SCSMR_CKS);
dev_dbg(port->dev, "SCR 0x%x SMR 0x%x\n", scr_val, smr_val);
-   serial_port_out(port, SCSCR, scr_val);
+   serial_port_out(port, SCSCR, scr_val | s->hscif_tot);
serial_port_out(port, SCSMR, smr_val);
}
 
@@ -2407,7 +2426,7 @@ static void sci_set_termios(struct uart_port *port, 
struct ktermios *termios,
scr_val |= SCSCR_RE | SCSCR_TE |
   (s->cfg->scscr & ~(SCSCR_CKE1 | SCSCR_CKE0));
dev_dbg(port->dev, "SCSCR 0x%x\n", scr_val);
-   serial_port_out(port, SCSCR, scr_val);
+   serial_port_out(port, SCSCR, scr_val | s->hscif_tot);
if ((srr + 1 == 5) &&
(port->type == PORT_SCIFA || port->type == PORT_SCIFB)) {
/*
@@ -2860,7 +2879,7 @@ static void serial_console_write(struct console *co, 
const char *s,
ctrl_temp = SCSCR_RE | 

Re: [PATCHv2 0/2] drm/bridge/adv7511: add CEC support

[Geert Uytterhoeven]

Hi Hans,

On Tue, Sep 19, 2017 at 9:33 AM, Hans Verkuil  wrote:
> From: Hans Verkuil 
>
> I should have posted this a month ago, but I completely forgot about
> it. Apologies for that.
>
> This patch series adds CEC support to the drm adv7511/adv7533 drivers.
>
> I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
> and the Renesas R-Car Koelsch board (adv7511 based).
>
> I only have the Koelsch board to test with, but it looks like other
> R-Car boards use the same adv7511. It would be nice if someone can
> add CEC support to the other R-Car boards as well. The main thing
> to check is if they all use the same 12 MHz fixed CEC clock source.

Have a 12 MHz fixed CEC clock source connected to the CEC_CLK pin
on ADV7511:
  - r8a7790/lager
  - r8a7791/koelsch
  - r8a7791/porter
  - r8a7792/blanche
  - r8a7793/gose
  - r8a7794/alt
  - r8a7794/silk

I don't know about r8a7792/wheat. But according to its .dts file, it has two
instances of the ADV7513, not ADV7511.

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 5/8] ARM: dts: r8a7743: Add QSPI support

[Geert Uytterhoeven]

On Wed, Sep 13, 2017 at 7:05 PM, Chris Paterson
 wrote:
> From: Fabrizio Castro 
>
> Add the DT node for the QSPI interface to the SoC dtsi.
>
> Signed-off-by: Fabrizio Castro 
> Signed-off-by: Chris Paterson 

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 7/8] ARM: dts: r8a7745: Add QSPI support

[Geert Uytterhoeven]

On Wed, Sep 13, 2017 at 7:05 PM, Chris Paterson
 wrote:
> From: Fabrizio Castro 
>
> Add the DT node for the QSPI interface to the SoC dtsi.
>
> Signed-off-by: Fabrizio Castro 
> Signed-off-by: Chris Paterson 

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 1/8] ARM: dts: r8a7745: Add APMU node and second CPU core

[Geert Uytterhoeven]

On Wed, Sep 13, 2017 at 7:05 PM, Chris Paterson
 wrote:
> From: Fabrizio Castro 
>
> Add DT node for the Advanced Power Management Unit (APMU), add the
> second CPU core, and use "renesas,apmu" as "enable-method".
>
> Signed-off-by: Fabrizio Castro 
> Signed-off-by: Chris Paterson 

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 ] phy: rcar-gen2: Add r8a7743/5 support

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 11:59 AM, Biju Das  wrote:
> Add USB PHY support for r8a7743/5 SoC. Renesas RZ/G1[ME] (R8A7743/5)
> USB PHY is identical to the R-Car Gen2 family.
>
> Signed-off-by: Biju Das 

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 3/4] arm64: dts: renesas: r8a77995: draak: enable USB2.0 PHY

[Geert Uytterhoeven]

On Thu, Sep 14, 2017 at 12:30 PM, Yoshihiro Shimoda
 wrote:
> This patch enables USB2.0 PHY for R-Car D3 draak board.
>
> Signed-off-by: Yoshihiro Shimoda 

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 2/4] arm64: dts: renesas: r8a77995: add USB2.0 Host (EHCI/OHCI) device node

[Geert Uytterhoeven]

On Thu, Sep 14, 2017 at 12:30 PM, Yoshihiro Shimoda
 wrote:
> This patch adds USB2.0 Host (EHCI/OHCI) device node for r8a77995.
>
> Signed-off-by: Yoshihiro Shimoda 

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 1/4] arm64: dts: renesas: r8a77995: Add USB2.0 PHY device node

[Geert Uytterhoeven]

On Thu, Sep 14, 2017 at 12:30 PM, Yoshihiro Shimoda
 wrote:
> This patch adds USB2.0 PHY device node for r8a77995.
>
> Signed-off-by: Yoshihiro Shimoda 

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] pinctrl: sh-pfc: r8a77995: Add USB2.0 host support

[Geert Uytterhoeven]

On Thu, Sep 14, 2017 at 12:29 PM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.15...

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] gpio: rcar: Add r8a77995 (R-Car D3) support

[Rob Herring]

On Wed, Sep 13, 2017 at 03:48:49PM +0900, Yoshihiro Shimoda wrote:
> This patch adds binding for r8a77995 (R-Car D3). This SoC can use
> "renesas,rcar-gen3-gpio" fallback compatibility. So, this patch
> doesn't modify the gpio-rcar driver.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v2] pinctrl: sh-pfc: r8a77995: Add EthernetAVB pins, groups and functions

[Geert Uytterhoeven]

Hi Shimoda-san,

On Thu, Sep 14, 2017 at 1:52 AM, Yoshihiro Shimoda
 wrote:
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  About AVB'0', I don't get any feedback from HW team... So, I'd like to follow
>  the current PFC section in the manual.
>
>  Changes from v1:
>   - Changes the groups like other SoCs (r8a7795 and r8a7796).

Thanks for the update!

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in sh-pfc-for-v4.15...

> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
> @@ -936,6 +936,99 @@ enum {

> +static const unsigned int avb0_mdc_pins[] = {
> +   /* AVB0_MDC, AVB_MDIO */

... with s/AVB_MDIO/AVB0_MDIO/.

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

Applied "spi: rspi: Add r8a7743/5 to the compatible list" to the spi tree

[Mark Brown]

The patch

   spi: rspi: Add r8a7743/5 to the compatible list

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.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 10c1705eced11d6ad710fddcdb57aaa9f85a6f98 Mon Sep 17 00:00:00 2001
From: Fabrizio Castro 
Date: Fri, 8 Sep 2017 09:07:15 +0100
Subject: [PATCH] spi: rspi: Add r8a7743/5 to the compatible list

Signed-off-by: Fabrizio Castro 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Rob Herring 
Signed-off-by: Mark Brown 
---
 Documentation/devicetree/bindings/spi/spi-rspi.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt 
b/Documentation/devicetree/bindings/spi/spi-rspi.txt
index 8f4169f63936..3b02b3a7cfb2 100644
--- a/Documentation/devicetree/bindings/spi/spi-rspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt
@@ -5,11 +5,14 @@ Required properties:
 "renesas,rspi-", "renesas,rspi" as fallback.
 For Renesas Serial Peripheral Interface on RZ/A1H:
 "renesas,rspi-", "renesas,rspi-rz" as fallback.
-For Quad Serial Peripheral Interface on R-Car Gen2:
+For Quad Serial Peripheral Interface on R-Car Gen2 and
+RZ/G1 devices:
 "renesas,qspi-", "renesas,qspi" as fallback.
 Examples with soctypes are:
- "renesas,rspi-sh7757" (SH)
- "renesas,rspi-r7s72100" (RZ/A1H)
+   - "renesas,qspi-r8a7743" (RZ/G1M)
+   - "renesas,qspi-r8a7745" (RZ/G1E)
- "renesas,qspi-r8a7790" (R-Car H2)
- "renesas,qspi-r8a7791" (R-Car M2-W)
- "renesas,qspi-r8a7792" (R-Car V2H)
-- 
2.14.1

renesas-drivers-2017-09-19-v4.14-rc1

[Geert Uytterhoeven]

I have pushed renesas-drivers-2017-09-19-v4.14-rc1 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.

Today's version is based on renesas-devel-20170918-v4.14-rc1.

Included branches with driver code:
  - clk-renesas
  - sh-pfc
  - topic/suspend-to-idle-v1-rebased1
  - topic/sh-sh7722-sh7757-sh7264-sh7269-fix-pinctrl-v2
  - topic/r8a77995-integration
  - topic/r8a77970-integration
  - topic/r8a7794-smp-v3
  - topic/cmt-binding-rework-driver-v3
  - topic/cmt-binding-rework-dt-v3
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/rcar-gen3-z-clk
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/cpufreq-automatic
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/rcar-gen3-cpufreq-dts
  - git://git.ragnatech.se/linux#for-renesas-drivers
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#renesas/topic/i2c-fault-injection
  - topic/vsp1/tlb-optimise-v2-rebased1
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/vsp-du/du-suspend-resume/v1

Included fixes:
  - rcar-vin: Fix section mismatch from rcar_vin_probe()
  - media: rcar-csi2: Fix section mismatch from rcar_csi2_probe()
  - of_mdio: Fix broken PHY IRQ in case of probe deferral
  - mtd: spi-nor: fix DMA unsafe buffer issue in spi_nor_read_sfdp()
  - mtd: spi-nor: Check consistency of the memory size extracted from the SFDP
  - [LOCAL] arm64: defconfig: Add renesas_defconfig

Included subsystem trees:
  - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
  - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
  - git://people.freedesktop.org/~airlied/linux#drm-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
  - git://linuxtv.org/mchehab/media-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
  - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
  - git://git.infradead.org/users/vkoul/slave-dma.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
  - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
  - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
  - git://github.com/bzolnier/linux.git#fbdev-for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
  - git://www.linux-watchdog.org/linux-watchdog-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
  - git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next

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: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 09/19/2017 01:59 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
  Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
  1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
  - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
generator. The chip will rely on the sync signals in the DSI data lanes,
rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


It's called "phandle" in the DT speak. :-)
Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


   No, you only say that there'll be the clock phandle only. The clock
specifier may follow the phandle for the clock devices that have
"#clock-cells" prop != 0.


I have to say that I just copy-and-pasted this from other bindings.


  :-)


Would this be better?

- clocks: list of clock specifiers, corresponding to entries in
 the clock-names property;


  Didn't you say that there'll be only one clock, "cec"? If so, there's
gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)


- clock-names: from common clock binding: must be "cec".


- clocks: cec clock phandle, corresponding to the clock-names entry.


 The clock phandle and specifier.


- clock-names: from common clock binding: must be "cec".

This OK?


 Well, you seem to be going in circles, the above was almost the same as
the original prop description...


- clocks: from common clock binding: reference to the CEC clock.
- clock-names: from common clock binding: must be "cec".

This avoids the whole issue of having just a phandle or a phandle + specifier.


   OK, let's go with this one. Thank you!


Regards,

Hans


MBR, Sergei

Re: [PATCH v3 00/12] ARM: dts: renesas: Update DTS for CMT DT binding rework

[Simon Horman]

On Mon, Sep 18, 2017 at 03:48:23PM +0200, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> This patch series updates the CMT device nodes in the various Renesas DTS
> files sh_cmt clocksource driver for the recent DT binding rework that was
> merged in v4.14-rc1.
> 
> This series is an evolutionary improvement of Magnus Damm's series "[PATCH
> v2 00/11] clocksource: sh_cmt: DT binding rework V2".
> It complements Magnus' series "[PATCH v3 00/06] clocksource: sh_cmt: DT 
> binding rework V3" and "[PATCH v4 00/06] clocksource: sh_cmt: DT binding 
> rework V4", which included DT binding updates only.
> 
>   - Patches 1-5 update the compatible values for the CMT0 and CMT1 device
> nodes on R-Mobile APE6 and R-Car Gen2,
>   - Patches 6-12 remove the now obsolete "renesas,channels-mask" properties
> from the CMT device nodes on all affected SoCs.
> 
> Changes compared to v2:
>   - Take over from Magnus,
>   - Update compatible values,
>   - Split in per-SoC patches,
> 
> Dependencies:
>   - This patch series has a runtime dependency on "[PATCH v3 0/7]
> clocksource: sh_cmt: Update driver for DT binding rework", and thus
> must not be applied yet,
>   - Patches were created against renesas-devel-20170918-v4.14-rc1.

Thanks, I have marked these as deferred pending acceptance of that
dependency. Please ping me once that is in place. I guess that will be
v4.16 timing.

Re: [PATCH] arm64: defconfig: enable thermal driver for Renesas R-Car Gen3

[Simon Horman]

On Mon, Sep 18, 2017 at 08:31:13PM +0200, Wolfram Sang wrote:
> We want this driver to detect critical temperatures in time.
> 
> Signed-off-by: Wolfram Sang 

Thanks, applied.

Re: [PATCH] arm64: dts: draak: Add serial console pins

[Simon Horman]

On Tue, Sep 19, 2017 at 11:13:25AM +0200, Geert Uytterhoeven wrote:
> On Wed, Aug 30, 2017 at 8:44 AM, Simon Horman  wrote:
> > On Mon, Aug 28, 2017 at 11:26:10AM +0200, Geert Uytterhoeven wrote:
> >> Add pin control for SCIF2.
> >>
> >> Signed-off-by: Geert Uytterhoeven 
> >> ---
> >> To be applied after v4.14-rc1, when commit 794a6711764658a1 ("pinctrl:
> >> sh-pfc: Initial R8A77995 PFC support") has hit mainline.
> >>
> >> Else the serial console will fail, reporting (on earlycon):
> >>
> >> sh-sci e6e88000.serial: could not find pctldev for node 
> >> /soc/pin-controller@e606/scif2, deferring probe
> >
> > Thanks, please ping me once that has happened.
> > In the meantime I have marked this patch as deferred.
> 
> Ping...

Thanks, applied.

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Hans Verkuil]

On 09/19/17 12:42, Sergei Shtylyov wrote:
> On 9/19/2017 1:35 PM, Hans Verkuil wrote:
> 
 From: Hans Verkuil 

 Document the cec clock binding.

 Signed-off-by: Hans Verkuil 
 Acked-by: Rob Herring 
 ---
  Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
 | 4 
  1 file changed, 4 insertions(+)

 diff --git 
 a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
 b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 index 06668bca7ffc..4497ae054d49 100644
 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 @@ -68,6 +68,8 @@ Optional properties:
  - adi,disable-timing-generator: Only for ADV7533. Disables the 
 internal timing
generator. The chip will rely on the sync signals in the DSI 
 data lanes,
rather than generate its own timings for HDMI output.
 +- clocks: from common clock binding: handle to CEC clock.
>>>
>>>It's called "phandle" in the DT speak. :-)
>>>Are you sure the clock specifier would always be absent?
>>
>> Sorry? I don't understand the question. Did you mean: "can be absent?"?
>
>   No, you only say that there'll be the clock phandle only. The clock
> specifier may follow the phandle for the clock devices that have
> "#clock-cells" prop != 0.

 I have to say that I just copy-and-pasted this from other bindings.
>>>
>>>  :-)
>>>
 Would this be better?

 - clocks: list of clock specifiers, corresponding to entries in
 the clock-names property;
>>>
>>>  Didn't you say that there'll be only one clock, "cec"? If so, there's
>>> gonna  be a single clock phandle+specifier pair. They always go in pairs. 
>>> :-)
>>>
 - clock-names: from common clock binding: must be "cec".
>>
>> - clocks: cec clock phandle, corresponding to the clock-names entry.
> 
> The clock phandle and specifier.
> 
>> - clock-names: from common clock binding: must be "cec".
>>
>> This OK?
> 
> Well, you seem to be going in circles, the above was almost the same as 
> the original prop description...

- clocks: from common clock binding: reference to the CEC clock.
- clock-names: from common clock binding: must be "cec".

This avoids the whole issue of having just a phandle or a phandle + specifier.

Regards,

Hans

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 9/19/2017 1:35 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
 - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
   generator. The chip will rely on the sync signals in the DSI data lanes,
   rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


   It's called "phandle" in the DT speak. :-)
   Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


  No, you only say that there'll be the clock phandle only. The clock
specifier may follow the phandle for the clock devices that have
"#clock-cells" prop != 0.


I have to say that I just copy-and-pasted this from other bindings.


 :-)


Would this be better?

- clocks: list of clock specifiers, corresponding to entries in
the clock-names property;


 Didn't you say that there'll be only one clock, "cec"? If so, there's
gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)


- clock-names: from common clock binding: must be "cec".


- clocks: cec clock phandle, corresponding to the clock-names entry.


   The clock phandle and specifier.


- clock-names: from common clock binding: must be "cec".

This OK?


   Well, you seem to be going in circles, the above was almost the same as 
the original prop description...



Regards,

Hans


MBR, Sergei

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Hans Verkuil]

On 09/19/17 12:15, Sergei Shtylyov wrote:
> On 9/19/2017 1:07 PM, Hans Verkuil wrote:
> 
>> From: Hans Verkuil 
>>
>> Document the cec clock binding.
>>
>> Signed-off-by: Hans Verkuil 
>> Acked-by: Rob Herring 
>> ---
>> Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
>> 
>> 1 file changed, 4 insertions(+)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> index 06668bca7ffc..4497ae054d49 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> @@ -68,6 +68,8 @@ Optional properties:
>> - adi,disable-timing-generator: Only for ADV7533. Disables the 
>> internal timing
>>   generator. The chip will rely on the sync signals in the DSI data 
>> lanes,
>>   rather than generate its own timings for HDMI output.
>> +- clocks: from common clock binding: handle to CEC clock.
>
>   It's called "phandle" in the DT speak. :-)
>   Are you sure the clock specifier would always be absent?

 Sorry? I don't understand the question. Did you mean: "can be absent?"?
>>>
>>>  No, you only say that there'll be the clock phandle only. The clock
>>> specifier may follow the phandle for the clock devices that have
>>> "#clock-cells" prop != 0.
>>
>> I have to say that I just copy-and-pasted this from other bindings.
> 
> :-)
> 
>> Would this be better?
>>
>> - clocks: list of clock specifiers, corresponding to entries in
>>the clock-names property;
> 
> Didn't you say that there'll be only one clock, "cec"? If so, there's 
> gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)
> 
>> - clock-names: from common clock binding: must be "cec".

- clocks: cec clock phandle, corresponding to the clock-names entry.
- clock-names: from common clock binding: must be "cec".

This OK?

Regards,

Hans

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 9/19/2017 1:07 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
- adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
  generator. The chip will rely on the sync signals in the DSI data lanes,
  rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


  It's called "phandle" in the DT speak. :-)
  Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


 No, you only say that there'll be the clock phandle only. The clock
specifier may follow the phandle for the clock devices that have
"#clock-cells" prop != 0.


I have to say that I just copy-and-pasted this from other bindings.


   :-)


Would this be better?

- clocks: list of clock specifiers, corresponding to entries in
   the clock-names property;


   Didn't you say that there'll be only one clock, "cec"? If so, there's 
gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)



- clock-names: from common clock binding: must be "cec".

Regards,

Hans


MBR, Sergei

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Hans Verkuil]

On 09/19/17 11:35, Sergei Shtylyov wrote:
> On 9/19/2017 12:29 PM, Hans Verkuil wrote:
> 
 From: Hans Verkuil 

 Document the cec clock binding.

 Signed-off-by: Hans Verkuil 
 Acked-by: Rob Herring 
 ---
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
 
1 file changed, 4 insertions(+)

 diff --git 
 a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
 b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 index 06668bca7ffc..4497ae054d49 100644
 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 @@ -68,6 +68,8 @@ Optional properties:
- adi,disable-timing-generator: Only for ADV7533. Disables the internal 
 timing
  generator. The chip will rely on the sync signals in the DSI data 
 lanes,
  rather than generate its own timings for HDMI output.
 +- clocks: from common clock binding: handle to CEC clock.
>>>
>>>  It's called "phandle" in the DT speak. :-)
>>>  Are you sure the clock specifier would always be absent?
>>
>> Sorry? I don't understand the question. Did you mean: "can be absent?"?
> 
> No, you only say that there'll be the clock phandle only. The clock 
> specifier may follow the phandle for the clock devices that have 
> "#clock-cells" prop != 0.

I have to say that I just copy-and-pasted this from other bindings. Would
this be better?

- clocks: list of clock specifiers, corresponding to entries in
  the clock-names property;
- clock-names: from common clock binding: must be "cec".

Regards,

Hans

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Hans Verkuil]

On 09/19/17 11:20, Sergei Shtylyov wrote:
> Hello!
> 
> On 9/19/2017 10:33 AM, Hans Verkuil wrote:
> 
>> From: Hans Verkuil 
>>
>> Document the cec clock binding.
>>
>> Signed-off-by: Hans Verkuil 
>> Acked-by: Rob Herring 
>> ---
>>   Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> index 06668bca7ffc..4497ae054d49 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> @@ -68,6 +68,8 @@ Optional properties:
>>   - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
>> timing
>> generator. The chip will rely on the sync signals in the DSI data lanes,
>> rather than generate its own timings for HDMI output.
>> +- clocks: from common clock binding: handle to CEC clock.
> 
> It's called "phandle" in the DT speak. :-)
> Are you sure the clock specifier would always be absent?

Sorry? I don't understand the question. Did you mean: "can be absent?"?

Regards,

Hans

> 
>> +- clock-names: from common clock binding: must be "cec".
>>   
>>   Required nodes:
>>   
> [...]
> 
> MBR, Sergei
> 

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 9/19/2017 12:29 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
   Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
   1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
   - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
 generator. The chip will rely on the sync signals in the DSI data lanes,
 rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


 It's called "phandle" in the DT speak. :-)
 Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


   No, you only say that there'll be the clock phandle only. The clock 
specifier may follow the phandle for the clock devices that have 
"#clock-cells" prop != 0.



Regards,

 Hans

[...]

MBR, Sergei

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

Hello!

On 9/19/2017 10:33 AM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
  Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
  1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
  - adi,disable-timing-generator: Only for ADV7533. Disables the internal timing
generator. The chip will rely on the sync signals in the DSI data lanes,
rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


   It's called "phandle" in the DT speak. :-)
   Are you sure the clock specifier would always be absent?


+- clock-names: from common clock binding: must be "cec".
  
  Required nodes:
  

[...]

MBR, Sergei

Re: [PATCH] arm64: dts: draak: Add serial console pins

[Geert Uytterhoeven]

On Wed, Aug 30, 2017 at 8:44 AM, Simon Horman  wrote:
> On Mon, Aug 28, 2017 at 11:26:10AM +0200, Geert Uytterhoeven wrote:
>> Add pin control for SCIF2.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>> To be applied after v4.14-rc1, when commit 794a6711764658a1 ("pinctrl:
>> sh-pfc: Initial R8A77995 PFC support") has hit mainline.
>>
>> Else the serial console will fail, reporting (on earlycon):
>>
>> sh-sci e6e88000.serial: could not find pctldev for node 
>> /soc/pin-controller@e606/scif2, deferring probe
>
> Thanks, please ping me once that has happened.
> In the meantime I have marked this patch as deferred.

Ping...

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] arm64: dts: salvator-common: add 12V regulator to backlight

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Monday, 18 September 2017 18:56:14 EEST Ulrich Hecht wrote:
> This fixes the warning "pwm-backlight backlight: backlight supply power
> not found, using dummy regulator".
> 
> Fixes: b33be33670217533 ("arm64: dts: salvator-x: Add panel backlight
> support")
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm64/boot/dts/renesas/salvator-common.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> b/arch/arm64/boot/dts/renesas/salvator-common.dtsi index e3d8310..fa2a1f7
> 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -63,6 +63,7 @@
>   brightness-levels = <256 128 64 16 8 4 0>;
>   default-brightness-level = <6>;
> 
> + power-supply = <_12v>;
>   enable-gpios = < 7 GPIO_ACTIVE_HIGH>;
>   };
> 
> @@ -107,6 +108,15 @@
>   regulator-always-on;
>   };
> 
> + reg_12v: regulator2 {

Nitpicking, should be call this reg_12p0v to match the naming scheme of the 
other fixed regulators ?

Apart from that, and regardless of whether you want to change the name or not,

Reviewed-by: Laurent Pinchart 

> + compatible = "regulator-fixed";
> + regulator-name = "fixed-12V";
> + regulator-min-microvolt = <1200>;
> + regulator-max-microvolt = <1200>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
>   rsnd_ak4613: sound {
>   compatible = "simple-audio-card";


-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 resend 0/4] sh: sh7722/sh7757i/sh7264/sh7269: Fix pinctrl registration

[Geert Uytterhoeven]

Hi Linus,

On Tue, Sep 19, 2017 at 10:19 AM, Linus Walleij
 wrote:
> On Tue, Sep 12, 2017 at 10:40 AM, Geert Uytterhoeven
>  wrote:
>> I'm resending this to you due to unresponsiveness from the SuperH
>> maintainers (v2 sent before on May 11, pinged on June 30 and August 14).
>
> I'm happy to take this into the pinctrl tree if need be.
>
> It is pinctrl related so it makes sense to carry it there if SH
> maintainers are not responding.
>
> Just send a separate pull request and indicate if it needs to
> go in for fixes or devel.

In the mean time, Andrew took it (thanks!), so it's now in linux-next.

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 resend 0/4] sh: sh7722/sh7757i/sh7264/sh7269: Fix pinctrl registration

[Linus Walleij]

On Tue, Sep 12, 2017 at 10:40 AM, Geert Uytterhoeven
 wrote:

> Hi Andrew,
>
> I'm resending this to you due to unresponsiveness from the SuperH
> maintainers (v2 sent before on May 11, pinged on June 30 and August 14).

I'm happy to take this into the pinctrl tree if need be.

It is pinctrl related so it makes sense to carry it there if SH
maintainers are not responding.

Just send a separate pull request and indicate if it needs to
go in for fixes or devel.

Yours,
Linus Walleij

Re: [PATCH v2 6/8] arm64: renesas: document Eagle board bindings

[Geert Uytterhoeven]

On Fri, Sep 15, 2017 at 9:43 PM, Sergei Shtylyov
 wrote:
> Document the Eagle device tree bindings, listing it as a supported board.
>
> This allows to use checkpatch.pl to validate .dts files referring to the
> Eagle board.
>
> 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

[PATCHv2 2/2] drm: adv7511/33: add HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

Add support for HDMI CEC to the drm adv7511/adv7533 drivers.

The CEC registers that we need to use are identical for both drivers,
but they appear at different offsets in the register map.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/bridge/adv7511/Kconfig   |   8 +
 drivers/gpu/drm/bridge/adv7511/Makefile  |   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511.h |  43 +++-
 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 337 +++
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 116 +++--
 drivers/gpu/drm/bridge/adv7511/adv7533.c |  38 +--
 6 files changed, 485 insertions(+), 58 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index 2fed567f9943..592b9d2ec034 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -21,3 +21,11 @@ config DRM_I2C_ADV7533
default y
help
  Support for the Analog Devices ADV7533 DSI to HDMI encoder.
+
+config DRM_I2C_ADV7511_CEC
+   bool "ADV7511/33 HDMI CEC driver"
+   depends on DRM_I2C_ADV7511
+   select CEC_CORE
+   default y
+   help
+ When selected the HDMI transmitter will support the CEC feature.
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 5ba675534f6e..5bb384938a71 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,4 +1,5 @@
 adv7511-y := adv7511_drv.o
 adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
 adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index fe18a5d2d84b..543a5eb91624 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -195,6 +195,25 @@
 #define ADV7511_PACKET_GM(x)   ADV7511_PACKET(5, x)
 #define ADV7511_PACKET_SPARE(x)ADV7511_PACKET(6, x)
 
+#define ADV7511_REG_CEC_TX_FRAME_HDR   0x00
+#define ADV7511_REG_CEC_TX_FRAME_DATA0 0x01
+#define ADV7511_REG_CEC_TX_FRAME_LEN   0x10
+#define ADV7511_REG_CEC_TX_ENABLE  0x11
+#define ADV7511_REG_CEC_TX_RETRY   0x12
+#define ADV7511_REG_CEC_TX_LOW_DRV_CNT 0x14
+#define ADV7511_REG_CEC_RX_FRAME_HDR   0x15
+#define ADV7511_REG_CEC_RX_FRAME_DATA0 0x16
+#define ADV7511_REG_CEC_RX_FRAME_LEN   0x25
+#define ADV7511_REG_CEC_RX_ENABLE  0x26
+#define ADV7511_REG_CEC_RX_BUFFERS 0x4a
+#define ADV7511_REG_CEC_LOG_ADDR_MASK  0x4b
+#define ADV7511_REG_CEC_LOG_ADDR_0_1   0x4c
+#define ADV7511_REG_CEC_LOG_ADDR_2 0x4d
+#define ADV7511_REG_CEC_CLK_DIV0x4e
+#define ADV7511_REG_CEC_SOFT_RESET 0x50
+
+#define ADV7533_REG_CEC_OFFSET 0x70
+
 enum adv7511_input_clock {
ADV7511_INPUT_CLOCK_1X,
ADV7511_INPUT_CLOCK_2X,
@@ -297,6 +316,8 @@ enum adv7511_type {
ADV7533,
 };
 
+#define ADV7511_MAX_ADDRS 3
+
 struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
@@ -343,15 +364,27 @@ struct adv7511 {
 
enum adv7511_type type;
struct platform_device *audio_pdev;
+
+   struct cec_adapter *cec_adap;
+   u8   cec_addr[ADV7511_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+   struct clk *cec_clk;
+   u32 cec_clk_freq;
 };
 
+#ifdef CONFIG_DRM_I2C_ADV7511_CEC
+int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
+unsigned int offset);
+void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
+#endif
+
 #ifdef CONFIG_DRM_I2C_ADV7533
 void adv7533_dsi_power_on(struct adv7511 *adv);
 void adv7533_dsi_power_off(struct adv7511 *adv);
 void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode *mode);
 int adv7533_patch_registers(struct adv7511 *adv);
-void adv7533_uninit_cec(struct adv7511 *adv);
-int adv7533_init_cec(struct adv7511 *adv);
+int adv7533_patch_cec_registers(struct adv7511 *adv);
 int adv7533_attach_dsi(struct adv7511 *adv);
 void adv7533_detach_dsi(struct adv7511 *adv);
 int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
@@ -374,11 +407,7 @@ static inline int adv7533_patch_registers(struct adv7511 
*adv)
return -ENODEV;
 }
 
-static inline void adv7533_uninit_cec(struct adv7511 *adv)
-{
-}
-
-static inline int adv7533_init_cec(struct adv7511 *adv)
+static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
 {
return -ENODEV;
 }
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
new file mode 100644
index ..b33d730e4d73
--- /dev/null
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
@@ -0,0 +1,337 @@
+/*
+ * 

[PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Hans Verkuil]

From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
 - adi,disable-timing-generator: Only for ADV7533. Disables the internal timing
   generator. The chip will rely on the sync signals in the DSI data lanes,
   rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.
+- clock-names: from common clock binding: must be "cec".
 
 Required nodes:
 
@@ -89,6 +91,8 @@ Example
reg = <39>;
interrupt-parent = <>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+   clocks = <_clock>;
+   clock-names = "cec";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
-- 
2.14.1

Re: Seeing conflict with IPMMU driver under ACPI

[Laurent Pinchart]

Hi Ananth,

On Tuesday, 19 September 2017 09:54:49 EEST Jasty, Ananth wrote:
> On Sep 18, 2017, at 11:49 PM, Laurent Pinchart wrote:
> > On Tuesday, 19 September 2017 03:43:05 EEST Jasty, Ananth wrote:
> >> Hi, with your IPMMU driver enabled under 4.13 we’re seeing a crash on
> >> boot:
> >> 
> >> [ 13.785164] Unable to handle kernel NULL pointer dereference at virtual
> >> address 0018
> >> [ 13.793254] [0018] user address but active_mm is swapper
> >> [ 13.799600] Internal error: Oops: 9604 [#1] SMP
> >> [ 13.804466] Modules linked in: aes_neon_bs aes_neon_blk crypto_simd
> >> cryptd
> >> [ 13.811334] CPU: 152 PID: 1529 Comm: kworker/152:1 Not tainted
> >> 4.13.0-9-generic #10-Ubuntu
> >> [ 13.819584] Hardware name: Default string Cavium ThunderX2/Default
> >> string, BIOS 5.13 07/20/2017
> >> [ 13.828285] Workqueue: events deferred_probe_work_func
> >> [ 13.833410] task: 80bee93d task.stack: 80bee93dc000
> >> [ 13.839330] PC is at iommu_ops_from_fwnode+0x4c/0x90
> >> [ 13.844282] LR is at iommu_ops_from_fwnode+0x28/0x90
> >> 
> >> The ARM SMMUv3 driver (which our platform implements) seems to be losing
> >> iommu_ops to the IPMMU driver.
> > 
> > You seem not to be the first one to notice:
> > 
> > https://patchwork.kernel.org/patch/9956449/
> 
> Wow, he did not beat me by much.
> 
> >> Note: our platform uses ACPI for device enumeration.
> >> 
> >> I have no way to test this, but is there a reason the set_iommu isn’t in
> >> _probe?
> > 
> > I can't recall what the reason was I'm afraid.
> 
> arm-smmu-v3.c does do the set_iommu in probe, and thus far there have been
> no confirmed fatalities, but I can't speak authoritatively.
> 
> I'll leave you all to it then.

After digging a bit I realized that calling bus_set_iommu() from the init 
function is needed to support ARM32 (the same driver supports both ARM32 and 
ARM64). Let's discuss the matter in a reply to https://patchwork.kernel.org/
patch/9956449/.

-- 
Regards,

Laurent Pinchart

Re: Seeing conflict with IPMMU driver under ACPI

[Laurent Pinchart]

Hi Ananth,

On Tuesday, 19 September 2017 03:43:05 EEST Jasty, Ananth wrote:
> Hi, with your IPMMU driver enabled under 4.13 we’re seeing a crash on boot:
> 
> [ 13.785164] Unable to handle kernel NULL pointer dereference at virtual
> address 0018
> [ 13.793254] [0018] user address but active_mm is swapper
> [ 13.799600] Internal error: Oops: 9604 [#1] SMP
> [ 13.804466] Modules linked in: aes_neon_bs aes_neon_blk crypto_simd cryptd
> [ 13.811334] CPU: 152 PID: 1529 Comm: kworker/152:1 Not tainted
> 4.13.0-9-generic #10-Ubuntu
> [ 13.819584] Hardware name: Default string Cavium ThunderX2/Default string,
> BIOS 5.13 07/20/2017
> [ 13.828285] Workqueue: events deferred_probe_work_func
> [ 13.833410] task: 80bee93d task.stack: 80bee93dc000
> [ 13.839330] PC is at iommu_ops_from_fwnode+0x4c/0x90
> [ 13.844282] LR is at iommu_ops_from_fwnode+0x28/0x90
> 
> The ARM SMMUv3 driver (which our platform implements) seems to be losing
> iommu_ops to the IPMMU driver.

You seem not to be the first one to notice:

https://patchwork.kernel.org/patch/9956449/

> Note: our platform uses ACPI for device enumeration.
> 
> I have no way to test this, but is there a reason the set_iommu isn’t in
> _probe?

I can't recall what the reason was I'm afraid.

> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 2a38aa1..d4c72da 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -1066,6 +1066,9 @@ static int ipmmu_probe(struct platform_device *pdev)
> 
> platform_set_drvdata(pdev, mmu);
> 
> +   if (!iommu_present(_bus_type))
> +   bus_set_iommu(_bus_type, _ops);
> +
> return 0;
>  }
> 
> @@ -1108,9 +,6 @@ static int __init ipmmu_init(void)
> if (ret < 0)
> return ret;
> 
> -   if (!iommu_present(_bus_type))
> -   bus_set_iommu(_bus_type, _ops);
> -
> return 0;
>  }
> 
> 
> If I’m wrong, my apologies.

-- 
Regards,

Laurent Pinchart