RE: [PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build

[Frank.Rowand]

On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann [mailto:a...@arndb.de]  
wrote:
>
> The *.dtb and *.dtb.S files get removed by 'make' during the build
> process,
> and later seem to be missed during the 'modpost' stage:
>
> rm drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb
> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb
> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb.S
> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb.S
> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S
> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb
> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb
> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb
> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb.S
> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb.S
> WARNING: could not open
> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S: No such file or
> directory
>
> As a workaround, this adds all those files to the 'extra-y' target list,
> but that's really ugly. Any ideas for a better fix?

Does this work for you (untested, but the way it is done in
drivers/of/unittest-data/Makefile):

.PRECIOUS: \
$(obj)/%.dtb.S \
$(obj)/%.dtb


-Frank


>
> Fixes: 81c0e3dd8292 ("drm: rcar-du: Fix legacy DT to create LVDS encoder
> nodes")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/rcar-du/Makefile | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile
> index 3e58ed93d5b1..e5fc6ec0b8cc 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -12,6 +12,21 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)  += rcar_du_of.o \
>rcar_du_of_lvds_r8a7793.dtb.o
> \
>rcar_du_of_lvds_r8a7795.dtb.o
> \
>rcar_du_of_lvds_r8a7796.dtb.o
> +
> +extra-y+=
> rcar_du_of_lvds_r8a7790.dtb \
> +  rcar_du_of_lvds_r8a7790.dtb \
> +  rcar_du_of_lvds_r8a7791.dtb \
> +  rcar_du_of_lvds_r8a7793.dtb \
> +  rcar_du_of_lvds_r8a7795.dtb \
> +  rcar_du_of_lvds_r8a7796.dtb
> +
> +extra-y+=
> rcar_du_of_lvds_r8a7790.dtb.S \
> +  rcar_du_of_lvds_r8a7790.dtb.S
> \
> +  rcar_du_of_lvds_r8a7791.dtb.S
> \
> +  rcar_du_of_lvds_r8a7793.dtb.S
> \
> +  rcar_du_of_lvds_r8a7795.dtb.S
> \
> +  rcar_du_of_lvds_r8a7796.dtb.S
> +
>  rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
>
>  obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
> --
> 2.9.0

Re: [PATCH 0/6] pinctrl: sh-pfc: rcar-gen3: Rename EtherAVB "mdc" pin group to "mdio"

[Niklas Söderlund]

Hi Geert,

Thanks for your work.

On 2018-03-12 15:40:16 +0100, Geert Uytterhoeven wrote:
>   Hi all,
> 
> On Renesas R-Car Gen2 SoCs, the pin group for the MDIO bus is named
> "mdio".
> 
> When initial support was added for R-Car H3, the MDIO pin was forgotten,
> and the MDC pin got its own group named "mdc".  During the addition of
> support for R-Car M3-W, this mistake was noticed.  But as R-Car H3 and
> M3-W are pin compatible, and can be mounted on the same boards, the
> decision was made to just add the MDIO pin to the existing "mdc" group.
> Later this was extended to R-Car H3 ES2.0, and M3-N, because of pin
> compatibility, and to R-Car D3, in the name of consistency among R-Car
> Gen3 SoCs.
> 
> However, this decision keeps on being questioned when adding new SoC
> support.  Hence bite the bullet and admit our mistake, and rename the
> pin group from "mdc" to "mdio", like on R-Car Gen2 SoCs.  Backwards
> compatibility with old DTBs is retained by using a pin group alias.

Thanks for fixing this, it frustrated me in the past :-) i like the pin 
alias solution neat! For the whole series,

Reviewed-by: Niklas Söderlund 

> 
> This patch series:
>   1. Introduces a macro for creating pin group aliases,
>   2. Renames the "mdc" pin group to "mdio" on R-Car H3 (ES1.x and
>  ES2.0), M3-W, M3-N, and D3.
> 
> Thanks for your comments!
> 
> Geert Uytterhoeven (6):
>   pinctrl: sh-pfc: Add SH_PFC_PIN_GROUP_ALIAS()
>   pinctrl: sh-pfc: r8a7795: Rename EtherAVB "mdc" pin group to "mdio"
>   pinctrl: sh-pfc: r8a7795-es1: Rename EtherAVB "mdc" pin group to
> "mdio"
>   pinctrl: sh-pfc: r8a7796: Rename EtherAVB "mdc" pin group to "mdio"
>   pinctrl: sh-pfc: r8a77965: Rename EtherAVB "mdc" pin group to "mdio"
>   pinctrl: sh-pfc: r8a77995: Rename EtherAVB "mdc" pin group to "mdio"
> 
>  drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c | 10 ++
>  drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 10 ++
>  drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 10 ++
>  drivers/pinctrl/sh-pfc/pfc-r8a77965.c| 10 ++
>  drivers/pinctrl/sh-pfc/pfc-r8a77995.c| 10 ++
>  drivers/pinctrl/sh-pfc/sh_pfc.h  |  5 +++--
>  6 files changed, 33 insertions(+), 22 deletions(-)
> 
> -- 
> 2.7.4
> 
> 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

-- 
Regards,
Niklas Söderlund

Re: [PATCH v5 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch.

This one must depend on '[PATCH v2 0/5] arm64: dts: renesas: r8a77970: 
enable HDMI output' or something similar not yet in renesas-drivers 
repository correct?

In the next version would you care to include the LVDS commit from the 
dependency  series and squash this change into that one or in some other 
good manger stack to two? Laurent told me he did not like 5/5 in that 
patch-set as it did not yet have the LVDS decoder node due to no driver 
existed at that time when I posted that even if it's not strictly needed 
to get the display working :-)

I also think you should split this last patch out to a separate series 
as it should go in Simon's tree while the driver and documentation is 
going in earlier in a different tree right?

On a side note, do you plan to update the Gen2 boards DTS files which 
also have a decoder which are not yet described in DT?

On 2018-03-15 17:11:56 +0100, Jacopo Mondi wrote:
> The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
> decoder, connected to the on-chip LVDS encoder output on one side
> and to HDMI encoder ADV7511w on the other one.
> 
> As the decoder does not need any configuration it has been so-far
> omitted from DTS. Now that a driver is available, describe it in DT
> as well.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> ---
>  arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 
> +++---
>  1 file changed, 30 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
> b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> index c0fd144..69f43b8 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> @@ -42,6 +42,33 @@
>   };
>   };
>   };
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + thc63lvd1024_in_0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + thc63lvd1024_out_2: endpoint {
> + remote-endpoint = <_in>;
> + };
> +
> + };
> +
> + };
> + };
>  };
>  
>   {
> @@ -98,7 +125,7 @@
>   port@0 {
>   reg = <0>;
>   adv7511_in: endpoint {
> - remote-endpoint = <_out>;
> + remote-endpoint = <_out_2>;
>   };
>   };
>  
> @@ -152,8 +179,8 @@
>  
>   ports {
>   port@1 {
> - endpoint {
> - remote-endpoint = <_in>;
> + lvds0_out: endpoint {
> + remote-endpoint = <_in_0>;
>   };
>   };
>   };
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v5 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch,

On 2018-03-15 17:11:55 +0100, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output converter.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/bridge/Kconfig|   6 +
>  drivers/gpu/drm/bridge/Makefile   |   1 +
>  drivers/gpu/drm/bridge/thc63lvd1024.c | 257 
> ++
>  3 files changed, 264 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3b99d5a..5815a20 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -92,6 +92,12 @@ config DRM_SII9234
> It is an I2C driver, that detects connection of MHL bridge
> and starts encapsulation of HDMI signal.
>  
> +config DRM_THINE_THC63LVD1024
> + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> + depends on OF
> + ---help---
> +   Thine THC63LVD1024 LVDS/parallel converter driver.
> +
>  config DRM_TOSHIBA_TC358767
>   tristate "Toshiba TC358767 eDP bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 373eb28..fd90b16 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>  obj-$(CONFIG_DRM_SII9234) += sii9234.o
> +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> new file mode 100644
> index 000..36069a0
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -0,0 +1,257 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> + *
> + * Copyright (C) 2018 Jacopo Mondi 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +enum {
> + THC63_LVDS_IN0,
> + THC63_LVDS_IN1,
> + THC63_DIGITAL_OUT0,
> + THC63_DIGITAL_OUT1,
> +};
> +
> +static const char * const thc63_reg_names[] = {
> + "vcc", "lvcc", "pvcc", "cvcc",
> +};
> +
> +struct thc63_dev {
> + struct device *dev;
> +
> + struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> +
> + struct gpio_desc *pdwn;
> + struct gpio_desc *oe;
> +
> + struct drm_bridge bridge;
> + struct drm_bridge *next;
> +};
> +
> +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct thc63_dev, bridge);
> +}
> +
> +static int thc63_attach(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> +
> + return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> +}
> +
> +static void thc63_enable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> + vcc = thc63->vccs[i];
> + if (!vcc)
> + continue;
> +
> + if (regulator_enable(vcc))
> + goto error_vcc_enable;
> + }
> +
> + if (thc63->pdwn)
> + gpiod_set_value(thc63->pdwn, 0);
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 1);
> +
> + return;
> +
> +error_vcc_enable:
> + dev_err(thc63->dev, "Failed to enable regulator %s\n",
> + thc63_reg_names[i]);
> +
> + for (i = i - 1; i >= 0; i--) {
> + vcc = thc63->vccs[i];
> + if (!vcc)
> + continue;
> +
> + regulator_disable(vcc);
> + }
> +}
> +
> +static void thc63_disable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + int i;
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 0);
> +
> + if (thc63->pdwn)
> + gpiod_set_value(thc63->pdwn, 1);
> +
> + for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
> + vcc = thc63->vccs[i];
> + if (!vcc)
> + continue;
> +
> + if (regulator_disable(vcc))
> + dev_dbg(thc63->dev,
> + "Failed to disable regulator %s\n",
> + thc63_reg_names[i]);
> + }
> +}
> +
> +struct drm_bridge_funcs thc63_bridge_func = {
> + .attach = thc63_attach,
> + .enable = thc63_enable,
> + .disable = thc63_disable,
> +};
> +
> +static int thc63_parse_dt(struct thc63_dev *thc63)
> 

Re: [PATCH v5 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch,

On 2018-03-15 17:11:54 +0100, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 

Reviewed-by: Niklas Söderlund 

> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> ++
>  1 file changed, 66 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..8225c6a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,66 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS 
> streams
> +to parallel data outputs. The chip supports single/dual input/output modes,
> +handling up to two two input LVDS stream and up to two digital CMOS/TTL 
> outputs.
> +
> +Single or dual operation modes, output data mapping and DDR output modes are
> +configured through input signals and the chip does not expose any control 
> bus.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024"
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry
> +- pdwn-gpios: Power down GPIO signal. Active low
> +- oe-gpios: Output enable GPIO signal. Active high
> +
> +The THC63LVD1024 video port connections are modeled according
> +to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
> +
> +Required video port nodes:
> +- Port@0: First LVDS input port
> +- Port@2: First digital CMOS/TTL parallel output
> +
> +Optional video port nodes:
> +- Port@1: Second LVDS input port
> +- Port@3: Second digital CMOS/TTL parallel output
> +
> +Example:
> +
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + vcc-supply = <_lvds_vcc>;
> + lvcc-supply = <_lvds_lvcc>;
> +
> + pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lvds_dec_in_0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + lvds_dec_out_2: endpoint {
> + remote-endpoint = <_in>;
> + };
> +
> + };
> +
> + };
> + };
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 00/20] Add multiplexed media pads to support CSI-2 virtual channels

