Re: [PATCH 03/12] power_supply: axp288_charger: Replace the extcon API

2016-12-06 Thread Chanwoo Choi 
Hi Sebastian,

On 2016년 12월 07일 12:05, Sebastian Reichel wrote:
> Hi Chanwoo,
> 
> On Tue, Dec 06, 2016 at 09:26:14AM +0900, Chanwoo Choi wrote:
>> Could you please review and pick the patch3/4 for power-supply driver?
> 
> Patches look fine. As I expect the merge window to open next week I
> would rather not queue this for 4.10 and instead do it once 4.10-rc1
> has been tagged.
> 
> -- Sebastian
> 

Thanks for your pick up.

-- 
Best Regards,
Chanwoo Choi

Re: [PATCH v4 2/4] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver

2016-12-06 Thread Eduardo Valentin 
Hello Wolfram,

On Thu, Dec 01, 2016 at 11:04:40PM +0100, Wolfram Sang wrote:
> Add support for R-Car Gen3 thermal sensors. Polling only for now,
> interrupts will be added incrementally. Same goes for reading fuses.
> This is documented already, but no hardware available for now.
> 
> Signed-off-by: Hien Dang 
> Signed-off-by: Thao Nguyen 
> Signed-off-by: Khiem Nguyen 
> Signed-off-by: Wolfram Sang 
> ---
> 
> Changes since v3:
> 
> * call 'init' callback a tad earlier, avoids need for locking
> * converted spinlock to mutex and simplified locking (only done against
>   concurrent access in rcar_gen3_thermal_get_temp() now)
> * use usleep_range instead of udelay
> * use s64 instead of long (int didn't work)
> * fixed an error path
> * simplified rcar_gen3_thermal_update_temp() and its use
> 

When I try compiling this driver (from this commit only), using
multi_v7_defconfig, I get this error when set as module:
ERROR: "__aeabi_ldivmod" [drivers/thermal/rcar_gen3_thermal.ko]
undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed

And these errors when builtin:
  LD  init/built-in.o
  drivers/built-in.o: In function `rcar_gen3_thermal_get_temp':
  :(.text+0x461778): undefined reference to `__aeabi_ldivmod'
  :(.text+0x461798): undefined reference to `__aeabi_ldivmod'
  drivers/built-in.o: In function `rcar_gen3_thermal_probe':
  :(.text+0x461948): undefined reference to `__aeabi_ldivmod'
  :(.text+0x461998): undefined reference to `__aeabi_ldivmod'
  :(.text+0x4619d0): undefined reference to `__aeabi_ldivmod'
  drivers/built-in.o::(.text+0x4619fc): more undefined references to
  `__aeabi_ldivmod' follow
  Makefile:962: recipe for target 'vmlinux' failed
  make: *** [vmlinux] Error 1

So, definitely would make sense to squash patch 5 here. BUT,

looking closer to it, I am getting this in the menuconfig on the flag
you added:
  │ Symbol: 64BIT [=64BIT]
  │  
  │ Type  : unknown   


  Am I missing something?


  BR,

Eduardo

Re: [PATCH v4 2/4] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver

2016-12-06 Thread Eduardo Valentin 
On Thu, Dec 01, 2016 at 11:04:40PM +0100, Wolfram Sang wrote:
> Add support for R-Car Gen3 thermal sensors. Polling only for now,
> interrupts will be added incrementally. Same goes for reading fuses.
> This is documented already, but no hardware available for now.
> 
> Signed-off-by: Hien Dang 
> Signed-off-by: Thao Nguyen 
> Signed-off-by: Khiem Nguyen 
> Signed-off-by: Wolfram Sang 

Would you please check the following from checkpatch too?
That is how the patch would apply. Enter to continue

WARNING: please write a paragraph that describes the config symbol fully
#82: FILE: drivers/thermal/Kconfig:248:
+config RCAR_GEN3_THERMAL

WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#107: 
new file mode 100644

CHECK: struct mutex definition without comment
#186: FILE: drivers/thermal/rcar_gen3_thermal.c:75:
+   struct mutex lock;

WARNING: line over 80 characters
#204: FILE: drivers/thermal/rcar_gen3_thermal.c:93:
+static inline u32 rcar_gen3_thermal_read(struct rcar_gen3_thermal_tsc *tsc, 
u32 reg)

CHECK: Alignment should match open parenthesis
#210: FILE: drivers/thermal/rcar_gen3_thermal.c:99:
+static inline void rcar_gen3_thermal_write(struct rcar_gen3_thermal_tsc *tsc,
+u32 reg, u32 data)

WARNING: line over 80 characters
#219: FILE: drivers/thermal/rcar_gen3_thermal.c:108:
+   round_offs = temp >= 0 ? RCAR3_THERMAL_GRAN / 2 : -RCAR3_THERMAL_GRAN / 
2;

CHECK: Alignment should match open parenthesis
#254: FILE: drivers/thermal/rcar_gen3_thermal.c:143:
+static int _linear_temp_converter(struct equation_coefs *coef,
+   int temp_code)

CHECK: Alignment should match open parenthesis
#304: FILE: drivers/thermal/rcar_gen3_thermal.c:193:
+   rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR,
+  CTSR_PONM | CTSR_AOUT | CTSR_THBGR | CTSR_VMEN);