[Niklas Söderlund]

Hi Todor,

On 2018-03-15 11:43:31 +0200, Todor Tomov wrote:
> Hello,
> 
> I'm trying to understand what is the current state of the multiple virtual
> channel support in V4L2 and Media framework. This is the last activity
> on this topic which I was able to find. Is anything new happened since
> this RFC, is someone working on this or planing to work on?

I'm currently working on this but right now I'm focusing on driver 
dependencies for my use-case, once that is done I will resume to push 
more for the multiplexed stream support. I randomly push my latest work 
to

git://git.ragnatech.se/linux v4l2/mux

But this is a unstable branch and contains some LOCAL patches to test my 
work on Renesas platforms. But if you want to checkout my current status 
that's the branch to check.

Out of curiosity what board or use-case are you interested in where 
multiplexed streams would be useful for you?

> 
> Best regards,
> Todor Tomov
> 
> On 11.08.2017 12:56, Niklas Söderlund wrote:
> > Hi,
> > 
> > This series is a RFC for how I think one could add CSI-2 virtual channel 
> > support to the V4L2 framework. The problem is that there is no way to in 
> > the media framework describe and control links between subdevices which 
> > carry more then one video stream, for example a CSI-2 bus which can have 
> > 4 virtual channels carrying different video streams.
> > 
> > This series adds a new pad flag which would indicate that a pad carries 
> > multiplexed streams, adds a new s_stream() operation to the pad 
> > operations structure which takes a new argument 'stream'. This new 
> > s_stream() operation then is both pad and stream aware. It also extends 
> > struct v4l2_mbus_frame_desc_entry with a new sub-struct to describe how 
> > a CSI-2 link multiplexes virtual channels. I also include one 
> > implementation based on Renesas R-Car which makes use of these patches 
> > as I think they help with understanding but they have no impact on the 
> > RFC feature itself.
> > 
> > The idea is that on both sides of the multiplexed media link there are 
> > one multiplexer subdevice and one demultiplexer subdevice. These two 
> > subdevices can't do any format conversions, there sole purpose is to 
> > (de)multiplex the CSI-2 link. If there is hardware which can do both 
> > CSI-2 multiplexing and format conversions they can be modeled as two 
> > subdevices from the same device driver and using the still pending 
> > incremental async mechanism to connect the external pads. The reason 
> > there is no format conversion is important as the multiplexed pads can't 
> > have a format in the current V4L2 model, get/set_fmt are not aware of 
> > streams.
> > 
> > +--+  +--+
> >  +---+  subdev 1   |  |  subdev 2   +---+
> >   +--+ Pad 1 | |  | | Pad 3 +---+
> >  +--++   +-+---+  +---+-+   ++--+
> > || Muxed pad A +--+ Muxed pad B ||
> >  +--++   +-+---+  +---+-+   ++--+
> >   +--+ Pad 2 | |  | | Pad 4 +---+
> >  +---+ |  | +---+
> > +--+  +--+
> > 
> > In the simple example above Pad 1 is routed to Pad 3 and Pad 2 to Pad 4, 
> > and the video data for both of them travels the link between pad A and 
> > B. One shortcoming of this RFC is that there currently are no way to 
> > express to user-space which pad is routed to which stream of the 
> > multiplexed link. But inside the kernel this is known and format 
> > validation is done by comparing the format of Pad 1 to Pad 3 and Pad 2 
> > to Pad 4 by the V4L2 framework. But it would be nice for the user to 
> > also be able to get this information while setting up the MC graph in 
> > user-space.
> > 
> > Obviously there are things that are not perfect in this RFC, one is the 
> > above mentioned lack of user-space visibility of that Pad 1 is in fact 
> > routed to Pad 3. Others are lack of Documentation/ work and I'm sure 
> > there are error path shortcuts which are not fully thought out. One big 
> > question is also if the s_stream() operation added to ops structure 
> > should be a compliment to the existing ones in video and audio ops or 
> > aim to replace the one in video ops. I'm also unsure of the CSI2 flag of 
> > struct v4l2_mbus_frame_desc_entry don't really belong in struct 
> > v4l2_mbus_frame_desc. And I'm sure there are lots of other stuff that's 
> > why this is a RFC...
> > 
> > A big thanks to Laurent and Sakari for being really nice and taking time 
> > helping me grasp all the possibilities and issues with this problem, all 
> > cred to them and all blame to me for misunderstanding there guidance :-)
> > 
> > This series based on the latest R-Car CSI-2 and VIN patches which can be 
> > found at [1], but that is a dependency 

Re: [Intel-gfx] [PATCH igt 3/8] lib/igt_gt: has_gpu_reset(): fix failed assertion on non-i915 platforms

[Ville Syrjälä]

On Thu, Mar 15, 2018 at 03:45:39PM +0100, Ulrich Hecht wrote:
> Checks if we have an i915 device before using intel_get_drm_devid().
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  lib/igt_gt.c | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/lib/igt_gt.c b/lib/igt_gt.c
> index e630550..9cb07c2 100644
> --- a/lib/igt_gt.c
> +++ b/lib/igt_gt.c

I would think igt_gt as a whole is pretty much i915 specific.
So feels to me like we should not have gotten this deep when
using another driver.

> @@ -59,14 +59,17 @@ static bool has_gpu_reset(int fd)
>   struct drm_i915_getparam gp;
>   int val = 0;
>  
> - memset(, 0, sizeof(gp));
> - gp.param = 35; /* HAS_GPU_RESET */
> - gp.value = 
> -
> - if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, ))
> - once = intel_gen(intel_get_drm_devid(fd)) >= 5;
> - else
> - once = val > 0;
> + if (is_i915_device(fd)) {
> + memset(, 0, sizeof(gp));
> + gp.param = 35; /* HAS_GPU_RESET */
> + gp.value = 
> +
> + if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, ))
> + once = intel_gen(intel_get_drm_devid(fd)) >= 5;
> + else
> + once = val > 0;
> + } else
> + once = 0;
>   }
>   return once;
>  }
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

Re: [Intel-gfx] [PATCH igt 6/8] lib/igt_pm: turn absence of autosuspend_delay_ms from fail to skip

[Ville Syrjälä]

On Thu, Mar 15, 2018 at 03:45:42PM +0100, Ulrich Hecht wrote:
> Fixes false negatives on everything that doesn't happen to be at a
> specific hard-coded sysfs path...
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  lib/igt_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> index 5bf5b2e..641157b 100644
> --- a/lib/igt_pm.c
> +++ b/lib/igt_pm.c
> @@ -262,7 +262,7 @@ bool igt_setup_runtime_pm(void)
>* suite goes faster and we have a higher probability of triggering race
>* conditions. */
>   fd = open(POWER_DIR "/autosuspend_delay_ms", O_WRONLY);

The hardocded path should probably go then.

igt_sysfs_path() + "/device/power" looks like it should dtrt.
Would need to plumb the fd down though. Hopefully every caller
has it handy.

> - igt_assert_f(fd >= 0,
> + igt_require_f(fd >= 0,
>"Can't open " POWER_DIR "/autosuspend_delay_ms\n");
>  
>   /* If we fail to write to the file, it means this system doesn't support
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

Re: [Intel-gfx] [PATCH igt 5/8] tests/kms_plane_lowres: skip i915-specific tests on other platforms

[Ville Syrjälä]

On Thu, Mar 15, 2018 at 03:45:41PM +0100, Ulrich Hecht wrote:
> Add is_i915_device() requirement to tests using Intel-specific APIs.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  tests/kms_plane_lowres.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/kms_plane_lowres.c b/tests/kms_plane_lowres.c
> index d1e4b3c..8fc7654 100644
> --- a/tests/kms_plane_lowres.c
> +++ b/tests/kms_plane_lowres.c
> @@ -270,6 +270,7 @@ run_tests_for_pipe(data_t *data, enum pipe pipe)
>   igt_skip_on(pipe >= data->display.n_pipes);
>  
>   igt_display_require_output_on_pipe(>display, pipe);
> + igt_require(is_i915_device(data->drm_fd));

What's the i915 specific thing here? The tiling formats? You should
still be able to do the linear tests.

We probably want to utilize https://patchwork.freedesktop.org/patch/210341/
to skip any test that is trying to use an unsupported modifier. Looks
like I didn't account for drivers that don't support blobifiers.
Shouldn't be too difficult to fix that up though.

>   }
>  
>   igt_subtest_f("pipe-%s-tiling-none",
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

Re: [git pull] clk: renesas: Updates for v4.17

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-03-15 02:27:33)
> Hi Stephen,
> 
> On Wed, Mar 14, 2018 at 10:43 PM, Stephen Boyd  wrote:
> 
> > Did you need to use clk_readl() or was it just copy-paste? I hope we can
> > get rid of that function at some point.
> 
> That's an oversight. I will get rid of them in the second pull request
> for v4.17.
> 

Awesome. Thanks.

Re: [PATCH v2 1/4] media: i2c: Copy mt9t112 soc_camera sensor driver

[jacopo mondi]

Hi Hans,

On Thu, Mar 15, 2018 at 08:30:21AM -0700, Hans Verkuil wrote:
> On 03/15/2018 07:38 AM, jacopo mondi wrote:
> > Hi Sakari,
> >thanks for looking into this!
> >
> > On Thu, Mar 15, 2018 at 01:35:34PM +0200, Sakari Ailus wrote:
> >> Hi Jacopo,
> >>
> >> I wonder if it'd make sense to just make all the changes to the driver and
> >> then have it reviewed; I'm not sure the old driver can be said to have been
> >> in a known-good state that'd be useful to compare against. I think you did
> >> that with another driver as well.
> >>
> >
> > Well, I understand this is still debated, and I see your point.
> > As far as I can tell the driver had been developed to work with SH4
> > Ecovec boards and there tested.
> >
> > I'm not sure I fully got you here though. Are you proposing to
> > squash my next patch that cleans up the driver into this one and
> > propose it as a completely new driver to be reviewed from scratch?
> >
> > In the two previous driver I touched in this "remove soc_camera"
> > journey (ov772x and tw9910) I have followed this same pattern: copy
> > the soc_camera driver without removing the existing one, and pile on
> > top my changes/cleanups in another patch. Then port the board code to
> > use the new sensor driver, and the new CEU driver as well.
> >
> > Also, how would you like to proceed here? Hans sent a pull request for
> > the series, should I go with incremental changes on top of this?
>
> I don't want to postpone this conversion. The i2c/mt9t112.c is bug-compatible
> with i2c/soc-camera/mt9t112.c which is good enough for me. Being able to
> remove soc-camera in the (hopefully very) near future is the most important
> thing here.
>
> Once Jacopo can actually test the sensor, then that's a good time to review
> the driver in more detail.
>
> This reminded me that I actually started testing this sensor a year
> ago (I bought the same sensor on ebay, I completely forgot about that!).
>
> My attempt is here:
>
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=mt9t112
>
> I never finished it because I had no documentation on the pinout and never
> got around to hooking my oscilloscope up to it to figure this out. I was
> testing this with the atmel-isc.c driver.
>
> This might be of some use to you, Jacopo, once you have the sensor.

Thanks for the info. I'll see what I can do. I don't have register
level document, and if the module is the same you have neither a
pinout description. This is going to be fun :/

I'll then refrain from sending more patches for this series/driver
until we cannot actually test the sensor, fixes apart, if any, of course.

Thanks
   j

>
> Regards,
>
>   Hans


signature.asc
Description: PGP signature

[PATCH v5 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

[Jacopo Mondi]

The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
decoder, connected to the on-chip LVDS encoder output on one side
and to HDMI encoder ADV7511w on the other one.

As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver is available, describe it in DT
as well.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 +++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..69f43b8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   thc63lvd1024_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   thc63lvd1024_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+
+   };
+
+   };
+   };
 };
 
  {
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
-   remote-endpoint = <_out>;
+   remote-endpoint = <_out_2>;
};
};
 
@@ -152,8 +179,8 @@
 
ports {
port@1 {
-   endpoint {
-   remote-endpoint = <_in>;
+   lvds0_out: endpoint {
+   remote-endpoint = <_in_0>;
};
};
};
-- 
2.7.4

[PATCH v5 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Jacopo Mondi]

Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/Kconfig|   6 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c | 257 ++
 3 files changed, 264 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a..5815a20 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -92,6 +92,12 @@ config DRM_SII9234
  It is an I2C driver, that detects connection of MHL bridge
  and starts encapsulation of HDMI signal.
 
+config DRM_THINE_THC63LVD1024
+   tristate "Thine THC63LVD1024 LVDS decoder bridge"
+   depends on OF
+   ---help---
+ Thine THC63LVD1024 LVDS/parallel converter driver.
+
 config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..36069a0
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+enum {
+   THC63_LVDS_IN0,
+   THC63_LVDS_IN1,
+   THC63_DIGITAL_OUT0,
+   THC63_DIGITAL_OUT1,
+};
+
+static const char * const thc63_reg_names[] = {
+   "vcc", "lvcc", "pvcc", "cvcc",
+};
+
+struct thc63_dev {
+   struct device *dev;
+
+   struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
+
+   struct gpio_desc *pdwn;
+   struct gpio_desc *oe;
+
+   struct drm_bridge bridge;
+   struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+
+   return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+   struct regulator *vcc;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
+   vcc = thc63->vccs[i];
+   if (!vcc)
+   continue;
+
+   if (regulator_enable(vcc))
+   goto error_vcc_enable;
+   }
+
+   if (thc63->pdwn)
+   gpiod_set_value(thc63->pdwn, 0);
+
+   if (thc63->oe)
+   gpiod_set_value(thc63->oe, 1);
+
+   return;
+
+error_vcc_enable:
+   dev_err(thc63->dev, "Failed to enable regulator %s\n",
+   thc63_reg_names[i]);
+
+   for (i = i - 1; i >= 0; i--) {
+   vcc = thc63->vccs[i];
+   if (!vcc)
+   continue;
+
+   regulator_disable(vcc);
+   }
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+   struct regulator *vcc;
+   int i;
+
+   if (thc63->oe)
+   gpiod_set_value(thc63->oe, 0);
+
+   if (thc63->pdwn)
+   gpiod_set_value(thc63->pdwn, 1);
+
+   for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
+   vcc = thc63->vccs[i];
+   if (!vcc)
+   continue;
+
+   if (regulator_disable(vcc))
+   dev_dbg(thc63->dev,
+   "Failed to disable regulator %s\n",
+   thc63_reg_names[i]);
+   }
+}
+
+struct drm_bridge_funcs thc63_bridge_func = {
+   .attach = thc63_attach,
+   .enable = thc63_enable,
+   .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+   struct device_node *thc63_out;
+   struct device_node *remote;
+   int ret = 0;
+
+   thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+ THC63_DIGITAL_OUT0, -1);
+   if (!thc63_out) {
+   

[PATCH v5 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Jacopo Mondi]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 ++
 1 file changed, 66 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..8225c6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,66 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL 
outputs.
+
+Single or dual operation modes, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry
+- pdwn-gpios: Power down GPIO signal. Active low
+- oe-gpios: Output enable GPIO signal. Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <_lvds_vcc>;
+   lvcc-supply = <_lvds_lvcc>;
+
+   pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   lvds_dec_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   lvds_dec_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+
+   };
+
+   };
+   };
-- 
2.7.4

[PATCH v5 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge

[Jacopo Mondi]

Hi,
   v5 with a few small changes compared to v4 and with Andrzej tag added to
all patches in the series.

I fixed punctuation in the bindings and added a statement to clarify
the chip does not expose any control bus but it is instead configured by input
signals.

Minor changes in the driver, with the regulator name printed out in error path
of enable/disable routines instead of its index.

Branch for testing available at
git://jmondi.org v3m/v4.16-rc3/lvds-bridge-v5

Thanks
   j

v4 -> v5:
- Fix punctuation in bindings documentation
- Add small statement to bindings document to clarify the chip has no
  control bus
- Print regulator name in enable/disable routines error path
- Add Andrzej Reviewed-by tag

v3 -> v4:
- Rename permutations of "pdwn" to just "pdwn" everywhere in the series
- Improve power enable/disable routines as suggested by Andrzej and Sergei
- Change "pdwn" gpio initialization to use the logical output level
- Change Kconfig description

v2 -> v3:
- Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific
-- Rework bindings to describe multiple input/output ports
-- Rename driver and remove "lvds-decoder" references
-- Rework Eagle DTS to use new bindings

v1 -> v2:
- Drop support for THC63LVD1024


Jacopo Mondi (3):
  dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
  drm: bridge: Add thc63lvd1024 LVDS decoder driver
  arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

 .../bindings/display/bridge/thine,thc63lvd1024.txt |  66 ++
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts |  33 ++-
 drivers/gpu/drm/bridge/Kconfig |   6 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c  | 257 +
 5 files changed, 360 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

--
2.7.4

Re: [PATCH v4 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[jacopo mondi]

Hi Andrzej,
thanks for your patience in reviewing this series

On Thu, Mar 15, 2018 at 02:37:00PM +0100, Andrzej Hajda wrote:
> On 15.03.2018 11:56, Jacopo Mondi wrote:
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output converter.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  drivers/gpu/drm/bridge/Kconfig|   6 +
> >  drivers/gpu/drm/bridge/Makefile   |   1 +
> >  drivers/gpu/drm/bridge/thc63lvd1024.c | 255 
> > ++
> >  3 files changed, 262 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3b99d5a..5815a20 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -92,6 +92,12 @@ config DRM_SII9234
> >   It is an I2C driver, that detects connection of MHL bridge
> >   and starts encapsulation of HDMI signal.
> >
> > +config DRM_THINE_THC63LVD1024
> > +   tristate "Thine THC63LVD1024 LVDS decoder bridge"
> > +   depends on OF
> > +   ---help---
> > + Thine THC63LVD1024 LVDS/parallel converter driver.
> > +
> >  config DRM_TOSHIBA_TC358767
> > tristate "Toshiba TC358767 eDP bridge"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index 373eb28..fd90b16 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> >  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> >  obj-$(CONFIG_DRM_SII902X) += sii902x.o
> >  obj-$(CONFIG_DRM_SII9234) += sii9234.o
> > +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> >  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> >  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> >  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > new file mode 100644
> > index 000..067f231
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -0,0 +1,255 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> > + *
> > + * Copyright (C) 2018 Jacopo Mondi 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +enum {
> > +   THC63_LVDS_IN0,
> > +   THC63_LVDS_IN1,
> > +   THC63_DIGITAL_OUT0,
> > +   THC63_DIGITAL_OUT1,
> > +};
> > +
> > +static const char * const thc63_reg_names[] = {
> > +   "vcc", "lvcc", "pvcc", "cvcc",
> > +};
> > +
> > +struct thc63_dev {
> > +   struct device *dev;
> > +
> > +   struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> > +
> > +   struct gpio_desc *pdwn;
> > +   struct gpio_desc *oe;
> > +
> > +   struct drm_bridge bridge;
> > +   struct drm_bridge *next;
> > +};
> > +
> > +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> > +{
> > +   return container_of(bridge, struct thc63_dev, bridge);
> > +}
> > +
> > +static int thc63_attach(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +
> > +   return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> > +}
> > +
> > +static void thc63_enable(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +   struct regulator *vcc;
> > +   int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > +   vcc = thc63->vccs[i];
> > +   if (!vcc)
> > +   continue;
> > +
> > +   if (regulator_enable(vcc))
> > +   goto error_vcc_enable;
> > +   }
> > +
> > +   if (thc63->pdwn)
> > +   gpiod_set_value(thc63->pdwn, 0);
> > +
> > +   if (thc63->oe)
> > +   gpiod_set_value(thc63->oe, 1);
> > +
> > +   return;
> > +
> > +error_vcc_enable:
> > +   dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
>
> It would be better to use supply or regulator name instead of index.
>

Yeah, now it's easy as I have the array with names in the driver
global scope...

> > +
> > +   for (i = i - 1; i >= 0; i--) {
> > +   vcc = thc63->vccs[i];
> > +   if (!vcc)
> > +   continue;
> > +
> > +   regulator_disable(vcc);
> > +   }
> > +}
> > +
> > +static void thc63_disable(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +   struct regulator *vcc;
> > +   int i;
> > +
> > +   if (thc63->oe)
> > +   gpiod_set_value(thc63->oe, 0);
> > +
> > +   if (thc63->pdwn)
> > +   gpiod_set_value(thc63->pdwn, 1);
> > +
> > +   for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
> > +   vcc = thc63->vccs[i];
> > +   if (!vcc)
> > +   continue;
> > +
> > +   if (regulator_disable(vcc))
> > +   dev_dbg(thc63->dev,
> 

[PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build

[Arnd Bergmann]

The *.dtb and *.dtb.S files get removed by 'make' during the build process,
and later seem to be missed during the 'modpost' stage:

rm drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb 
drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb 
drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb.S 
drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb.S 
drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S 
drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb 
drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb 
drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb 
drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb.S 
drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb.S
WARNING: could not open drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S: 
No such file or directory

As a workaround, this adds all those files to the 'extra-y' target list,
but that's really ugly. Any ideas for a better fix?

Fixes: 81c0e3dd8292 ("drm: rcar-du: Fix legacy DT to create LVDS encoder nodes")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/rcar-du/Makefile | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 3e58ed93d5b1..e5fc6ec0b8cc 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -12,6 +12,21 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)  += rcar_du_of.o \
   rcar_du_of_lvds_r8a7793.dtb.o \
   rcar_du_of_lvds_r8a7795.dtb.o \
   rcar_du_of_lvds_r8a7796.dtb.o
+
+extra-y+= rcar_du_of_lvds_r8a7790.dtb \
+  rcar_du_of_lvds_r8a7790.dtb \
+  rcar_du_of_lvds_r8a7791.dtb \
+  rcar_du_of_lvds_r8a7793.dtb \
+  rcar_du_of_lvds_r8a7795.dtb \
+  rcar_du_of_lvds_r8a7796.dtb
+
+extra-y+= 
rcar_du_of_lvds_r8a7790.dtb.S \
+  rcar_du_of_lvds_r8a7790.dtb.S \
+  rcar_du_of_lvds_r8a7791.dtb.S \
+  rcar_du_of_lvds_r8a7793.dtb.S \
+  rcar_du_of_lvds_r8a7795.dtb.S \
+  rcar_du_of_lvds_r8a7796.dtb.S
+
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
-- 
2.9.0

Re: [PATCH v2 1/4] media: i2c: Copy mt9t112 soc_camera sensor driver

[Hans Verkuil]

On 03/15/2018 07:38 AM, jacopo mondi wrote:
> Hi Sakari,
>thanks for looking into this!
> 
> On Thu, Mar 15, 2018 at 01:35:34PM +0200, Sakari Ailus wrote:
>> Hi Jacopo,
>>
>> I wonder if it'd make sense to just make all the changes to the driver and
>> then have it reviewed; I'm not sure the old driver can be said to have been
>> in a known-good state that'd be useful to compare against. I think you did
>> that with another driver as well.
>>
> 
> Well, I understand this is still debated, and I see your point.
> As far as I can tell the driver had been developed to work with SH4
> Ecovec boards and there tested.
> 
> I'm not sure I fully got you here though. Are you proposing to
> squash my next patch that cleans up the driver into this one and
> propose it as a completely new driver to be reviewed from scratch?
> 
> In the two previous driver I touched in this "remove soc_camera"
> journey (ov772x and tw9910) I have followed this same pattern: copy
> the soc_camera driver without removing the existing one, and pile on
> top my changes/cleanups in another patch. Then port the board code to
> use the new sensor driver, and the new CEU driver as well.
> 
> Also, how would you like to proceed here? Hans sent a pull request for
> the series, should I go with incremental changes on top of this?

I don't want to postpone this conversion. The i2c/mt9t112.c is bug-compatible
with i2c/soc-camera/mt9t112.c which is good enough for me. Being able to
remove soc-camera in the (hopefully very) near future is the most important
thing here.

Once Jacopo can actually test the sensor, then that's a good time to review
the driver in more detail.

This reminded me that I actually started testing this sensor a year
ago (I bought the same sensor on ebay, I completely forgot about that!).

My attempt is here:

https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=mt9t112

I never finished it because I had no documentation on the pinout and never
got around to hooking my oscilloscope up to it to figure this out. I was
testing this with the atmel-isc.c driver.

This might be of some use to you, Jacopo, once you have the sensor.

Regards,

Hans

[PATCH igt 7/8] tests/kms_addfb_basic: size_tests(): reduce test buffer size

[Ulrich Hecht]

Fixes fails on low-memory devices.

Signed-off-by: Ulrich Hecht 
---
 tests/kms_addfb_basic.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
index cf9ba37..d1da718 100644
--- a/tests/kms_addfb_basic.c
+++ b/tests/kms_addfb_basic.c
@@ -238,26 +238,26 @@ static void size_tests(int fd)
struct drm_mode_fb_cmd2 f_16 = {};
struct drm_mode_fb_cmd2 f_8 = {};
 
-   f.width = 1024;
-   f.height = 1024;
+   f.width = 512;
+   f.height = 512;
f.pixel_format = DRM_FORMAT_XRGB;
-   f.pitches[0] = 1024*4;
+   f.pitches[0] = 512*4;
 
-   f_16.width = 1024;
-   f_16.height = 1024*2;
+   f_16.width = 512;
+   f_16.height = 512*2;
f_16.pixel_format = DRM_FORMAT_RGB565;
-   f_16.pitches[0] = 1024*2;
+   f_16.pitches[0] = 512*2;
 
-   f_8.width = 1024*2;
-   f_8.height = 1024*2;
+   f_8.width = 512*2;
+   f_8.height = 512*2;
f_8.pixel_format = DRM_FORMAT_C8;
-   f_8.pitches[0] = 1024*2;
+   f_8.pitches[0] = 512*2;
 
igt_fixture {
-   gem_bo = igt_create_bo_with_dimensions(fd, 1024, 1024,
+   gem_bo = igt_create_bo_with_dimensions(fd, 512, 512,
DRM_FORMAT_XRGB, 0, 0, NULL, NULL, NULL);
igt_assert(gem_bo);
-   gem_bo_small = igt_create_bo_with_dimensions(fd, 1024, 1023,
+   gem_bo_small = igt_create_bo_with_dimensions(fd, 512, 511,
DRM_FORMAT_XRGB, 0, 0, NULL, NULL, NULL);
igt_assert(gem_bo_small);
}
@@ -311,7 +311,7 @@ static void size_tests(int fd)
}
 
/* Just to check that the parameters would work. */
-   f.height = 1020;
+   f.height = 510;
igt_subtest("small-bo") {
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, ) == 0);
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB, _id) == 0);
@@ -320,7 +320,7 @@ static void size_tests(int fd)
 