CHECK: Alignment should match open parenthesis
#309: FILE: drivers/thermal/rcar_gen3_thermal.c:198:
+   rcar_gen3_thermal_write(tsc, REG_GEN3_CTSR,
+ CTSR_PONM | CTSR_AOUT | CTSR_THBGR | CTSR_VMEN |

WARNING: line over 80 characters
#361: FILE: drivers/thermal/rcar_gen3_thermal.c:250:
+   const struct rcar_gen3_thermal_data *match_data = 
of_device_get_match_data(dev);

CHECK: Alignment should match open parenthesis
#406: FILE: drivers/thermal/rcar_gen3_thermal.c:295:
+   zone = devm_thermal_zone_of_sensor_register(dev, i, tsc,
+   _gen3_tz_of_ops);

total: 0 errors, 5 warnings, 6 checks, 346 lines checked



> ---
> 
> Changes since v3:
> 
> * call 'init' callback a tad earlier, avoids need for locking
> * converted spinlock to mutex and simplified locking (only done against
>   concurrent access in rcar_gen3_thermal_get_temp() now)
> * use usleep_range instead of udelay
> * use s64 instead of long (int didn't work)
> * fixed an error path
> * simplified rcar_gen3_thermal_update_temp() and its use
> 
> Thanks a lot to Eduardo and Geert for the prompt reviews!
> 
>  drivers/thermal/Kconfig |   9 +
>  drivers/thermal/Makefile|   1 +
>  drivers/thermal/rcar_gen3_thermal.c | 324 
> 
>  3 files changed, 334 insertions(+)
>  create mode 100644 drivers/thermal/rcar_gen3_thermal.c
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index c2c056cc7ea52e..3912d24a07b10f 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -245,6 +245,15 @@ config RCAR_THERMAL
> Enable this to plug the R-Car thermal sensor driver into the Linux
> thermal framework.
>  
> +config RCAR_GEN3_THERMAL
> + tristate "Renesas R-Car Gen3 thermal driver"
> + depends on ARCH_RENESAS || COMPILE_TEST
> + depends on HAS_IOMEM
> + depends on OF
> + help
> +   Enable this to plug the R-Car Gen3 thermal sensor driver into the 
> Linux
> +   thermal framework.
> +
>  config KIRKWOOD_THERMAL
>   tristate "Temperature sensor on Marvell Kirkwood SoCs"
>   depends on MACH_KIRKWOOD || COMPILE_TEST
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index c92eb22a41ff89..1216fb31ed4036 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM)  += 
> qcom-spmi-temp-alarm.o
>  obj-$(CONFIG_SPEAR_THERMAL)  += spear_thermal.o
>  obj-$(CONFIG_ROCKCHIP_THERMAL)   += rockchip_thermal.o
>  obj-$(CONFIG_RCAR_THERMAL)   += rcar_thermal.o
> +obj-$(CONFIG_RCAR_GEN3_THERMAL)  += rcar_gen3_thermal.o
>  obj-$(CONFIG_KIRKWOOD_THERMAL)  += kirkwood_thermal.o
>  obj-y+= samsung/
>  obj-$(CONFIG_DOVE_THERMAL)   += dove_thermal.o
> diff --git a/drivers/thermal/rcar_gen3_thermal.c 
> b/drivers/thermal/rcar_gen3_thermal.c
> new file mode

Re: [PATCH v4 5/4] thermal: rcar_gen3_thermal: restrict to 64BIT

2016-12-06 Thread Eduardo Valentin 
On Fri, Dec 02, 2016 at 09:44:22PM +0100, Wolfram Sang wrote:
> COMPILE_TEST triggers problems on 32 bit machines, so limit this driver
> to 64BIT for now. This is no loss because the hardware is only available
> on 64 bit SoCs anyhow. After we obtained more data from the hardware
> engineers, we will refactor the code to be usable with COMPILE_TEST.
> 

Don't you want to fold this one into patch 2 and mention the limitation
on that patch's commit log?

> Signed-off-by: Wolfram Sang 
> ---
> 
> buildbot reported the problem and seems to be happy now.
> 
>  drivers/thermal/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 3912d24a07b10f..edaed1282791bf 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -247,7 +247,7 @@ config RCAR_THERMAL
>  
>  config RCAR_GEN3_THERMAL
>   tristate "Renesas R-Car Gen3 thermal driver"
> - depends on ARCH_RENESAS || COMPILE_TEST
> + depends on ARCH_RENESAS && 64BIT
>   depends on HAS_IOMEM
>   depends on OF
>   help
> -- 
> 2.10.2
>

Re: [PATCH 15/22] dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings

2016-12-06 Thread Rob Herring 
On Fri, Dec 02, 2016 at 01:43:30AM +0200, Laurent Pinchart wrote:
> The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add
> corresponding device tree bindings based on the DWC HDMI TX bindings
> model.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  .../bindings/display/bridge/renesas,dw-hdmi.txt| 75 
> ++
>  MAINTAINERS|  1 +
>  2 files changed, 76 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt

Acked-by: Rob Herring

Re: [PATCH 14/22] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation

2016-12-06 Thread Rob Herring 
On Fri, Dec 02, 2016 at 01:43:29AM +0200, Laurent Pinchart wrote:
> Make it clear that the core bridge/dw_hdmi.txt document isn't a device
> tree binding by itself but is meant to be referenced by platform device
> tree bindings, and update the Rockchip and Freescale DWC HDMI TX
> bindings to reference it.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  .../devicetree/bindings/display/bridge/dw_hdmi.txt | 85 
> +-
>  .../devicetree/bindings/display/imx/hdmi.txt   | 51 +++--
>  .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 43 +++
>  3 files changed, 91 insertions(+), 88 deletions(-)

Acked-by: Rob Herring 

Really, the ddc-i2c-bus prop needs to move to a connector node, but 
that's a separate problem. We might also want to drop the 'ddc-' part 
and have a generic way to refer to an i2c bus. There's a couple of other 
cases.

Rob

Re: [PATCH] iio: Add Maxim MAX11100 driver

2016-12-06 Thread Peter Meerwald-Stadler 
On Tue, 6 Dec 2016, Jacopo Mondi wrote:

> Add IIO driver for Maxim MAX11100 single-channel ADC.
> Support raw_read mode only.

comments below; very minimal driver, but several easy issues...

the read_raw() is supposed to return millivolts (after application of 
offset and scale); maybe need _SCALE?
 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/iio/adc/Kconfig|   9 +++
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/max11100.c | 165 
> +
>  3 files changed, 175 insertions(+)
>  create mode 100644 drivers/iio/adc/max11100.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 99c0514..e2f3340 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -285,6 +285,15 @@ config MAX1027
> To compile this driver as a module, choose M here: the module will be
> called max1027.
>  
> +config MAX11100
> + tristate "Maxim max11100 ADC driver"
> + depends on SPI
> + help
> +   Say yes here to build support for Maxim 11100 SPI ADC

Maxim max11100

> +
> +   To compile this driver as a module, choose M here: the module will be
> +   called max11100.
> +
>  config MAX1363
>   tristate "Maxim max1363 ADC driver"
>   depends on I2C
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 7a40c04..1463044 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>  obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
>  obj-$(CONFIG_LTC2485) += ltc2485.o
>  obj-$(CONFIG_MAX1027) += max1027.o
> +obj-$(CONFIG_MAX11100) += max11100.o
>  obj-$(CONFIG_MAX1363) += max1363.o
>  obj-$(CONFIG_MCP320X) += mcp320x.o
>  obj-$(CONFIG_MCP3422) += mcp3422.o
> diff --git a/drivers/iio/adc/max11100.c b/drivers/iio/adc/max11100.c
> new file mode 100644
> index 000..fbce287
> --- /dev/null
> +++ b/drivers/iio/adc/max11100.c
> @@ -0,0 +1,165 @@
> +/*
> + * iio/adc/max11100.c
> + * Maxim MAX11100 ADC Driver with IIO interface

MAX11100 or max11100

> + *
> + * Copyright (C) 2016 Renesas Electronics Corporation
> + * Copyright (C) 2016 Jacopo Mondi
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +struct max11100_state {
> + const struct max11100_chip_desc *desc;
> + struct spi_device *spi;
> + struct mutex lock;
> +};
> +
> +static struct iio_chan_spec max11100_channels[] = {
> + { /* [0] */
> + .type = IIO_VOLTAGE,
> + .channel = 0,

not indexed, so channel = 0 not needed

> + .address = 0,

address not needed (and no need to initialize to 0 anyway)

> + .scan_index = 0,

scan_index and scan_type not needed since no buffered support (yet); add 
this when needed

> + .scan_type = {
> + .sign = 'u',
> + .realbits = 16,
> + .storagebits = 24,
> + .shift = 8,
> + .repeat = 1,
> + .endianness = IIO_BE,
> + },
> + .output = 1,

no, ADC is typically not an output channel 

> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + },
> +};
> +
> +static const unsigned long max11100_scan_masks[] = {

scan_masks not needed since no buffered support

> + 0x,
> +};
> +
> +static struct max11100_chip_desc {
> + uint32_t num_chan;

why not just unsigned?

> + const unsigned long *scanmasks;

not needed (yet)

> + const struct iio_chan_spec *channels;
> +} max11100_desc = {
> + .num_chan = 1,

ARRAY_SIZE(max11100_channels)

> + .scanmasks = max11100_scan_masks,
> + .channels = max11100_channels,
> +};
> +
> +static int max11100_read_raw(struct iio_dev *indio_dev,
> +  struct iio_chan_spec const *chan,
> +  int *val, int *val2, long mask)
> +{
> + int ret;
> + struct max11100_state *state = iio_priv(indio_dev);
> + uint8_t buffer[3] = { 0, 0, 0 };

no need to initialize buffer; consider alignment requirements for SPI

> +
> + mutex_lock(>lock);

what is the mutex protecting?
must the spi_read() by protected? then the unlock can be placed right 
after the call...

> +
> + ret = spi_read(state->spi, (void *) buffer, 3);

sizeof(buffer)

> + if (ret) {
> + dev_err(_dev->dev, "SPI transfer failed\n");

mutex_unlock()!?

> + return ret;
> + }
> +
> + dev_dbg(_dev->dev, "ADC output values: "  \
> + "[0]: 0x%2x [1]: 0x%2x [2]: 0x%2x\n",

probably 0x%02x if really needed

> + buffer[0], buffer[1], buffer[2]);
> +
> + /* the first 8 bits sent out from ADC must be 0s */
> + if

RE: [RFC] New Device Tree property - "bonding"

2016-12-06 Thread Ramesh Shanmugasundaram 
Hi Rob,

> >> On Monday 05 Dec 2016 09:57:32 Rob Herring wrote:
> >> > On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote:
> >> > > On Monday 05 Dec 2016 08:18:34 Rob Herring wrote:
> >> > >> On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote:
> >> > >>> Hello DT maintainers,
> >> > >>>
> >> > >>> In one of the Renesas SoCs we have a device called DRIF
> >> > >>> (Digital Radio
> >> > >>> Interface) controller. A DRIF channel contains 4 external pins
> >> > >>> - SCK, SYNC, Data pins D0 & D1.
> >> > >>>
> >> > >>> Internally a DRIF channel is made up of two SPI slave devices
> >> > >>> (also called sub-channels here) that share common CLK & SYNC
> >> > >>> signals but have their own resource set. The DRIF channel can
> >> > >>> have either one of the sub-channel active at a time or both.
> >> > >>> When both sub-channels are active, they need to be managed
> >> > >>> together as one device as they share same CLK & SYNC. We plan
> >> > >>> to tie these two sub-channels together with a new property called
> "renesas,bonding".
> >> > >>
> >> > >> Is there no need to describe the master device? No GPIOs,
> >> > >> regulators or other sideband controls needed? If that's never
> >> > >> needed (which seems doubtful), then I would do something
> >> > >> different here probably with the master device as a child of one
> >> > >> DRIF and then phandles to master from the other DRIFs.
> >> > >> Otherwise, this looks
> >> fine to me.
> >> > >
> >> > > Here's a bit of background.
> >> > >
> >> > > The DRIF is an SPI receiver. It has three input pins, a clock
> >> > > line, a data line and a sync signal. The device is designed to be
> >> > > connected to a variety of data sources, usually plain SPI (1 data
> >> > > line), IIS (1 data
> >> > > line) but also radio tuners that output I/Q data
> >> > > (http://www.ni.com/tutorial/4805/en/) over two data lines.
> >> > >
> >> > > In the case of IQ each data sample is split in two I and Q values
> >> > > (typically 16 to 20 bits each in this case), and the values are
> >> > > transmitted serially over one data line each. The synchronization
> >> > > and clock signals are common to both data lines. The DRIF is
> >> > > optimized for this use case as the DRIF instances in the SoC
> >> > > (each of them having independent clocks, interrupts and control
> >> > > registers) are grouped by two, and the two instances in a group
> >> > > handle a single data line each but share the same clock and sync
> input.
> >> > >
> >> > > On the software side we need to group the I and Q values, which
> >> > > are DMA'ed to memory by the two DRIF instances, and make them
> >> > > available to userspace. The V4L2 API used here in SDR (Software
> >> > > Defined Radio) mode supports such use cases and exposes a single
> >> > > device node to userspace that allows control of the two DRIF
> >> > > instances as a single device. To be able to implement this we
> >> > > need kernel code to be aware of DRIF groups and, while binding to
> >> > > the DRIF instances separately, expose only one V4L2 device to
> userspace for each group.
> >> > >
> >> > > There's no master or slave instance from a hardware point of
> >> > > view, but the two instances are not interchangeable as they carry
> >> > > separate
> >> information.
> >> > > They must thus be identified at the driver level.
> >> >
> >> > By master, I meant the external master device that generates the IQ
> >> > data, not which of the internal DRIF blocks is a master of the other.
> >> > So back to my question, does the external master device need to be
> >> > described? I worry the answer now for a simple case is no, but then
> >> > later people are going to have cases needing to describe more. We
> >> > need to answer this question first before we can decide what this
> >> > binding should look like.
> >>
> >> Oh yes the external device certainly needs to be described. As it is
> >> controlled through a separate, general-purpose I2C or SPI controller,
> >> it should be a child node of that controller. The DRIF handles the
> >> data interface only, not the control interface of the external device.
> >
> > Yes, as Laurent mentioned, the external master will be described
> separately. The data interface with the master is described through port
> nodes. E.g.
> >
> > port {
> > drif0_ep: endpoint {
> >  remote-endpoint = <_ep>;
> > };
> > };
> >
> > Do we agree on this model please?
>
> Well, that's not complete as you should have both DRIF0 and DRIF1 having
> connections to the tuner. Then you can walk the graph and find everything,
> and you then don't need the bonding property.

Assuming the third party tuner exposes it's two data lines as two endpoints, it 
seems possible with of_graph.h apis to walk through tuner end points and get 
the phandle of the other DRIF device. However, there are couple of points 
coming to mind.

- The ctrl pins shared between two DRIFs

[PATCH] iio: Add Maxim MAX11100 driver

2016-12-06 Thread Jacopo Mondi 
Add IIO driver for Maxim MAX11100 single-channel ADC.
Support raw_read mode only.

Signed-off-by: Jacopo Mondi 
---
 drivers/iio/adc/Kconfig|   9 +++
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/max11100.c | 165 +
 3 files changed, 175 insertions(+)
 create mode 100644 drivers/iio/adc/max11100.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 99c0514..e2f3340 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -285,6 +285,15 @@ config MAX1027
  To compile this driver as a module, choose M here: the module will be
  called max1027.
 
+config MAX11100
+   tristate "Maxim max11100 ADC driver"
+   depends on SPI
+   help
+ Say yes here to build support for Maxim 11100 SPI ADC
+
+ To compile this driver as a module, choose M here: the module will be
+ called max11100.
+
 config MAX1363
tristate "Maxim max1363 ADC driver"
depends on I2C
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 7a40c04..1463044 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
 obj-$(CONFIG_LTC2485) += ltc2485.o
 obj-$(CONFIG_MAX1027) += max1027.o
+obj-$(CONFIG_MAX11100) += max11100.o
 obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
diff --git a/drivers/iio/adc/max11100.c b/drivers/iio/adc/max11100.c
new file mode 100644
index 000..fbce287
--- /dev/null
+++ b/drivers/iio/adc/max11100.c
@@ -0,0 +1,165 @@
+/*
+ * iio/adc/max11100.c
+ * Maxim MAX11100 ADC Driver with IIO interface
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ * Copyright (C) 2016 Jacopo Mondi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct max11100_state {
+   const struct max11100_chip_desc *desc;
+   struct spi_device *spi;
+   struct mutex lock;
+};
+
+static struct iio_chan_spec max11100_channels[] = {
+   { /* [0] */
+   .type = IIO_VOLTAGE,
+   .channel = 0,
+   .address = 0,
+   .scan_index = 0,
+   .scan_type = {
+   .sign = 'u',
+   .realbits = 16,
+   .storagebits = 24,
+   .shift = 8,
+   .repeat = 1,
+   .endianness = IIO_BE,
+   },
+   .output = 1,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   },
+};
+
+static const unsigned long max11100_scan_masks[] = {
+   0x,
+};
+
+static struct max11100_chip_desc {
+   uint32_t num_chan;
+   const unsigned long *scanmasks;
+   const struct iio_chan_spec *channels;
+} max11100_desc = {
+   .num_chan = 1,
+   .scanmasks = max11100_scan_masks,
+   .channels = max11100_channels,
+};
+
+static int max11100_read_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan,
+int *val, int *val2, long mask)
+{
+   int ret;
+   struct max11100_state *state = iio_priv(indio_dev);
+   uint8_t buffer[3] = { 0, 0, 0 };
+
+   mutex_lock(>lock);
+
+   ret = spi_read(state->spi, (void *) buffer, 3);
+   if (ret) {
+   dev_err(_dev->dev, "SPI transfer failed\n");
+   return ret;
+   }
+
+   dev_dbg(_dev->dev, "ADC output values: "  \
+   "[0]: 0x%2x [1]: 0x%2x [2]: 0x%2x\n",
+   buffer[0], buffer[1], buffer[2]);
+
+   /* the first 8 bits sent out from ADC must be 0s */
+   if (buffer[0]) {
+   dev_err(_dev->dev, "Invalid value: buffer[0] != 0\n");
+   return -EINVAL;
+   }
+
+   *val = (buffer[1] << 8) | buffer[2];
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static const struct iio_info max11100_info = {
+   .driver_module = THIS_MODULE,
+   .read_raw = max11100_read_raw,
+};
+
+static int max11100_probe(struct spi_device *spi)
+{
+   int ret;
+   struct iio_dev *indio_dev;
+   struct max11100_state *state;
+
+   indio_dev = devm_iio_device_alloc(>dev, sizeof(*state));
+   if (!indio_dev) {
+   pr_err("Can't allocate iio device\n");
+   return -ENOMEM;
+   }
+   dev_dbg(_dev->dev, "probe max11100 IIO SPI\n");
+
+   spi_set_drvdata(spi, indio_dev);
+
+   state = iio_priv(indio_dev);
+   state->spi = spi;
+   state->desc = _desc;
+
+   mutex_init(>lock);
+
+   indio_dev->dev.parent = >dev;
+   indio_dev->dev.of_node = spi->dev.of_node;
+   indio_dev->info = _info;
+

[PATCH v4 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings

2016-12-06 Thread Simon Horman 
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that it's not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant of the former or vice versa.

We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.

For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme is being adopted for
drivers for Renesas SoCs.

Also:
* Deprecate renesas,i2c-rcar. It seems poorly named as it is only
  compatible with R-Car Gen 1. It also appears unused in mainline.
* Add some text to describe per-SoC bindings

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
v5
* s/R8A7797/R8A777/

v4
* Correct grammar in changelog

v3
* Consistently use renesas,- for new compat strings
* Drop RFC designation

v2
* Include accidently omitted i2c-rcar.c portion of patch
---
 Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++
 drivers/i2c/busses/i2c-rcar.c  |  5 +++-
 2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt 
b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index 239632a0d709..2b8bd33dbf8d 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -1,17 +1,25 @@
 I2C for R-Car platforms
 
 Required properties:
-- compatible: Must be one of
-   "renesas,i2c-rcar"
-   "renesas,i2c-r8a7778"
-   "renesas,i2c-r8a7779"
-   "renesas,i2c-r8a7790"
-   "renesas,i2c-r8a7791"
-   "renesas,i2c-r8a7792"
-   "renesas,i2c-r8a7793"
-   "renesas,i2c-r8a7794"
-   "renesas,i2c-r8a7795"
-   "renesas,i2c-r8a7796"
+- compatible:
+   "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
+   "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC.
+   "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
+   "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
+   "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
+   "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
+   "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
+   "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
+   "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
+   "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
+   "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 compatible device.
+   "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device.
+   "renesas,i2c-rcar" (deprecated)
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first followed
+   by the generic version.
+
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: interrupt specifier.
@@ -33,7 +41,7 @@ Examples :
 i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "renesas,i2c-r8a7791";
+   compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7791_CLK_I2C0>;
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 726615e54f2a..622def6b43e2 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
 };
 
 static const struct of_device_id rcar_i2c_dt_ids[] = {
-   { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
@@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
{ .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
{ .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
{ .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
+   { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
// Deprecated
+   { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1 
},
+   { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 
},
+   { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3 
},
{},
 };
 MODULE_DEVICE_TABLE(of,

[PATCH pci/next v3 3/3] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar

2016-12-06 Thread Simon Horman 
Add fallback compatibility string for the  R-Car Gen 3 family.  This is in
keeping with the both the existing fallback compatibility string for the
R-Car Gen 2 family and the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman 
---
v3
* s/rcar_pcie_hw_init_hw_init/rcar_pcie_hw_init/
v2
* Move fallback binding to below SoC specific bindings it covers
  in implementation
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
 drivers/pci/host/pcie-rcar.c   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt 
b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 6cf99690eef9..eee518db90b9 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -7,6 +7,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
"renesas,pcie-r8a7793" for the R8A7793 SoC;
"renesas,pcie-r8a7795" for the R8A7795 SoC;
"renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
+   "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
 
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 85971bc276c6..aca85be101f8 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -1078,6 +1078,7 @@ static const struct of_device_id rcar_pcie_of_match[] = {
{ .compatible = "renesas,pcie-rcar-gen2",
  .data = rcar_pcie_hw_init_gen2 },
{ .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
+   { .compatible = "renesas,pcie-rcar-gen3", .data = rcar_pcie_hw_init },
{},
 };
 
-- 
2.7.0.rc3.207.g0ac5344

[PATCH pci/next v3 2/3] PCI: rcar: Use gen2 fallback compatibility last

2016-12-06 Thread Simon Horman 
Improve readability by listing fallback compatibility strings
after the more-specific compatibility strings they provide a fallback for.

This does not effect run-time behaviour as it is the order in the DTB that
determines which compatibility string is used.

Signed-off-by: Simon Horman 
---
v3
* Reworded changelog: the ordering does not effect run-time behaviour
v2
* New patch
---
 drivers/pci/host/pcie-rcar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 62700d1896f4..85971bc276c6 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -1071,12 +1071,12 @@ static int rcar_pcie_parse_map_dma_ranges(struct 
rcar_pcie *pcie,
 
 static const struct of_device_id rcar_pcie_of_match[] = {
{ .compatible = "renesas,pcie-r8a7779", .data = rcar_pcie_hw_init_h1 },
-   { .compatible = "renesas,pcie-rcar-gen2",
- .data = rcar_pcie_hw_init_gen2 },
{ .compatible = "renesas,pcie-r8a7790",
  .data = rcar_pcie_hw_init_gen2 },
{ .compatible = "renesas,pcie-r8a7791",
  .data = rcar_pcie_hw_init_gen2 },
+   { .compatible = "renesas,pcie-rcar-gen2",
+ .data = rcar_pcie_hw_init_gen2 },
{ .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
{},
 };
-- 
2.7.0.rc3.207.g0ac5344

[PATCH pci/next v3 1/3] PCI: rcar-gen2: Use gen2 fallback compatibility last

2016-12-06 Thread Simon Horman 
Improve readability by listing fallback compatibility strings
after the more-specific compatibility strings they provide a fallback for.

This does not effect run-time behaviour as it is the order in the DTB that
determines which compatibility string is used.

Signed-off-by: Simon Horman 
---
v3
* Reworded changelog: the ordering does not effect run-time behaviour
v2
* New patch
---
 drivers/pci/host/pci-rcar-gen2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pci-rcar-gen2.c b/drivers/pci/host/pci-rcar-gen2.c
index 1eeefa4df64c..85348590848b 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -430,10 +430,10 @@ static int rcar_pci_probe(struct platform_device *pdev)
 }
 
 static struct of_device_id rcar_pci_of_match[] = {
-   { .compatible = "renesas,pci-rcar-gen2", },
{ .compatible = "renesas,pci-r8a7790", },
{ .compatible = "renesas,pci-r8a7791", },
{ .compatible = "renesas,pci-r8a7794", },
+   { .compatible = "renesas,pci-rcar-gen2", },
{ },
 };
 
-- 
2.7.0.rc3.207.g0ac5344

[PATCH pci/next v3 0/3] PCI: rcar, rcar-gen2: Bindings cleanups

2016-12-06 Thread Simon Horman 
Hi,

this short series makes some bindings cleanups to the Renesas PCI drivers.

Changes v2->v3:
* Reworded changelogs to indicate that re-ordering struct of_device_id
  entries does not effect run-time behaviour
* Corrected compile error due to typo in symbol name
Changes v1->v2:
* re-order struct of_device_id entries

Simon Horman (3):
  PCI: rcar-gen2: Use gen2 fallback compatibility last
  PCI: rcar: Use gen2 fallback compatibility last
  PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar

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

-- 
2.7.0.rc3.207.g0ac5344

RE: [RFC] New Device Tree property - "bonding"

2016-12-06 Thread Ramesh Shanmugasundaram 
Hi Rob, Laurent,

Thanks for the response.

> On Monday 05 Dec 2016 09:57:32 Rob Herring wrote:
> > On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote:
> > > On Monday 05 Dec 2016 08:18:34 Rob Herring wrote:
> > >> On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote:
> > >>> Hello DT maintainers,
> > >>>
> > >>> In one of the Renesas SoCs we have a device called DRIF (Digital
> > >>> Radio
> > >>> Interface) controller. A DRIF channel contains 4 external pins -
> > >>> SCK, SYNC, Data pins D0 & D1.
> > >>>
> > >>> Internally a DRIF channel is made up of two SPI slave devices
> > >>> (also called sub-channels here) that share common CLK & SYNC
> > >>> signals but have their own resource set. The DRIF channel can have
> > >>> either one of the sub-channel active at a time or both. When both
> > >>> sub-channels are active, they need to be managed together as one
> > >>> device as they share same CLK & SYNC. We plan to tie these two
> > >>> sub-channels together with a new property called "renesas,bonding".
> > >>
> > >> Is there no need to describe the master device? No GPIOs,
> > >> regulators or other sideband controls needed? If that's never
> > >> needed (which seems doubtful), then I would do something different
> > >> here probably with the master device as a child of one DRIF and
> > >> then phandles to master from the other DRIFs. Otherwise, this looks
> fine to me.
> > >
> > > Here's a bit of background.
> > >
> > > The DRIF is an SPI receiver. It has three input pins, a clock line,
> > > a data line and a sync signal. The device is designed to be
> > > connected to a variety of data sources, usually plain SPI (1 data
> > > line), IIS (1 data
> > > line) but also radio tuners that output I/Q data
> > > (http://www.ni.com/tutorial/4805/en/) over two data lines.
> > >
> > > In the case of IQ each data sample is split in two I and Q values
> > > (typically 16 to 20 bits each in this case), and the values are
> > > transmitted serially over one data line each. The synchronization
> > > and clock signals are common to both data lines. The DRIF is
> > > optimized for this use case as the DRIF instances in the SoC (each
> > > of them having independent clocks, interrupts and control registers)
> > > are grouped by two, and the two instances in a group handle a single
> > > data line each but share the same clock and sync input.
> > >
> > > On the software side we need to group the I and Q values, which are
> > > DMA'ed to memory by the two DRIF instances, and make them available
> > > to userspace. The V4L2 API used here in SDR (Software Defined Radio)
> > > mode supports such use cases and exposes a single device node to
> > > userspace that allows control of the two DRIF instances as a single
> > > device. To be able to implement this we need kernel code to be aware
> > > of DRIF groups and, while binding to the DRIF instances separately,
> > > expose only one V4L2 device to userspace for each group.
> > >
> > > There's no master or slave instance from a hardware point of view,
> > > but the two instances are not interchangeable as they carry separate
> information.
> > > They must thus be identified at the driver level.
> >
> > By master, I meant the external master device that generates the IQ
> > data, not which of the internal DRIF blocks is a master of the other.
> > So back to my question, does the external master device need to be
> > described? I worry the answer now for a simple case is no, but then
> > later people are going to have cases needing to describe more. We need
> > to answer this question first before we can decide what this binding
> > should look like.
>
> Oh yes the external device certainly needs to be described. As it is
> controlled through a separate, general-purpose I2C or SPI controller, it
> should be a child node of that controller. The DRIF handles the data
> interface only, not the control interface of the external device.

Yes, as Laurent mentioned, the external master will be described separately. 
The data interface with the master is described through port nodes. E.g.

port {
drif0_ep: endpoint {
 remote-endpoint = <_ep>;
};
};

Do we agree on this model please?

>
> > > Back to the DT bindings, the need to expose relationships between
> > > (mostly) independent devices is quite common nowadays. It has been
> > > solved in some cases by creating a separate DT node that does not
> > > correspond to any physical hardware and whose sole purpose is to
> > > contain phandles to devices that need to be grouped. Drivers then
> > > bind to the compatible string of that "virtual" DT node. The
> > > proposed bonding property is a different approach to solve a similar
> > > problem. Would it be worth it addressing the problem at a more
> > > general level and try to design a common solution ?
> >
> > We already have somewhat standard ways of grouping, but they are per
> > type of device

renesas-drivers-2016-12-06-v4.9-rc8

2016-12-06 Thread Geert Uytterhoeven 
I have pushed renesas-drivers-2016-12-06-v4.9-rc8 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 branches with driver code
submitted or planned for submission to maintainers into the development
branch of Simon Horman's renesas.git tree.

As we are currently focusing on a stable v4.9, no for-next branches
of various subsystem trees have been included.

Today's version is based on renesas-devel-20161205-v4.9-rc8.

Included branches with driver code:
  - clk-renesas-for-v4.11
  - sh-pfc-for-v4.11
  - topic/rcar-secondary-booting-in-debug-mode-v2
  - topic/r8a7796-ravb-v1-rebased1
  - topic/r8a7796-dmac-driver-v2-rebased1
  - topic/r8a7796-dmac-dts-v2-rebased3~3
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/sdr104-driver-v8
  - topic/vin-gen2-driver-v1-rebased2
  - topic/rcar-gen3-usb2-role-swap-v5
  - topic/dma-map-resource-v1
  - git://linuxtv.org/pinchartl/media.git#vsp1/histogram
  - https://git.ragnatech.se/linux#for-renesas-drivers
  - topic/ipmmu-multi-arch-v6
  - topic/r8a7795-ipmmu-v2-rebased4
  - topic/r8a7796-ipmmu-v1-rebased4
  - topic/r8a7795-ipmmu-integration-v1
  - topic/vin-gen2-dts-v1-rebased5
  - topic/vsp1-pa-improvements-v1-rebased1
  - topic/vsp1-writeback-v2-rebased2
  - git://linuxtv.org/pinchartl/media.git#drm/r8a7796/next
  - topic/iommu-devel-du-rebased1
  - topic/r8a7795-es2-v1-rebased5
  - topic/r8a7796-64b-mem+ravb-prototype-v1-rebased5~1
  - topic/rcar-du-lvds-mode-selection-v1
  - git://linuxtv.org/pinchartl/media.git#drm/next/lvds
  - git://github.com/uli/kernel.git#r8a7795-hdmi-out-driver-v1
  - git://github.com/uli/kernel.git#r8a7795-hdmi-out-dts-v1

As we're getting close to the opening of the merge window for v4.10, I
have also pushed renesas-drivers-next-2016-12-06-v4.9-rc8 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

This tree lacks the last 4 branches above, but does include the
following for-next branches of various subsystem trees:

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/cjb/mmc.git#mmc-next
  - 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.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine.git#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://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - git://git.infradead.org/battery-2.6.git#master
  - 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-intel#topic/drm-misc
  - 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
  -

Re: [PATCH] drm: rcar-du: Fix R-Car Gen3 crash when VSP is disabled

2016-12-06 Thread Laurent Pinchart 
Hello,

On Wednesday 26 Oct 2016 18:13:23 Magnus Damm wrote:
> On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven wrote:
> > On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote:
> >> From: Magnus Damm 
> >> 
> >> For the DU to operate on R-Car Gen3 hardware a combination of DU
> >> and VSP devices are required. Since the DU driver also supports
> >> earlier generations hardware the VSP portion is enabled via Kconfig.
> >> 
> >> The arm64 defconfig is as of v4.9-rc1 having the DU driver enabled
> >> as a module, however this is not enough to support R-Car Gen3. In
> >> the current case of CONFIG_DRM_RCAR_VSP=n then the kernel crashes
> >> when loading the module. This patch is fixing that particular case.
> >> 
> >> In more detail, the crash triggers in drm_atomic_get_plane_state()
> >> when __drm_atomic_helper_set_config() passes NULL as crtc->primary.
> >> 
> >> This patch corrects this issue by failing to load the DU driver on
> >> R-Car Gen3 when VSP is not available.
> >> 
> >> Signed-off-by: Magnus Damm 
> >> ---
> >> 
> >>  drivers/gpu/drm/rcar-du/rcar_du_vsp.h |2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> --- 0001/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> >> +++ work/drivers/gpu/drm/rcar-du/rcar_du_vsp.h  2016-10-26
> >> 00:01:12.920607110 +0900 @@ -70,7 +70,7 @@ void
> >> rcar_du_vsp_disable(struct rcar_du_
> >> 
> >>  void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
> >>  void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
> >>  #else
> >> 
> >> -static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp) { return 0;
> >> };
> >> +static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp) { return
> >> -ENXIO; };

With this patch applied the DU will fail to probe on Gen2 if DRM_RCAR_VSP is 
disabled.

DRM_RCAR_DU should instead depend on VIDEO_RENESAS_VSP1 (with DRM_RCAR_VSP 
always set) on Gen3.

> > -ENODEV sounds more appropriate
> 
> Ok, however -ENXIO is the same error code as the DU driver currently
> returns when dealing with the VSP and not finding DT nodes.
> 
> To avoid dealing with this again I would prefer skipping per-driver
> Kconfig options entirely, for instance something like this:
> 
> [PATCH/RFC] Simplify Gen3 DU and VSP Kconfig bits
> https://www.spinics.net/lists/linux-sh/msg45978.html
> 
> >>  static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
> >>  static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
> >>  static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) {
> >>  };
> > 
> > Alternatively,  DRM_RCAR_DU can force DRM_RCAR_VSP to y if ARCH_R8A7795
> > or ARCH_R8A7796 is enabled.
> 
> The DU driver has symbol dependencies on VSP and FCP driver code
> (V4L2), so we need to take the state of driver support for those
> modules into consideration as well instead of only depending on
> SoC-specific Kconfig symbols.
> 
> On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven wrote:
> > On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote:
> >> The arm64 defconfig is as of v4.9-rc1 having the DU driver enabled
> >> as a module, however this is not enough to support R-Car Gen3. In
> > 
> > Nope, arm64 defconfig on v4.9-rc1:
> > # CONFIG_DRM_RCAR_DU is not set
> 
> Right, you are correct. Sorry for the noise. It seems that I was using
> renesas-drivers-2016-10-18-v4.9-rc1 - not mainline v4.9-rc1.
> 
> Without this fix the driver still crashes, but not due to defconfig in
> v4.9-rc1.

-- 
Regards,

Laurent Pinchart

Re: [PATCH renesas/devel 2/2] ARM: multi_v7_defconfig: Enable r8a774[35] SoCs

2016-12-06 Thread Geert Uytterhoeven 
On Tue, Dec 6, 2016 at 2:32 PM, Simon Horman  wrote:
> Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.
>
> Signed-off-by: Simon Horman 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH renesas/devel 1/2] ARM: shmobile: defconfig: Enable r8a774[35] SoCs

2016-12-06 Thread Geert Uytterhoeven 
On Tue, Dec 6, 2016 at 2:32 PM, Simon Horman  wrote:
> Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.
>
> Signed-off-by: Simon Horman 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH renesas/devel 2/2] ARM: multi_v7_defconfig: Enable r8a774[35] SoCs

2016-12-06 Thread Simon Horman 
Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.

Signed-off-by: Simon Horman 
---
 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 11f37ed1dbff..770e96d61a64 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -87,6 +87,8 @@ CONFIG_ARCH_EMEV2=y
 CONFIG_ARCH_R7S72100=y
 CONFIG_ARCH_R8A73A4=y
 CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7743=y
+CONFIG_ARCH_R8A7745=y
 CONFIG_ARCH_R8A7778=y
 CONFIG_ARCH_R8A7779=y
 CONFIG_ARCH_R8A7790=y
-- 
2.7.0.rc3.207.g0ac5344

[PATCH renesas/devel 1/2] ARM: shmobile: defconfig: Enable r8a774[35] SoCs

2016-12-06 Thread Simon Horman 
Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.

Signed-off-by: Simon Horman 
---
 arch/arm/configs/shmobile_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index b66e17aec058..760688aa5c79 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -14,6 +14,8 @@ CONFIG_ARCH_EMEV2=y
 CONFIG_ARCH_R7S72100=y
 CONFIG_ARCH_R8A73A4=y
 CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7743=y
+CONFIG_ARCH_R8A7745=y
 CONFIG_ARCH_R8A7778=y
 CONFIG_ARCH_R8A7779=y
 CONFIG_ARCH_R8A7790=y
-- 
2.7.0.rc3.207.g0ac5344

[PATCH renesas/devel 0/2] ARM: Enable r8a774[35] SoCs in defconfigs

2016-12-06 Thread Simon Horman 
Hi,

this short series enables recently added r8a7743 (RZ/G1M) and r8a7745
(RZ/G1E) SoCs in relevant defconfigs.

Based on renesas-devel-20161206-v4.9-rc8

Simon Horman (2):
  ARM: shmobile: defconfig: Enable r8a774[35] SoCs
  ARM: multi_v7_defconfig: Enable r8a774[35] SoCs

 arch/arm/configs/multi_v7_defconfig | 2 ++
 arch/arm/configs/shmobile_defconfig | 2 ++
 2 files changed, 4 insertions(+)

-- 
2.7.0.rc3.207.g0ac5344

Re: [PATCH v2 0/5] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode

2016-12-06 Thread Geert Uytterhoeven 
Hi Simon,

On Tue, Dec 6, 2016 at 1:39 PM, Simon Horman  wrote:
> On Mon, Dec 05, 2016 at 11:39:36AM +0100, Geert Uytterhoeven wrote:
>> This patch series allows booting secondary CPU cores on R-Car Gen2 when
>> hardware debug mode is enabled. In this mode, reset requests derived

> Thanks, I have tentatively queued this up for v4.11.
>
> I have pulled in the rcar-rst dependency with the expectation ttha
> it will disappear when I rebase on v4.10-rc1 once it has been released.

Thank you very much!

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 0/5] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode

2016-12-06 Thread Simon Horman 
On Mon, Dec 05, 2016 at 11:39:36AM +0100, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> This patch series allows booting secondary CPU cores on R-Car Gen2 when
> hardware debug mode is enabled. In this mode, reset requests derived
> from power-shutoff to the AP-system CPU cores must be enabled before the
> AP-system CPU cores resume from power-shutoff for the first time.
> Else resume may fail, causing the system to hang during boot.
> Currently we avoid the hang by prohibiting booting secondary CPU cores
> when hardware debug mode is enabled (except on legacy r8a7790, see
> below).
> 
> On all R-Car Gen2 SoCs, hardware debug mode is enabled by setting
> MD21=1.  On both Koelsch and Lager, this is done by setting mode switch
> SW8-4 to OFF.
> 
> Unfortunately the hang is not easy to reproduce: I only saw it (on
> Koelsch) during real cold boot (power off during the night), and even
> then it's not guaranteed to trigger. Pressing the reset button
> afterwards recovers the system, and a subsequent boot will succeed
> (incl. secondary CPU core boot).
> 
> This series configures the reset requests as documented in the R-Car
> Gen2 datasheet, and removes the check for MD21 during secondary CPU
> bringup.  It was inspired by CPU-specific patches in the BSP by
> Nakamura-san.
> 
> And finally, we get rid of reading the Mode Monitoring register using
> hardcoded addresses in platform code!
> 
> This series also fixes a minor regression introduced by adding the
> "renesas,apmu" enable-method on Lager, where secondary CPU cores are no
> longer available when hardware debug mode is enabled.
> 
> This has been boot-tested on r8a7791/koelsch (both debug mode and normal
> mode), on r8a7790/lager, r8a7792/blanche, and r8a7793/gose (normal mode
> only), and on r8a7794/alt (normal mode UP only).  Its core parts have
> been in renesas-drivers since renesas-drivers-2016-09-06-v4.8-rc5.
> 
> Changes compared to v1:
>   - Add Tested-by,
>   - New patch "ARM: shmobile: rcar-gen2: Remove unused
> rcar_gen2_read_mode_pins()".
> 
> This series is against renesas-devel-20161202-v4.9-rc7, with my
> "rcar-rst" branch merged in, which resulted in a merge conflict.
> The latter dependency is present in clk-next, and expected to land
> upstream in v4.10-rc1.
> 
> For your convenience (and for conflict resolution), this series is also
> available in the topic/rcar-secondary-booting-in-debug-mode-v2 branch of
> my renesas-drivers git repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> 
> Thanks for applying!

Thanks, I have tentatively queued this up for v4.11.

I have pulled in the rcar-rst dependency with the expectation ttha
it will disappear when I rebase on v4.10-rc1 once it has been released.

[PATCH 2/4] v4l: vsp1: Refactor video pipeline configuration

2016-12-06 Thread Kieran Bingham 
With multiple inputs through the BRU it is feasible for the streams to
race each other at stream-on. In the case of the video pipelines, this
can present two serious issues.

 1) A null-dereference if the pipe->dl is committed at the same time as
the vsp1_video_setup_pipeline() is processing

 2) A hardware hang, where a display list is committed without having
called vsp1_video_setup_pipeline() first

Along side these race conditions, the work done by
vsp1_video_setup_pipeline() is undone by the re-initialisation during a
suspend resume cycle, and an active pipeline does not attempt to
reconfigure the correct routing and init parameters for the entities.

To repair all of these issues, we can move the call to a conditional
inside vsp1_video_pipeline_run() and ensure that this can only be called
on the last stream which calls into vsp1_video_start_streaming()

As a convenient side effect of this, by specifying that the
configuration has been lost during suspend/resume actions - the
vsp1_video_pipeline_run() call can re-initialise pipelines when
necessary thus repairing resume actions for active m2m pipelines.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drv.c   |  3 +++
 drivers/media/platform/vsp1/vsp1_pipe.c  |  1 +
 drivers/media/platform/vsp1/vsp1_pipe.h  |  2 ++
 drivers/media/platform/vsp1/vsp1_video.c | 20 +---
 4 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 57c713a4e1df..dd26549a6912 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -447,6 +447,9 @@ static int vsp1_device_init(struct vsp1_device *vsp1)
ret = vsp1_reset_wpf(vsp1, i);
if (ret < 0)
return ret;
+
+   if (vsp1->wpf[i] && vsp1->wpf[i]->pipe)
+   vsp1->wpf[i]->pipe->configured = false;
}
 
vsp1_write(vsp1, VI6_CLK_DCSWT, (8 << VI6_CLK_DCSWT_CSTPW_SHIFT) |
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 756ca4ea7668..7ddf862ee403 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -208,6 +208,7 @@ void vsp1_pipeline_init(struct vsp1_pipeline *pipe)
 
INIT_LIST_HEAD(>entities);
pipe->state = VSP1_PIPELINE_STOPPED;
+   pipe->configured = false;
 }
 
 /* Must be called with the pipe irqlock held. */
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index ac4ad261..0743b9fcb655 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -61,6 +61,7 @@ enum vsp1_pipeline_state {
  * @pipe: the media pipeline
  * @irqlock: protects the pipeline state
  * @state: current state
+ * @configured: determines routing configuration active on cell.
  * @wq: wait queue to wait for state change completion
  * @frame_end: frame end interrupt handler
  * @lock: protects the pipeline use count and stream count
@@ -86,6 +87,7 @@ struct vsp1_pipeline {
 
spinlock_t irqlock;
enum vsp1_pipeline_state state;
+   bool configured;
wait_queue_head_t wq;
 
void (*frame_end)(struct vsp1_pipeline *pipe);
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 44b687c0b8df..7ff9f4c19ff0 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -388,6 +388,8 @@ static int vsp1_video_setup_pipeline(struct vsp1_pipeline 
*pipe)
   VSP1_ENTITY_PARAMS_INIT);
}
 
+   pipe->configured = true;
+
return 0;
 }
 
@@ -411,6 +413,9 @@ static void vsp1_video_pipeline_run(struct vsp1_pipeline 
*pipe)
struct vsp1_device *vsp1 = pipe->output->entity.vsp1;
struct vsp1_entity *entity;
 
+   if (!pipe->configured)
+   vsp1_video_setup_pipeline(pipe);
+
if (!pipe->dl)
pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
 
@@ -793,25 +798,18 @@ static int vsp1_video_start_streaming(struct vb2_queue 
*vq, unsigned int count)
struct vsp1_video *video = vb2_get_drv_priv(vq);
struct vsp1_pipeline *pipe = video->rwpf->pipe;
unsigned long flags;
-   int ret;
 
mutex_lock(>lock);
if (pipe->stream_count == pipe->num_inputs) {
-   ret = vsp1_video_setup_pipeline(pipe);
-   if (ret < 0) {
-   mutex_unlock(>lock);
-   return ret;
-   }
+   spin_lock_irqsave(>irqlock, flags);
+   if (vsp1_pipeline_ready(pipe))
+   vsp1_video_pipeline_run(pipe);
+   spin_unlock_irqrestore(>irqlock, flags);
}
 
pipe->stream_count++;

[PATCH 3/4] v4l: vsp1: Use local display lists and remove global pipe->dl

2016-12-06 Thread Kieran Bingham 
The usage of pipe->dl is susceptible to races, and it is redundant to
keep this pointer in a larger scoped context.

Now that the calling order of vsp1_video_setup_pipeline() has been
adapted, it is possible to remove the pipe->dl and pass the variable as
required.

Currently the pipe->dl is set during the atomic begin hook, but it is
not utilised until the flush. Moving this should do no harm.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drm.c   | 20 +++---
 drivers/media/platform/vsp1/vsp1_pipe.h  |  2 --
 drivers/media/platform/vsp1/vsp1_video.c | 45 ++--
 3 files changed, 30 insertions(+), 37 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index cd209dccff1b..bf735e85b597 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -220,9 +220,6 @@ void vsp1_du_atomic_begin(struct device *dev)
struct vsp1_pipeline *pipe = >drm->pipe;
 
vsp1->drm->num_inputs = pipe->num_inputs;
-
-   /* Prepare the display list. */
-   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
 }
 EXPORT_SYMBOL_GPL(vsp1_du_atomic_begin);
 
@@ -426,10 +423,14 @@ void vsp1_du_atomic_flush(struct device *dev)
struct vsp1_pipeline *pipe = >drm->pipe;
struct vsp1_rwpf *inputs[VSP1_MAX_RPF] = { NULL, };
struct vsp1_entity *entity;
+   struct vsp1_dl_list *dl;
unsigned long flags;
unsigned int i;
int ret;
 
+   /* Prepare the display list. */
+   dl = vsp1_dl_list_get(pipe->output->dlm);
+
/* Count the number of enabled inputs and sort them by Z-order. */
pipe->num_inputs = 0;
 
@@ -484,26 +485,25 @@ void vsp1_du_atomic_flush(struct device *dev)
struct vsp1_rwpf *rpf = to_rwpf(>subdev);
 
if (!pipe->inputs[rpf->entity.index]) {
-   vsp1_dl_list_write(pipe->dl, entity->route->reg,
+   vsp1_dl_list_write(dl, entity->route->reg,
   VI6_DPR_NODE_UNUSED);
continue;
}
}
 
-   vsp1_entity_route_setup(entity, pipe->dl);
+   vsp1_entity_route_setup(entity, dl);
 
if (entity->ops->configure) {
-   entity->ops->configure(entity, pipe, pipe->dl,
+   entity->ops->configure(entity, pipe, dl,
   VSP1_ENTITY_PARAMS_INIT);
-   entity->ops->configure(entity, pipe, pipe->dl,
+   entity->ops->configure(entity, pipe, dl,
   VSP1_ENTITY_PARAMS_RUNTIME);
-   entity->ops->configure(entity, pipe, pipe->dl,
+   entity->ops->configure(entity, pipe, dl,
   VSP1_ENTITY_PARAMS_PARTITION);
}
}
 
-   vsp1_dl_list_commit(pipe->dl);
-   pipe->dl = NULL;
+   vsp1_dl_list_commit(dl);
 
/* Start or stop the pipeline if needed. */
if (!vsp1->drm->num_inputs && pipe->num_inputs) {
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 0743b9fcb655..98980c85081f 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -108,8 +108,6 @@ struct vsp1_pipeline {
 
struct list_head entities;
 
-   struct vsp1_dl_list *dl;
-
unsigned int div_size;
unsigned int partitions;
struct v4l2_rect partition;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 7ff9f4c19ff0..9619ed4dda7c 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -350,18 +350,14 @@ static void vsp1_video_frame_end(struct vsp1_pipeline 
*pipe,
pipe->buffers_ready |= 1 << video->pipe_index;
 }
 
-static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
+static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl)
 {
struct vsp1_entity *entity;
 
/* Determine this pipelines sizes for image partitioning support. */
vsp1_video_pipeline_setup_partitions(pipe);
 
-   /* Prepare the display list. */
-   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
-   if (!pipe->dl)
-   return -ENOMEM;
-
if (pipe->uds) {
struct vsp1_uds *uds = to_uds(>uds->subdev);
 
@@ -381,10 +377,10 @@ static int vsp1_video_setup_pipeline(struct vsp1_pipeline 
*pipe)
}
 
list_for_each_entry(entity, >entities, list_pipe) {
-   vsp1_entity_route_setup(entity, pipe->dl);
+

[PATCH RFC 4/4] media: Catch null pipes on pipeline stop

2016-12-06 Thread Kieran Bingham 
media_entity_pipeline_stop() can be called through error paths with a
NULL entity pipe object. In this instance, stopping is a no-op, so
simply return without any action

Signed-off-by: Kieran Bingham 
---

I've marked this patch as RFC, although if deemed suitable, by all means
integrate it as is.

When testing suspend/resume operations on VSP1, I encountered a segfault on the
WARN_ON(!pipe->streaming_count) line, where 'pipe == NULL'. The simple
protection fix is to return early in this instance, as this patch does however:

A) Does this early return path warrant a WARN() statement itself, to identify
drivers which are incorrectly calling media_entity_pipeline_stop() with an
invalid entity, or would this just be noise ...

and therefore..

B) I also partly assume this patch could simply get NAK'd with a request to go
and dig out the root cause of calling media_entity_pipeline_stop() with an
invalid entity. 

My brief investigation so far here so far shows that it's almost a second order
fault - where the first suspend resume cycle completes but leaves the entity in
an invalid state having followed an error path - and then on a second
suspend/resume - the stop fails with the affected segfault.

If statement A) or B) apply here, please drop this patch from the series, and
don't consider it a blocking issue for the other 3 patches.

Kieran


 drivers/media/media-entity.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index c68239e60487..93c9cbf4bf46 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -508,6 +508,8 @@ void __media_entity_pipeline_stop(struct media_entity 
*entity)
struct media_entity_graph *graph = >pipe->graph;
struct media_pipeline *pipe = entity->pipe;
 
+   if (!pipe)
+   return;
 
WARN_ON(!pipe->streaming_count);
media_entity_graph_walk_start(graph, entity);
-- 
2.7.4

[PATCH 1/4] v4l: vsp1: Move vsp1_video_setup_pipeline()

2016-12-06 Thread Kieran Bingham 
Move the static vsp1_video_setup_pipeline() function in preparation for
the callee updates so that the vsp1_video_pipeline_run() call can
configure pipelines following suspend resume actions.

This commit is just a code move for clarity performing no functional
change.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_video.c | 82 
 1 file changed, 41 insertions(+), 41 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index d351b9c768d2..44b687c0b8df 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -350,6 +350,47 @@ static void vsp1_video_frame_end(struct vsp1_pipeline 
*pipe,
pipe->buffers_ready |= 1 << video->pipe_index;
 }
 
+static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
+{
+   struct vsp1_entity *entity;
+
+   /* Determine this pipelines sizes for image partitioning support. */
+   vsp1_video_pipeline_setup_partitions(pipe);
+
+   /* Prepare the display list. */
+   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
+   if (!pipe->dl)
+   return -ENOMEM;
+
+   if (pipe->uds) {
+   struct vsp1_uds *uds = to_uds(>uds->subdev);
+
+   /* If a BRU is present in the pipeline before the UDS, the alpha
+* component doesn't need to be scaled as the BRU output alpha
+* value is fixed to 255. Otherwise we need to scale the alpha
+* component only when available at the input RPF.
+*/
+   if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
+   uds->scale_alpha = false;
+   } else {
+   struct vsp1_rwpf *rpf =
+   to_rwpf(>uds_input->subdev);
+
+   uds->scale_alpha = rpf->fmtinfo->alpha;
+   }
+   }
+
+   list_for_each_entry(entity, >entities, list_pipe) {
+   vsp1_entity_route_setup(entity, pipe->dl);
+
+   if (entity->ops->configure)
+   entity->ops->configure(entity, pipe, pipe->dl,
+  VSP1_ENTITY_PARAMS_INIT);
+   }
+
+   return 0;
+}
+
 static void vsp1_video_pipeline_run_partition(struct vsp1_pipeline *pipe,
  struct vsp1_dl_list *dl)
 {
@@ -747,47 +788,6 @@ static void vsp1_video_buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(>irqlock, flags);
 }
 
-static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
-{
-   struct vsp1_entity *entity;
-
-   /* Determine this pipelines sizes for image partitioning support. */
-   vsp1_video_pipeline_setup_partitions(pipe);
-
-   /* Prepare the display list. */
-   pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
-   if (!pipe->dl)
-   return -ENOMEM;
-
-   if (pipe->uds) {
-   struct vsp1_uds *uds = to_uds(>uds->subdev);
-
-   /* If a BRU is present in the pipeline before the UDS, the alpha
-* component doesn't need to be scaled as the BRU output alpha
-* value is fixed to 255. Otherwise we need to scale the alpha
-* component only when available at the input RPF.
-*/
-   if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
-   uds->scale_alpha = false;
-   } else {
-   struct vsp1_rwpf *rpf =
-   to_rwpf(>uds_input->subdev);
-
-   uds->scale_alpha = rpf->fmtinfo->alpha;
-   }
-   }
-
-   list_for_each_entry(entity, >entities, list_pipe) {
-   vsp1_entity_route_setup(entity, pipe->dl);
-
-   if (entity->ops->configure)
-   entity->ops->configure(entity, pipe, pipe->dl,
-  VSP1_ENTITY_PARAMS_INIT);
-   }
-
-   return 0;
-}
-
 static int vsp1_video_start_streaming(struct vb2_queue *vq, unsigned int count)
 {
struct vsp1_video *video = vb2_get_drv_priv(vq);
-- 
2.7.4

[PATCH 0/4] v4l: vsp1: Fix suspend/resume and race on M2M pipelines

2016-12-06 Thread Kieran Bingham 
This small patchset helps rework the VSP1 driver to repair an issue on
suspend/resume operations whereby the pipeline does not get reconfigured after
it has been re-initialised following a resume operation.

Along side this, there was an intrinsic race in the vsp1_video_start_streaming()
function whereby multiple streams operating through a BRU, could find themselves
commencing an operation before the pipeline has been configured, or worse -
commencing, just as the pipeline is being configured resulting in a null pointer
dereference on pipe->dl.

This series superceeds a previous effort to fix the BRU race.

Patch [1/4] is a code move only, with no functional change.
Patch [2/4] refactors the vsp1_video_start_streaming() function and fixes both
suspend/resume, and the BRU race in a single change
Patch [3/4] removes the context scoped 'pipe->dl' which has been susceptible to
races and isn't required to be in the context.
Patch [4/4] is an RFC patch really, that fixes a segfault on error paths  and I
certainly expect feedback and brief discussion. Please drop Patch 4
in the event of any further discussion, and don't consider it as
blocking for the first three patches of this series.

Kieran Bingham (4):
  v4l: vsp1: Move vsp1_video_setup_pipeline()
  v4l: vsp1: Refactor video pipeline configuration
  v4l: vsp1: Use local display lists and remove global pipe->dl
  media: Catch null pipes on pipeline stop

 drivers/media/media-entity.c |   2 +
 drivers/media/platform/vsp1/vsp1_drm.c   |  20 ++---
 drivers/media/platform/vsp1/vsp1_drv.c   |   3 +
 drivers/media/platform/vsp1/vsp1_pipe.c  |   1 +
 drivers/media/platform/vsp1/vsp1_pipe.h  |   4 +-
 drivers/media/platform/vsp1/vsp1_video.c | 127 +++
 6 files changed, 78 insertions(+), 79 deletions(-)

-- 
2.7.4