igt_subtest("bo-too-small-due-to-tiling") {
igt_require(is_i915_device(fd));
-   gem_set_tiling(fd, gem_bo_small, I915_TILING_X, 1024*4);
+   gem_set_tiling(fd, gem_bo_small, I915_TILING_X, 512*4);
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, ) == -1 &&
   errno == EINVAL);
}
-- 
2.7.4

[PATCH igt 1/8] tests/kms_addfb_basic: skip i915-specific tests on other platforms

[Ulrich Hecht]

Add is_i915_device() requirement to tests using Intel-specific APIs.

Signed-off-by: Ulrich Hecht 
---
 tests/kms_addfb_basic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
index 7d8852f..cf9ba37 100644
--- a/tests/kms_addfb_basic.c
+++ b/tests/kms_addfb_basic.c
@@ -104,6 +104,7 @@ static void invalid_tests(int fd)
}
 
igt_subtest("clobberred-modifier") {
+   igt_require(is_i915_device(fd));
f.flags = 0;
f.modifier[0] = 0;
gem_set_tiling(fd, gem_bo, I915_TILING_X, 512*4);
@@ -318,6 +319,7 @@ static void size_tests(int fd)
}
 
igt_subtest("bo-too-small-due-to-tiling") {
+   igt_require(is_i915_device(fd));
gem_set_tiling(fd, gem_bo_small, I915_TILING_X, 1024*4);
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, ) == -1 &&
   errno == EINVAL);
@@ -369,6 +371,7 @@ static void addfb25_tests(int fd)
 
igt_subtest_group {
igt_fixture {
+   igt_require(is_i915_device(fd));
gem_set_tiling(fd, gem_bo, I915_TILING_X, 1024*4);
igt_require_fb_modifiers(fd);
}
-- 
2.7.4

[PATCH igt 4/8] lib/igt_gt: check for presence of GPU reset before using it

[Ulrich Hecht]

Fixes failed assertion on non-i915 devices.

Signed-off-by: Ulrich Hecht 
---
 lib/igt_gt.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index 9cb07c2..825ea52 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -166,14 +166,15 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned 
flags)
struct drm_i915_gem_context_param param;
unsigned ban;
 
+   if (!igt_check_boolean_env_var("IGT_HANG_WITHOUT_RESET", false))
+   igt_require(has_gpu_reset(fd));
+
igt_assert(igt_sysfs_set_parameter
   (fd, "reset", "%d", INT_MAX /* any reset method */));
 
if (!igt_check_boolean_env_var("IGT_HANG", true))
igt_skip("hang injection disabled by user");
gem_context_require_bannable(fd);
-   if (!igt_check_boolean_env_var("IGT_HANG_WITHOUT_RESET", false))
-   igt_require(has_gpu_reset(fd));
 
param.ctx_id = ctx;
param.size = 0;
-- 
2.7.4

[PATCH igt 8/8] test/kms_addfb_basic: tolerate absence of 8-bit format

[Ulrich Hecht]

Ignores failure to add DRM_FORMAT_C8 frame buffer; some devices do not
support any 8-bit format.

Signed-off-by: Ulrich Hecht 
---
 tests/kms_addfb_basic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
index d1da718..db79827 100644
--- a/tests/kms_addfb_basic.c
+++ b/tests/kms_addfb_basic.c
@@ -273,8 +273,8 @@ static void size_tests(int fd)
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, _16) == 0);
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB, _16.fb_id) == 0);
f.fb_id = 0;
-   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, _8) == 0);
-   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB, _8.fb_id) == 0);
+   if (drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, _8) == 0)
+   igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB, 
_8.fb_id) == 0);
f.fb_id = 0;
}
 
-- 
2.7.4

[PATCH igt 2/8] tests/kms_panel_fitting: check for i915 before checking version

[Ulrich Hecht]

Fixes false negatives on non-i915 platforms.

Signed-off-by: Ulrich Hecht 
---
 tests/kms_panel_fitting.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/kms_panel_fitting.c b/tests/kms_panel_fitting.c
index b3cee22..6d0be50 100644
--- a/tests/kms_panel_fitting.c
+++ b/tests/kms_panel_fitting.c
@@ -243,6 +243,7 @@ static void test_atomic_fastset(igt_display_t *display)
igt_set_module_param_int("fastboot", 1);
 
igt_require(display->is_atomic);
+   igt_require(is_i915_device(display->drm_fd));
igt_require(intel_gen(intel_get_drm_devid(display->drm_fd)) >= 5);
 
for_each_pipe_with_valid_output(display, pipe, output) {
-- 
2.7.4

[PATCH igt 6/8] lib/igt_pm: turn absence of autosuspend_delay_ms from fail to skip

[Ulrich Hecht]

Fixes false negatives on everything that doesn't happen to be at a
specific hard-coded sysfs path...

Signed-off-by: Ulrich Hecht 
---
 lib/igt_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 5bf5b2e..641157b 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -262,7 +262,7 @@ bool igt_setup_runtime_pm(void)
 * suite goes faster and we have a higher probability of triggering race
 * conditions. */
fd = open(POWER_DIR "/autosuspend_delay_ms", O_WRONLY);
-   igt_assert_f(fd >= 0,
+   igt_require_f(fd >= 0,
 "Can't open " POWER_DIR "/autosuspend_delay_ms\n");
 
/* If we fail to write to the file, it means this system doesn't support
-- 
2.7.4

[PATCH igt 0/8] Non-Intel test suite fixes

[Ulrich Hecht]

Hi!

I have run the tests on a Renesas R-Car M3-W's DU device, and have found a
number of false negatives that mostly stem from use of Intel-specifics
without checking if that makes sense first. So here's a bunch of fixes for
those, hope they are generic enough for upstreaming.

CU
Uli


Ulrich Hecht (8):
  tests/kms_addfb_basic: skip i915-specific tests on other platforms
  tests/kms_panel_fitting: check for i915 before checking version
  lib/igt_gt: has_gpu_reset(): fix failed assertion on non-i915
platforms
  lib/igt_gt: check for presence of GPU reset before using it
  tests/kms_plane_lowres: skip i915-specific tests on other platforms
  lib/igt_pm: turn absence of autosuspend_delay_ms from fail to skip
  tests/kms_addfb_basic: size_tests(): reduce test buffer size
  test/kms_addfb_basic: tolerate absence of 8-bit format

 lib/igt_gt.c  | 24 ++--
 lib/igt_pm.c  |  2 +-
 tests/kms_addfb_basic.c   | 33 ++---
 tests/kms_panel_fitting.c |  1 +
 tests/kms_plane_lowres.c  |  1 +
 5 files changed, 35 insertions(+), 26 deletions(-)

-- 
2.7.4

[PATCH igt 5/8] tests/kms_plane_lowres: skip i915-specific tests on other platforms

[Ulrich Hecht]

Add is_i915_device() requirement to tests using Intel-specific APIs.

Signed-off-by: Ulrich Hecht 
---
 tests/kms_plane_lowres.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/kms_plane_lowres.c b/tests/kms_plane_lowres.c
index d1e4b3c..8fc7654 100644
--- a/tests/kms_plane_lowres.c
+++ b/tests/kms_plane_lowres.c
@@ -270,6 +270,7 @@ run_tests_for_pipe(data_t *data, enum pipe pipe)
igt_skip_on(pipe >= data->display.n_pipes);
 
igt_display_require_output_on_pipe(>display, pipe);
+   igt_require(is_i915_device(data->drm_fd));
}
 
igt_subtest_f("pipe-%s-tiling-none",
-- 
2.7.4

[PATCH igt 3/8] lib/igt_gt: has_gpu_reset(): fix failed assertion on non-i915 platforms

[Ulrich Hecht]

Checks if we have an i915 device before using intel_get_drm_devid().

Signed-off-by: Ulrich Hecht 
---
 lib/igt_gt.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index e630550..9cb07c2 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -59,14 +59,17 @@ static bool has_gpu_reset(int fd)
struct drm_i915_getparam gp;
int val = 0;
 
-   memset(, 0, sizeof(gp));
-   gp.param = 35; /* HAS_GPU_RESET */
-   gp.value = 
-
-   if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, ))
-   once = intel_gen(intel_get_drm_devid(fd)) >= 5;
-   else
-   once = val > 0;
+   if (is_i915_device(fd)) {
+   memset(, 0, sizeof(gp));
+   gp.param = 35; /* HAS_GPU_RESET */
+   gp.value = 
+
+   if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, ))
+   once = intel_gen(intel_get_drm_devid(fd)) >= 5;
+   else
+   once = val > 0;
+   } else
+   once = 0;
}
return once;
 }
-- 
2.7.4

Re: [PATCH v2 1/4] media: i2c: Copy mt9t112 soc_camera sensor driver

[jacopo mondi]

Hi Sakari,
   thanks for looking into this!

On Thu, Mar 15, 2018 at 01:35:34PM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> I wonder if it'd make sense to just make all the changes to the driver and
> then have it reviewed; I'm not sure the old driver can be said to have been
> in a known-good state that'd be useful to compare against. I think you did
> that with another driver as well.
>

Well, I understand this is still debated, and I see your point.
As far as I can tell the driver had been developed to work with SH4
Ecovec boards and there tested.

I'm not sure I fully got you here though. Are you proposing to
squash my next patch that cleans up the driver into this one and
propose it as a completely new driver to be reviewed from scratch?

In the two previous driver I touched in this "remove soc_camera"
journey (ov772x and tw9910) I have followed this same pattern: copy
the soc_camera driver without removing the existing one, and pile on
top my changes/cleanups in another patch. Then port the board code to
use the new sensor driver, and the new CEU driver as well.

Also, how would you like to proceed here? Hans sent a pull request for
the series, should I go with incremental changes on top of this?

> On Mon, Mar 12, 2018 at 02:43:02PM +0100, Jacopo Mondi wrote:
> > Copy the soc_camera based driver in v4l2 sensor driver directory.
> > This commit just copies the original file without modifying it.
> > No modification to KConfig and Makefile as soc_camera framework
> > dependencies need to be removed first in next commit.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  drivers/media/i2c/mt9t112.c | 1163 
> > +++
> >  1 file changed, 1163 insertions(+)
> >  create mode 100644 drivers/media/i2c/mt9t112.c
> >
> > diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
> > new file mode 100644
> > index 000..297d22e
> > --- /dev/null
> > +++ b/drivers/media/i2c/mt9t112.c
> > @@ -0,0 +1,1163 @@
> > +/*
> > + * mt9t112 Camera Driver
> > + *
> > + * Copyright (C) 2009 Renesas Solutions Corp.
> > + * Kuninori Morimoto 
> > + *
> > + * Based on ov772x driver, mt9m111 driver,
> > + *
> > + * Copyright (C) 2008 Kuninori Morimoto 
> > + * Copyright (C) 2008, Robert Jarzmik 
> > + * Copyright 2006-7 Jonathan Corbet 
> > + * Copyright (C) 2008 Magnus Damm
> > + * Copyright (C) 2008, Guennadi Liakhovetski 
> > + *
> > + * 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 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* you can check PLL/clock info */
> > +/* #define EXT_CLOCK 2400 */
> > +
> > +/
> > +   macro
> > +/
> > +/*
> > + * frame size
> > + */
> > +#define MAX_WIDTH   2048
> > +#define MAX_HEIGHT  1536
> > +
> > +/*
> > + * macro of read/write
> > + */
> > +#define ECHECKER(ret, x)   \
> > +   do {\
> > +   (ret) = (x);\
> > +   if ((ret) < 0)  \
> > +   return (ret);   \
>
> I think the code would be easier to follow without macros like this one.
>

Yes, I agree, but again, not my code and already in mainline, so I
felt uncomfortable chopping away pieces with an axe just because "I didn't
like it". But if we're going for a major review I can be a bit more
aggressive and address your comments.

> > +   } while (0)
> > +
> > +#define mt9t112_reg_write(ret, client, a, b) \
> > +   ECHECKER(ret, __mt9t112_reg_write(client, a, b))
> > +#define mt9t112_mcu_write(ret, client, a, b) \
> > +   ECHECKER(ret, __mt9t112_mcu_write(client, a, b))
> > +
> > +#define mt9t112_reg_mask_set(ret, client, a, b, c) \
> > +   ECHECKER(ret, __mt9t112_reg_mask_set(client, a, b, c))
> > +#define mt9t112_mcu_mask_set(ret, client, a, b, c) \
> > +   ECHECKER(ret, __mt9t112_mcu_mask_set(client, a, b, c))
> > +
> > +#define mt9t112_reg_read(ret, client, a) \
> > +   ECHECKER(ret, __mt9t112_reg_read(client, a))
> > +
> > +/*
> > + * Logical address
> > + */
> > +#define _VAR(id, offset, base) (base | (id & 0x1f) << 10 | (offset & 
> > 0x3ff))
> > +#define VAR(id, offset)  _VAR(id, offset, 0x)
> > +#define VAR8(id, offset) _VAR(id, offset, 0x8000)
> > +
> > +/
> > +   struct
> > +/
> > +struct mt9t112_format {
> > 

Re: [PATCH v4 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

[Andrzej Hajda]

On 15.03.2018 11:56, Jacopo Mondi wrote:
> The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
> decoder, connected to the on-chip LVDS encoder output on one side
> and to HDMI encoder ADV7511w on the other one.
>
> As the decoder does not need any configuration it has been so-far
> omitted from DTS. Now that a driver is available, describe it in DT
> as well.
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej
> ---
>  arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 
> +++---
>  1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
> b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> index c0fd144..69f43b8 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> @@ -42,6 +42,33 @@
>   };
>   };
>   };
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + thc63lvd1024_in_0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + thc63lvd1024_out_2: endpoint {
> + remote-endpoint = <_in>;
> + };
> +
> + };
> +
> + };
> + };
>  };
>  
>   {
> @@ -98,7 +125,7 @@
>   port@0 {
>   reg = <0>;
>   adv7511_in: endpoint {
> - remote-endpoint = <_out>;
> + remote-endpoint = <_out_2>;
>   };
>   };
>  
> @@ -152,8 +179,8 @@
>  
>   ports {
>   port@1 {
> - endpoint {
> - remote-endpoint = <_in>;
> + lvds0_out: endpoint {
> + remote-endpoint = <_in_0>;
>   };
>   };
>   };

Re: [PATCH v4 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Andrzej Hajda]

On 15.03.2018 11:56, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output converter.
>
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/gpu/drm/bridge/Kconfig|   6 +
>  drivers/gpu/drm/bridge/Makefile   |   1 +
>  drivers/gpu/drm/bridge/thc63lvd1024.c | 255 
> ++
>  3 files changed, 262 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3b99d5a..5815a20 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -92,6 +92,12 @@ config DRM_SII9234
> It is an I2C driver, that detects connection of MHL bridge
> and starts encapsulation of HDMI signal.
>  
> +config DRM_THINE_THC63LVD1024
> + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> + depends on OF
> + ---help---
> +   Thine THC63LVD1024 LVDS/parallel converter driver.
> +
>  config DRM_TOSHIBA_TC358767
>   tristate "Toshiba TC358767 eDP bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 373eb28..fd90b16 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>  obj-$(CONFIG_DRM_SII9234) += sii9234.o
> +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> new file mode 100644
> index 000..067f231
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -0,0 +1,255 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> + *
> + * Copyright (C) 2018 Jacopo Mondi 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +enum {
> + THC63_LVDS_IN0,
> + THC63_LVDS_IN1,
> + THC63_DIGITAL_OUT0,
> + THC63_DIGITAL_OUT1,
> +};
> +
> +static const char * const thc63_reg_names[] = {
> + "vcc", "lvcc", "pvcc", "cvcc",
> +};
> +
> +struct thc63_dev {
> + struct device *dev;
> +
> + struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> +
> + struct gpio_desc *pdwn;
> + struct gpio_desc *oe;
> +
> + struct drm_bridge bridge;
> + struct drm_bridge *next;
> +};
> +
> +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct thc63_dev, bridge);
> +}
> +
> +static int thc63_attach(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> +
> + return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> +}
> +
> +static void thc63_enable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> + vcc = thc63->vccs[i];
> + if (!vcc)
> + continue;
> +
> + if (regulator_enable(vcc))
> + goto error_vcc_enable;
> + }
> +
> + if (thc63->pdwn)
> + gpiod_set_value(thc63->pdwn, 0);
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 1);
> +
> + return;
> +
> +error_vcc_enable:
> + dev_err(thc63->dev, "Failed to enable regulator %u\n", i);

It would be better to use supply or regulator name instead of index.

> +
> + for (i = i - 1; i >= 0; i--) {
> + vcc = thc63->vccs[i];
> + if (!vcc)
> + continue;
> +
> + regulator_disable(vcc);
> + }
> +}
> +
> +static void thc63_disable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + int i;
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 0);
> +
> + if (thc63->pdwn)
> + gpiod_set_value(thc63->pdwn, 1);
> +
> + for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
> + vcc = thc63->vccs[i];
> + if (!vcc)
> + continue;
> +
> + if (regulator_disable(vcc))
> + dev_dbg(thc63->dev,
> + "Failed to disable regulator %u\n", i);

ditto

> + }
> +}
> +
> +struct drm_bridge_funcs thc63_bridge_func = {
> + .attach = thc63_attach,
> + .enable = thc63_enable,
> + .disable = thc63_disable,
> +};
> +
> +static int thc63_parse_dt(struct thc63_dev *thc63)
> +{
> + struct device_node *thc63_out;
> + struct device_node *remote;
> + int ret = 0;
> +

Re: [PATCH v4 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Andrzej Hajda]

On 15.03.2018 11:56, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi 
> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 63 
> ++
>  1 file changed, 63 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..0936bde
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,63 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS 
> streams
> +to parallel data outputs. The chip supports single/dual input/output modes,
> +handling up to two two input LVDS stream and up to two digital CMOS/TTL 
> outputs.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024",
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry
> +- pdwn-gpios: Power down GPIO signal. Active low.
> +- oe-gpios: Output enable GPIO signal. Active high.

Nitpick: different lines ends differently: period, dot, nothing.
Another thing if there will be next iteration it would be good to
emphasize converter has no control bus.
Anyway:

Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

> +
> +The THC63LVD1024 video port connections are modeled according
> +to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
> +
> +Required video port nodes:
> +- Port@0: First LVDS input port
> +- Port@2: First digital CMOS/TTL parallel output
> +
> +Optional video port nodes:
> +- Port@1: Second LVDS input port
> +- Port@3: Second digital CMOS/TTL parallel output
> +
> +Example:
> +
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + vcc-supply = <_lvds_vcc>;
> + lvcc-supply = <_lvds_lvcc>;
> +
> + pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lvds_dec_in_0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + lvds_dec_out_2: endpoint {
> + remote-endpoint = <_in>;
> + };
> +
> + };
> +
> + };
> + };

Re: [PATCH] dt-bindings: media: rcar_vin: Use status "okay"

[Sakari Ailus]

On Fri, Mar 09, 2018 at 10:34:40AM +0100, Geert Uytterhoeven wrote:
> According to the Devicetree Specification, "ok" is not a valid status.
> 
> Fixes: 47c71bd61b772cd7 ("[media] rcar_vin: add devicetree support")
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Sakari Ailus 

There are a few other matches, too, it'd be nice to fix them as well:

$ git grep 'status.*"ok"' -- Documentation/devicetree/bindings/
Documentation/devicetree/bindings/ata/apm-xgene.txt:- status: Shall 
be "ok" if enabled or "disabled" if disabled.
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt: status 
= "ok";
Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt:   status = "ok";
Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt:   status = "ok";
Documentation/devicetree/bindings/media/rcar_vin.txt:status = "ok";
Documentation/devicetree/bindings/media/rcar_vin.txt:status = "ok";
Documentation/devicetree/bindings/net/apm-xgene-enet.txt:- status: Should be 
"ok" or "disabled" for enabled/disabled. Default is "ok".
Documentation/devicetree/bindings/net/apm-xgene-enet.txt:   status 
= "ok";
Documentation/devicetree/bindings/net/apm-xgene-enet.txt:status = "ok";
Documentation/devicetree/bindings/pci/hisilicon-pcie.txt:- status: Either "ok" 
or "disabled".
Documentation/devicetree/bindings/pci/xgene-pci.txt:- status: Either "ok" or 
"disabled".
Documentation/devicetree/bindings/pci/xgene-pci.txt:status = "ok";
Documentation/devicetree/bindings/phy/apm-xgene-phy.txt:- status
: Shall be "ok" if enabled or "disabled" if disabled.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2 1/4] media: i2c: Copy mt9t112 soc_camera sensor driver

[Sakari Ailus]

Hi Jacopo,

I wonder if it'd make sense to just make all the changes to the driver and
then have it reviewed; I'm not sure the old driver can be said to have been
in a known-good state that'd be useful to compare against. I think you did
that with another driver as well.

On Mon, Mar 12, 2018 at 02:43:02PM +0100, Jacopo Mondi wrote:
> Copy the soc_camera based driver in v4l2 sensor driver directory.
> This commit just copies the original file without modifying it.
> No modification to KConfig and Makefile as soc_camera framework
> dependencies need to be removed first in next commit.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/i2c/mt9t112.c | 1163 
> +++
>  1 file changed, 1163 insertions(+)
>  create mode 100644 drivers/media/i2c/mt9t112.c
> 
> diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
> new file mode 100644
> index 000..297d22e
> --- /dev/null
> +++ b/drivers/media/i2c/mt9t112.c
> @@ -0,0 +1,1163 @@
> +/*
> + * mt9t112 Camera Driver
> + *
> + * Copyright (C) 2009 Renesas Solutions Corp.
> + * Kuninori Morimoto 
> + *
> + * Based on ov772x driver, mt9m111 driver,
> + *
> + * Copyright (C) 2008 Kuninori Morimoto 
> + * Copyright (C) 2008, Robert Jarzmik 
> + * Copyright 2006-7 Jonathan Corbet 
> + * Copyright (C) 2008 Magnus Damm
> + * Copyright (C) 2008, Guennadi Liakhovetski 
> + *
> + * 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 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* you can check PLL/clock info */
> +/* #define EXT_CLOCK 2400 */
> +
> +/
> + macro
> +/
> +/*
> + * frame size
> + */
> +#define MAX_WIDTH   2048
> +#define MAX_HEIGHT  1536
> +
> +/*
> + * macro of read/write
> + */
> +#define ECHECKER(ret, x) \
> + do {\
> + (ret) = (x);\
> + if ((ret) < 0)  \
> + return (ret);   \

I think the code would be easier to follow without macros like this one.

> + } while (0)
> +
> +#define mt9t112_reg_write(ret, client, a, b) \
> + ECHECKER(ret, __mt9t112_reg_write(client, a, b))
> +#define mt9t112_mcu_write(ret, client, a, b) \
> + ECHECKER(ret, __mt9t112_mcu_write(client, a, b))
> +
> +#define mt9t112_reg_mask_set(ret, client, a, b, c) \
> + ECHECKER(ret, __mt9t112_reg_mask_set(client, a, b, c))
> +#define mt9t112_mcu_mask_set(ret, client, a, b, c) \
> + ECHECKER(ret, __mt9t112_mcu_mask_set(client, a, b, c))
> +
> +#define mt9t112_reg_read(ret, client, a) \
> + ECHECKER(ret, __mt9t112_reg_read(client, a))
> +
> +/*
> + * Logical address
> + */
> +#define _VAR(id, offset, base)   (base | (id & 0x1f) << 10 | (offset & 
> 0x3ff))
> +#define VAR(id, offset)  _VAR(id, offset, 0x)
> +#define VAR8(id, offset) _VAR(id, offset, 0x8000)
> +
> +/
> + struct
> +/
> +struct mt9t112_format {
> + u32 code;
> + enum v4l2_colorspace colorspace;
> + u16 fmt;
> + u16 order;
> +};
> +
> +struct mt9t112_priv {
> + struct v4l2_subdev   subdev;
> + struct mt9t112_camera_info  *info;
> + struct i2c_client   *client;
> + struct v4l2_rect frame;
> + struct v4l2_clk *clk;
> + const struct mt9t112_format *format;
> + int  num_formats;
> + u32  flags;
> +/* for flags */
> +#define INIT_DONE(1 << 0)
> +#define PCLK_RISING  (1 << 1)
> +};
> +
> +/
> + supported format
> +/
> +
> +static const struct mt9t112_format mt9t112_cfmts[] = {
> + {
> + .code   = MEDIA_BUS_FMT_UYVY8_2X8,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> + .fmt= 1,
> + .order  = 0,
> + }, {
> + .code   = MEDIA_BUS_FMT_VYUY8_2X8,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> + .fmt= 1,
> + .order  = 1,
> + }, {
> + .code   = MEDIA_BUS_FMT_YUYV8_2X8,
> + .colorspace

[PATCH v4 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

[Jacopo Mondi]

The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
decoder, connected to the on-chip LVDS encoder output on one side
and to HDMI encoder ADV7511w on the other one.

As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver is available, describe it in DT
as well.

Signed-off-by: Jacopo Mondi 
---
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 +++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..69f43b8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   thc63lvd1024_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   thc63lvd1024_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+
+   };
+
+   };
+   };
 };
 
  {
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
-   remote-endpoint = <_out>;
+   remote-endpoint = <_out_2>;
};
};
 
@@ -152,8 +179,8 @@
 
ports {
port@1 {
-   endpoint {
-   remote-endpoint = <_in>;
+   lvds0_out: endpoint {
+   remote-endpoint = <_in_0>;
};
};
};
-- 
2.7.4

[PATCH v4 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Jacopo Mondi]

Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/bridge/Kconfig|   6 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c | 255 ++
 3 files changed, 262 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a..5815a20 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -92,6 +92,12 @@ config DRM_SII9234
  It is an I2C driver, that detects connection of MHL bridge
  and starts encapsulation of HDMI signal.
 
+config DRM_THINE_THC63LVD1024
+   tristate "Thine THC63LVD1024 LVDS decoder bridge"
+   depends on OF
+   ---help---
+ Thine THC63LVD1024 LVDS/parallel converter driver.
+
 config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..067f231
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+enum {
+   THC63_LVDS_IN0,
+   THC63_LVDS_IN1,
+   THC63_DIGITAL_OUT0,
+   THC63_DIGITAL_OUT1,
+};
+
+static const char * const thc63_reg_names[] = {
+   "vcc", "lvcc", "pvcc", "cvcc",
+};
+
+struct thc63_dev {
+   struct device *dev;
+
+   struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
+
+   struct gpio_desc *pdwn;
+   struct gpio_desc *oe;
+
+   struct drm_bridge bridge;
+   struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+
+   return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+   struct regulator *vcc;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
+   vcc = thc63->vccs[i];
+   if (!vcc)
+   continue;
+
+   if (regulator_enable(vcc))
+   goto error_vcc_enable;
+   }
+
+   if (thc63->pdwn)
+   gpiod_set_value(thc63->pdwn, 0);
+
+   if (thc63->oe)
+   gpiod_set_value(thc63->oe, 1);
+
+   return;
+
+error_vcc_enable:
+   dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
+
+   for (i = i - 1; i >= 0; i--) {
+   vcc = thc63->vccs[i];
+   if (!vcc)
+   continue;
+
+   regulator_disable(vcc);
+   }
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+   struct regulator *vcc;
+   int i;
+
+   if (thc63->oe)
+   gpiod_set_value(thc63->oe, 0);
+
+   if (thc63->pdwn)
+   gpiod_set_value(thc63->pdwn, 1);
+
+   for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
+   vcc = thc63->vccs[i];
+   if (!vcc)
+   continue;
+
+   if (regulator_disable(vcc))
+   dev_dbg(thc63->dev,
+   "Failed to disable regulator %u\n", i);
+   }
+}
+
+struct drm_bridge_funcs thc63_bridge_func = {
+   .attach = thc63_attach,
+   .enable = thc63_enable,
+   .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+   struct device_node *thc63_out;
+   struct device_node *remote;
+   int ret = 0;
+
+   thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+ THC63_DIGITAL_OUT0, -1);
+   if (!thc63_out) {
+   dev_err(thc63->dev, "Missing endpoint in Port@%u\n",
+   THC63_DIGITAL_OUT0);
+   return -ENODEV;
+  

[PATCH v4 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Jacopo Mondi]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt | 63 ++
 1 file changed, 63 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..0936bde
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,63 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL 
outputs.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024",
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry
+- pdwn-gpios: Power down GPIO signal. Active low.
+- oe-gpios: Output enable GPIO signal. Active high.
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <_lvds_vcc>;
+   lvcc-supply = <_lvds_lvcc>;
+
+   pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   lvds_dec_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   lvds_dec_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+
+   };
+
+   };
+   };
-- 
2.7.4

[PATCH v4 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge

[Jacopo Mondi]

Hello,
   this new version fixes comments received from Andrzej and Sergei on the
preceding v3.

Mostly, I cleaned up the mess with the powerdown GPIO names, and I'm now using
pdwn everywhere. The regulator enabling routine has been improved as suggested
by Sergei and Andrzej and I've changed Kconfig symbol documentation for
consistency with other ones. Also, fix gpio initialization to comply with the
APIs that work on logical level even at gpio request time.

Branch for testing available at
git://jmondi.org v3m/v4.16-rc3/lvds-bridge-v4

Thanks
   j

v3 -> v4:
- Rename permutations of "pdwn" to just "pdwn" everywhere in the series
- Improve power enable/disable routines as suggested by Andrzej and Sergei
- Change "pdwn" gpio initialization to use the logical output level
- Change Kconfig description

v2 -> v3:
- Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific
-- Rework bindings to describe multiple input/output ports
-- Rename driver and remove "lvds-decoder" references
-- Rework Eagle DTS to use new bindings

v1 -> v2:
- Drop support for THC63LVD1024

Jacopo Mondi (3):
  dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
  drm: bridge: Add thc63lvd1024 LVDS decoder driver
  arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

 .../bindings/display/bridge/thine,thc63lvd1024.txt |  63 +
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts |  33 ++-
 drivers/gpu/drm/bridge/Kconfig |   6 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c  | 255 +
 5 files changed, 355 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

--
2.7.4

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[jacopo mondi]

HI Andrezej,

On Thu, Mar 15, 2018 at 10:44:42AM +0100, Andrzej Hajda wrote:
> On 14.03.2018 11:09, jacopo mondi wrote:
> > Hi Andrzej,
> > thanks for review
> >
> > On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote:
> >> On 13.03.2018 15:30, Jacopo Mondi wrote:
> >>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> >>> output decoder.
> >> IMO converter suits here better, but it is just suggestion.
> >>
> >>> Signed-off-by: Jacopo Mondi 
> >>> ---
> >>>  drivers/gpu/drm/bridge/Kconfig|   7 +
> >>>  drivers/gpu/drm/bridge/Makefile   |   1 +
> >>>  drivers/gpu/drm/bridge/thc63lvd1024.c | 241 
> >>> ++
> >>>  3 files changed, 249 insertions(+)
> >>>  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/Kconfig 
> >>> b/drivers/gpu/drm/bridge/Kconfig
> >>> index 3b99d5a..facf6bd 100644
> >>> --- a/drivers/gpu/drm/bridge/Kconfig
> >>> +++ b/drivers/gpu/drm/bridge/Kconfig
> >>> @@ -92,6 +92,13 @@ config DRM_SII9234
> >>> It is an I2C driver, that detects connection of MHL bridge
> >>> and starts encapsulation of HDMI signal.
> >>>
> >>> +config DRM_THINE_THC63LVD1024
> >>> + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> >>> + depends on OF
> >>> + select DRM_PANEL_BRIDGE
> >> You don't use PANEL_BRIDGE, it should be possible to drop the select.
> >>
> > Ack
> >
> >>> + ---help---
> >>> +   Thine THC63LVD1024 LVDS decoder bridge driver.
> >> Decoder to what?
> >> Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
> >> converter or bridge.
> > "LVDS to digital CMOS/TTL parallel data converter" as the manual
> > describes the chip?
>
> Should work, unless we want some consistency in interface names, we have
> already: parallel / DPI / RGB. I am little bit confused about relations
> between them so I do not want to enforce any.

config DRM_THINE_THC63LVD1024
tristate "Thine THC63LVD1024 LVDS decoder bridge"
depends on OF
---help---
  Thine THC63LVD1024 LVDS/parallel converter driver.

I guess this is consistent with other symbol descriptions I found

>

[snip]
>
> >>> +
> >>> +static int thc63_gpio_init(struct thc63_dev *thc63)
> >>> +{
> >>> + thc63->pwdn = devm_gpiod_get_optional(thc63->dev, "pwdn",
> >>> +   GPIOD_OUT_LOW);
> >> Shouldn't be GPIOD_OUT_HIGH - bridge initially disabled?
> > No, the PWDN gpio is active low, it puts the chip in power down mode
> > when the physical line level is set to 0.
> >
> > That's another confusing thing, when requesting the GPIO, the actual
> > physical line value has to be provided, while when "set_value()" the
> > logical one is requested, iirc.
>
> I think it is opposite, only *raw* functions uses physical level. Other
> uses logical level.
>
> >
> > Being the GPIO defined as active low, in power enable we set it to
> > "logical inactive" == "physical 1", while during power disable it has
> > to be set to "logical active" == "physical 0"
> >
> > Not the right place to complain here, but imo that's not consistent.
> > Or have I misinterpreted the APIs? I cannot do much test, as in my setup
> > the PWDN pin is hardwired to +vcc (through a physical switch, not
> > controlled through a GPIO though).
>
> devm_gpiod_get_optional calls (indirectly) gpiod_configure_flags, which
> calls gpiod_direction_output which uses logical levels.

I clearly mis-interpreted the APIs.

I'll fix and I'm sending v4 out shortly.

Thanks
   j

>
> Regards
> Andrzej
>
> >
> > Thanks
> >j
> >
> >> Regards
> >> Andrzej
> >>> + if (IS_ERR(thc63->pwdn)) {
> >>> + dev_err(thc63->dev, "Unable to get GPIO \"pwdn\"\n");
> >>> + return PTR_ERR(thc63->pwdn);
> >>> + }
> >>> +
> >>> + thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
> >>> + if (IS_ERR(thc63->oe)) {
> >>> + dev_err(thc63->dev, "Unable to get GPIO \"oe\"\n");
> >>> + return PTR_ERR(thc63->oe);
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int thc63_regulator_init(struct thc63_dev *thc63)
> >>> +{
> >>> + struct regulator **reg;
> >>> + int i;
> >>> +
> >>> + reg = >vccs[0];
> >>> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++, reg++) {
> >>> + *reg = devm_regulator_get_optional(thc63->dev,
> >>> +thc63_reg_names[i]);
> >>> + if (IS_ERR(*reg)) {
> >>> + if (PTR_ERR(*reg) == -EPROBE_DEFER)
> >>> + return -EPROBE_DEFER;
> >>> + *reg = NULL;
> >>> + }
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int thc63_probe(struct platform_device *pdev)
> >>> +{
> >>> + struct thc63_dev *thc63;
> >>> + int ret;
> >>> +
> >>> + thc63 = devm_kzalloc(>dev, sizeof(*thc63), GFP_KERNEL);
> >>> + if (!thc63)
> >>> + return -ENOMEM;
> >>> +
> >>> + thc63->dev = >dev;
> >>> + 

Re: [PATCH] mmc: renesas_sdhi: fix WP detection

[Ulf Hansson]

On 5 March 2018 at 21:48, Wolfram Sang  wrote:
> Commit "mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of
> TMIO own flag" activated MMC_CAP2_NO_WRITE_PROTECT for Renesas SDHI
> which incorrectly disabled WP altogether instead of only disabling the
> internal mechanism. Since the whole WP handling has been reworked, we
> can simply disable this capability to re-enable WP GPIOs.
>
> Signed-off-by: Wolfram Sang 

Thanks, applied for next!

Kind regards
Uffe

> ---
>
> More testing revealed this. This time, I don't think squashing makes sense but
> I am open to discussion here.
>
>  drivers/mmc/host/renesas_sdhi_internal_dmac.c | 1 -
>  drivers/mmc/host/renesas_sdhi_sys_dmac.c  | 3 ---
>  2 files changed, 4 deletions(-)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> index a04f31fea72fd1..8e0acd197c43c0 100644
> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> @@ -75,7 +75,6 @@ static const struct renesas_sdhi_of_data 
> of_rcar_gen3_compatible = {
>   TMIO_MMC_HAVE_CBSY | TMIO_MMC_MIN_RCAR2,
> .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
>   MMC_CAP_CMD23,
> -   .capabilities2  = MMC_CAP2_NO_WRITE_PROTECT,
> .bus_shift  = 2,
> .scc_offset = 0x1000,
> .taps   = rcar_gen3_scc_taps,
> diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> index 4bb46c489d71f8..848e50c1638aa6 100644
> --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> @@ -42,7 +42,6 @@ static const struct renesas_sdhi_of_data of_rz_compatible = 
> {
>  static const struct renesas_sdhi_of_data of_rcar_gen1_compatible = {
> .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_CLK_ACTUAL,
> .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
> -   .capabilities2  = MMC_CAP2_NO_WRITE_PROTECT,
>  };
>
>  /* Definitions for sampling clocks */
> @@ -62,7 +61,6 @@ static const struct renesas_sdhi_of_data 
> of_rcar_gen2_compatible = {
>   TMIO_MMC_HAVE_CBSY | TMIO_MMC_MIN_RCAR2,
> .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
>   MMC_CAP_CMD23,
> -   .capabilities2  = MMC_CAP2_NO_WRITE_PROTECT,
> .dma_buswidth   = DMA_SLAVE_BUSWIDTH_4_BYTES,
> .dma_rx_offset  = 0x2000,
> .scc_offset = 0x0300,
> @@ -83,7 +81,6 @@ static const struct renesas_sdhi_of_data 
> of_rcar_gen3_compatible = {
>   TMIO_MMC_HAVE_CBSY | TMIO_MMC_MIN_RCAR2,
> .capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
>   MMC_CAP_CMD23,
> -   .capabilities2  = MMC_CAP2_NO_WRITE_PROTECT,
> .bus_shift  = 2,
> .scc_offset = 0x1000,
> .taps   = rcar_gen3_scc_taps,
> --
> 2.11.0
>

Re: [PATCH 00/20] Add multiplexed media pads to support CSI-2 virtual channels

[Todor Tomov]

Hello,

I'm trying to understand what is the current state of the multiple virtual
channel support in V4L2 and Media framework. This is the last activity
on this topic which I was able to find. Is anything new happened since
this RFC, is someone working on this or planing to work on?

Best regards,
Todor Tomov

On 11.08.2017 12:56, Niklas Söderlund wrote:
> Hi,
> 
> This series is a RFC for how I think one could add CSI-2 virtual channel 
> support to the V4L2 framework. The problem is that there is no way to in 
> the media framework describe and control links between subdevices which 
> carry more then one video stream, for example a CSI-2 bus which can have 
> 4 virtual channels carrying different video streams.
> 
> This series adds a new pad flag which would indicate that a pad carries 
> multiplexed streams, adds a new s_stream() operation to the pad 
> operations structure which takes a new argument 'stream'. This new 
> s_stream() operation then is both pad and stream aware. It also extends 
> struct v4l2_mbus_frame_desc_entry with a new sub-struct to describe how 
> a CSI-2 link multiplexes virtual channels. I also include one 
> implementation based on Renesas R-Car which makes use of these patches 
> as I think they help with understanding but they have no impact on the 
> RFC feature itself.
> 
> The idea is that on both sides of the multiplexed media link there are 
> one multiplexer subdevice and one demultiplexer subdevice. These two 
> subdevices can't do any format conversions, there sole purpose is to 
> (de)multiplex the CSI-2 link. If there is hardware which can do both 
> CSI-2 multiplexing and format conversions they can be modeled as two 
> subdevices from the same device driver and using the still pending 
> incremental async mechanism to connect the external pads. The reason 
> there is no format conversion is important as the multiplexed pads can't 
> have a format in the current V4L2 model, get/set_fmt are not aware of 
> streams.
> 
> +--+  +--+
>  +---+  subdev 1   |  |  subdev 2   +---+
>   +--+ Pad 1 | |  | | Pad 3 +---+
>  +--++   +-+---+  +---+-+   ++--+
> || Muxed pad A +--+ Muxed pad B ||
>  +--++   +-+---+  +---+-+   ++--+
>   +--+ Pad 2 | |  | | Pad 4 +---+
>  +---+ |  | +---+
> +--+  +--+
> 
> In the simple example above Pad 1 is routed to Pad 3 and Pad 2 to Pad 4, 
> and the video data for both of them travels the link between pad A and 
> B. One shortcoming of this RFC is that there currently are no way to 
> express to user-space which pad is routed to which stream of the 
> multiplexed link. But inside the kernel this is known and format 
> validation is done by comparing the format of Pad 1 to Pad 3 and Pad 2 
> to Pad 4 by the V4L2 framework. But it would be nice for the user to 
> also be able to get this information while setting up the MC graph in 
> user-space.
> 
> Obviously there are things that are not perfect in this RFC, one is the 
> above mentioned lack of user-space visibility of that Pad 1 is in fact 
> routed to Pad 3. Others are lack of Documentation/ work and I'm sure 
> there are error path shortcuts which are not fully thought out. One big 
> question is also if the s_stream() operation added to ops structure 
> should be a compliment to the existing ones in video and audio ops or 
> aim to replace the one in video ops. I'm also unsure of the CSI2 flag of 
> struct v4l2_mbus_frame_desc_entry don't really belong in struct 
> v4l2_mbus_frame_desc. And I'm sure there are lots of other stuff that's 
> why this is a RFC...
> 
> A big thanks to Laurent and Sakari for being really nice and taking time 
> helping me grasp all the possibilities and issues with this problem, all 
> cred to them and all blame to me for misunderstanding there guidance :-)
> 
> This series based on the latest R-Car CSI-2 and VIN patches which can be 
> found at [1], but that is a dependency only for the driver specific
> implementation which acts as an example of implementation. For the V4L2 
> framework patches the media-tree is the base.
> 
> 1. https://git.ragnatech.se/linux#rcar-vin-elinux-v12
> 
> Niklas Söderlund (20):
>   media.h: add MEDIA_PAD_FL_MUXED flag
>   v4l2-subdev.h: add pad and stream aware s_stream
>   v4l2-subdev.h: add CSI-2 bus description to struct
> v4l2_mbus_frame_desc_entry
>   v4l2-core: check that both pads in a link are muxed if one are
>   v4l2-core: verify all streams formats on multiplexed links
>   rcar-vin: use the pad and stream aware s_stream
>   rcar-csi2: declare sink pad as multiplexed
>   rcar-csi2: switch to pad and stream aware s_stream
>   rcar-csi2: figure out remote pad and stream which are 

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Andrzej Hajda]

On 14.03.2018 11:09, jacopo mondi wrote:
> Hi Andrzej,
> thanks for review
>
> On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote:
>> On 13.03.2018 15:30, Jacopo Mondi wrote:
>>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
>>> output decoder.
>> IMO converter suits here better, but it is just suggestion.
>>
>>> Signed-off-by: Jacopo Mondi 
>>> ---
>>>  drivers/gpu/drm/bridge/Kconfig|   7 +
>>>  drivers/gpu/drm/bridge/Makefile   |   1 +
>>>  drivers/gpu/drm/bridge/thc63lvd1024.c | 241 
>>> ++
>>>  3 files changed, 249 insertions(+)
>>>  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
>>>
>>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>>> index 3b99d5a..facf6bd 100644
>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>> @@ -92,6 +92,13 @@ config DRM_SII9234
>>>   It is an I2C driver, that detects connection of MHL bridge
>>>   and starts encapsulation of HDMI signal.
>>>
>>> +config DRM_THINE_THC63LVD1024
>>> +   tristate "Thine THC63LVD1024 LVDS decoder bridge"
>>> +   depends on OF
>>> +   select DRM_PANEL_BRIDGE
>> You don't use PANEL_BRIDGE, it should be possible to drop the select.
>>
> Ack
>
>>> +   ---help---
>>> + Thine THC63LVD1024 LVDS decoder bridge driver.
>> Decoder to what?
>> Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
>> converter or bridge.
> "LVDS to digital CMOS/TTL parallel data converter" as the manual
> describes the chip?

Should work, unless we want some consistency in interface names, we have
already: parallel / DPI / RGB. I am little bit confused about relations
between them so I do not want to enforce any.


>
>>> +
>>>  config DRM_TOSHIBA_TC358767
>>> tristate "Toshiba TC358767 eDP bridge"
>>> depends on OF
>>> diff --git a/drivers/gpu/drm/bridge/Makefile 
>>> b/drivers/gpu/drm/bridge/Makefile
>>> index 373eb28..fd90b16 100644
>>> --- a/drivers/gpu/drm/bridge/Makefile
>>> +++ b/drivers/gpu/drm/bridge/Makefile
>>> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>>>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>>>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>>>  obj-$(CONFIG_DRM_SII9234) += sii9234.o
>>> +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>>>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>>>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>>>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>>> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
>>> b/drivers/gpu/drm/bridge/thc63lvd1024.c
>>> new file mode 100644
>>> index 000..4b059c0
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
>>> @@ -0,0 +1,241 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
>>> + *
>>> + * Copyright (C) 2018 Jacopo Mondi 
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +static const char * const thc63_reg_names[] = {
>>> +   "vcc", "lvcc", "pvcc", "cvcc", };
>>> +
>>> +struct thc63_dev {
>>> +   struct device *dev;
>>> +
>>> +   struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
>>> +
>>> +   struct gpio_desc *pwdn;
>>> +   struct gpio_desc *oe;
>>> +
>>> +   struct drm_bridge bridge;
>>> +   struct drm_bridge *next;
>>> +};
>>> +
>>> +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
>>> +{
>>> +   return container_of(bridge, struct thc63_dev, bridge);
>>> +}
>>> +
>>> +static int thc63_attach(struct drm_bridge *bridge)
>>> +{
>>> +   struct thc63_dev *thc63 = to_thc63(bridge);
>>> +
>>> +   return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
>>> +}
>>> +
>>> +static void thc63_enable(struct drm_bridge *bridge)
>>> +{
>>> +   struct thc63_dev *thc63 = to_thc63(bridge);
>>> +   struct regulator *vcc;
>>> +   unsigned int i;
>>> +   int ret;
>>> +
>>> +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>>> +   vcc = thc63->vccs[i];
>>> +   if (vcc) {
>>> +   ret = regulator_enable(vcc);
>>> +   if (ret)
>>> +   goto error_vcc_enable;
>>> +   }
>>> +   }
>>> +
>>> +   if (thc63->pwdn)
>>> +   gpiod_set_value(thc63->pwdn, 0);
>>> +
>>> +   if (thc63->oe)
>>> +   gpiod_set_value(thc63->oe, 1);
>>> +
>>> +   return;
>>> +
>>> +error_vcc_enable:
>>> +   dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
>>> +}
>>> +
>>> +static void thc63_disable(struct drm_bridge *bridge)
>>> +{
>>> +   struct thc63_dev *thc63 = to_thc63(bridge);
>>> +   struct regulator *vcc;
>>> +   unsigned int i;
>>> +   int ret;
>>> +
>>> +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>>> +   vcc = thc63->vccs[i];
>>> +   if (vcc) {
>>> +   ret = regulator_disable(vcc);
>>> +   if (ret)
>>> +

Re: [git pull] clk: renesas: Updates for v4.17

[Geert Uytterhoeven]

Hi Stephen,

On Wed, Mar 14, 2018 at 10:43 PM, Stephen Boyd  wrote:
> Quoting Geert Uytterhoeven (2018-03-02 02:17:52)
>> The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
>>
>>   Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
>> tags/clk-renesas-for-v4.17-tag1
>>
>> for you to fetch changes up to 7ce36da900c0a2ff4777d9ba51c4f1cb74205463:
>>
>>   clk: renesas: cpg-mssr: Add support for R-Car M3-N (2018-02-26 09:13:29 
>> +0100)
>>
>> 
>> clk: renesas: Updates for v4.17
>>
>>   - Update legacy DT Kconfig default,
>>   - Add support for CPU (Z/Z2) clocks on R-Car H3 and M3-W,
>>   - Add support for the watchdog module clocks on R-Car Gen2 and RZ/G1,
>>   - Add support for the new R-Car M3-N and V3H SoCs.
>>
>> Thanks for pulling!
>>
>
> Thanks. Pulled into clk-next.

Thanks!

> Did you need to use clk_readl() or was it just copy-paste? I hope we can
> get rid of that function at some point.

That's an oversight. I will get rid of them in the second pull request
for v4.17.

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