Re: [PATCH 0/2] Salvator-X: Add GPIO keys support

[Geert Uytterhoeven]

Hi Laurent,

On Tue, Nov 15, 2016 at 12:59 AM, Laurent Pinchart
 wrote:
> On Monday 14 Nov 2016 20:47:03 Geert Uytterhoeven wrote:
>> On Mon, Nov 14, 2016 at 5:44 PM, Laurent Pinchart wrote:
>> > On Monday 14 Nov 2016 14:47:00 Geert Uytterhoeven wrote:
>> >> On Mon, Nov 14, 2016 at 2:41 PM, Laurent Pinchart wrote:
>> >>> On Monday 14 Nov 2016 14:35:26 Geert Uytterhoeven wrote:
>>  The main reason I haven't sent out a similar series yet is because the
>>  GPIOs used for the 3 push buttons are shared with the 3 user LEDs. For
>>  each of them, you have to choose at DT time if you want to use them as
>>  buttons or as LEDs.
>> 
>>  On ULCB, the same issue is present. For those, we settled on 1 key and
>>  2 LEDs...
>> 
>>  Looking forward to more comments...
>> >>>
>> >>> In theory the GPIOs could be shared by the gpio-keys and LED drivers in
>> >>> open- drain mode. I'm not sure the GPIO subsystem supports that though.
>> >>
>> >> Been there, done that, cfr. "[RFD] Sharing GPIOs for input (buttons) and
>> >> output (LEDs)". The result wasn't pretty...
>> >
>> > Wasn't it ? Linus basically told you to use open-drain GPIOs and fix the
>> > GPIO driver in case it can't read the value of GPIOs configured as output
>> > in open- drain mode. If didn't shoot the idea down.
>>
>> If I'm not mistaken, the R-Car GPIO block does not support open-drain GPIO.
>
> Not as such, but we can switch between input and output low, which is
> basically open-drain.
>
>> Even if it would support it, you cannot read the GPIO while actively
>> pulling it down.
>
> When actively driving it low you know the value is 0. Only when driving it
> open do you need to read the value back, and that's easily implemented as the
> hardware will be configured in input mode then.
>
>> Hence you have to time-multiplex the GPIO to use both LEDs and buttons,
>> through switching between pulling down and not pulling down (or between
>> output and input, which is what I did).
>
> No, if you want to use both, you should configure the I/O in open-drain, in
> which case you have two options:
>
> - Turn the LED on by driving the I/O "high", meaning leaving it floating. The
> pull-up resistor will turn the MOSFET on, the LED will be lit. When the
> corresponding button is pressed the I/O will be connected to GND, turning the
> LED off, and signalling the input.
>
> - Turn the LED off by driving the I/O low. Pressing the button won't have any
> effect. We need in this case to ignore the input value, which could be done by

Right. I tried to have both ;-)

> disabling the I/O interrupt (or just ignoring it).

IIRC, the R-Car GPIO block will send interrupts in output mode only.

>> Apart from that, there's also the discrepancy between hardware description
>> (the GPIO is connected to both buttons and LEDs, hence it should be
>> described that way in DT)
>
> Correct, this is where a framework change is needed if we want to allow both
> the GPIO keyboard and LED drivers to request the GPIO.
>
>> and user policy (the user wants to use e.g. the first GPIO as a button, and
>> the second GPIO as an LED).
>
> That's easy to do, the user will just need to turn the first LED on, allowing
> full button operation on the I/O.

Thanks, didn't think of that.

Gr{oetje,eeting}s,

Geert

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

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

Re: [git pull] clk: renesas: Updates for v4.10 (take one)

[Stephen Boyd]

On 11/14, Geert Uytterhoeven wrote:
> Hi Stephen,
> 
> On Fri, Nov 11, 2016 at 12:35 AM, Stephen Boyd  wrote:
> > On 11/07, Geert Uytterhoeven wrote:
> >> clk: renesas: Updates for v4.10 (take one)
> >>
> >>   - SYS-DMAC, (H)SCIF, I2C, DRIF, and graphics related clocks for R-Car
> >> M3-W,
> >>   - Minor fixes and cleanups.
> >>
> >> Thanks for pulling!
> >> 
> >> Geert Uytterhoeven (4):
> >>   clk: renesas: cpg-mssr: Always use readl()/writel()
> >>   clk: renesas: rcar-gen3-cpg: Always use readl()/writel()
> >>   clk: renesas: cpg-mssr: Fix inverted debug check
> >
> > Hm.. I already applied this one to clk-next. If you're going to
> > apply patches can you please indicate if they've been picked up
> > and/or not send them To: Mike and I, please?
> 
> Sorry, I'll be more clear in the future.
> 
> I believe this is not a blocker for pulling, is it?

No I guess not. Pulled into clk-next.

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

Re: [PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels

[Laurent Pinchart]

Hi Rob,

On Monday 14 Nov 2016 19:40:26 Rob Herring wrote:
> On Mon, Oct 17, 2016 at 7:42 AM, Laurent Pinchart wrote:
> > On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
> >> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
> >>> On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
>  On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
> > LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> > Multiple incompatible data link layers have been used over time to
> > transmit image data to LVDS panels. This binding supports display
> > panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
> > specifications.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  .../bindings/display/panel/panel-lvds.txt  | 119 
> >  1 file changed, 119 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> > b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> > new file mode 100644
> > index ..250861f2673e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> > @@ -0,0 +1,119 @@
> > +Generic LVDS Panel
> > +==
> > +
> > +LVDS is a physical layer specification defined in
> > ANSI/TIA/EIA-644-A. Multiple
> > +incompatible data link layers have been used over time to transmit
> > image data
> > +to LVDS panels. This bindings supports display panels compatible
> > with the
> > +following specifications.
> > +
> > +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
> > February
> > +1999 (Version 1.0), Japan Electronic Industry Development
> > Association (JEIDA)
> > +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95),
> > National
> > +Semiconductor
> > +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
> > Video
> > +Electronics Standards Association (VESA)
> > +
> > +Device compatible with those specifications have been marketed under
> > the
> > +FPD-Link and FlatLink brands.
> > +
> > +
> > +Required properties:
> > +- compatible: shall contain "panel-lvds"
>  
>  Maybe as a fallback, but on its own, no way.
> >>> 
> >>> Which brings an interesting question: when designing generic DT
> >>> bindings, what's the rule regarding
> > 
> > Looks like I forgot part of the question. I meant to ask what is the rule
> > regarding usage of more precise compatible strings ?
> 
> When in doubt, always have one. If there's any chance at all that s/w
> will need to know or care, then we should have one.
> 
> > For instance (but perhaps not the best example), the
> > input/rotary-encoder.txt bindings define a "rotary-encoder" compatible
> > string, with no other bindings defining more precise compatible strings
> > for the exact rotary encoder model. When it comes to panels I believe it
> > makes sense to define model-specific compatible strings even if they're
> > unused by drivers. I'm however wondering what the rule is there, and
> > where those device-specific compatible strings should be defined. I'd
> > like to avoid using one file per panel model as done today for the
> > simple-panel bindings.
> 
> There's a few exceptions like this where there is not any sort of
> model to base a compatible on. For example, a GPIO connected LED is
> truly generic. The only way to have a more specific compatible would
> be something with the board name in it.
> 
> Your case here is in the middle. It seems like it's generic and
> passive, but perhaps power control is not. Rather than trying to
> decide, we can just cover our ass and put both a generic and specific
> compatible in.

That sounds good to me. I'll mention in the document that a more precise 
compatible is required.

> >> Call it "simple" so I can easily NAK it. :)
> >> 
> >> Define a generic structure, not a single binding trying to serve all.
> >> 
> > +- width-mm: panel display width in millimeters
> > +- height-mm: panel display height in millimeters
>  
>  This is already documented for all panels IIRC.
> >>> 
> >>> Note that this DT binding has nothing to do with the simple-panel
> >>> binding. It is instead similar to the panel-dpi and panel-dsi-cm
> >>> bindings (which currently don't but should specify the panel size in
> >>> DT). The LVDS panel driver will *not* include any panel-specific
> >>> information such as size or timings, these are specified in DT.
> >> 
> >> The panel bindings aren't really different. The biggest difference was
> >> location in the tree, but we now generally allow panels to be either a
> >> child of the LCD controller or connected with OF graph. We probably
> >> need to work on re

Re: [GIT PULL FOR renesas-drivers] R-Car LVDS mode selection support

[Laurent Pinchart]

And the title should of course have read "R-Car LVDS mode selection support", 
sorry about that.

On Tuesday 15 Nov 2016 03:51:04 Laurent Pinchart wrote:
> Hi Geert,
> 
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
> 
>   Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/pinchartl/media.git drm/next/lvds
> 
> for you to fetch changes up to d2a726e6d677e4032595569b3e7cddefe638cd84:
> 
>   arm64: dts: r8a7795: salvator-x: Add DU LVDS output endpoint (2016-11-15
> 02:39:36 +0200)
> 
> 
> Koji Matsuoka (3):
>   drm: rcar-du: Fix display timing controller parameter
>   drm: rcar-du: Fix H/V sync signal polarity configuration
>   drm: rcar-du: Fix LVDS start sequence on Gen3
> 
> Laurent Pinchart (13):
>   video: of: Constify node argument to display timing functions
>   drm: rcar-du: Constify node argument to rcar_du_lvds_connector_init()
>   drm: rcar-du: Bring HDMI encoder comments in line with the driver
>   drm: rcar-du: Remove test for impossible error condition
>   drm: rcar-du: Remove memory allocation error message
>   drm: rcar-du: Fix crash in encoder failure error path
>   drm: rcar-du: Simplify and fix probe error handling
>   drm: rcar-du: Add R8A7796 support
>   drm: rcar-du: Fix dot clock routing configuration
>   devicetree/bindings: display: Add bindings for LVDS panels
>   drm: rcar-du: Add support for LVDS mode selection
>   ARM: shmobile: dts: Switch to panel-lvds bindings for Mitsubishi
> panels arm64: dts: r8a7795: salvator-x: Add DU LVDS output endpoint
> 
> Sergei Shtylyov (1):
>   drm: rcar-du: Add R8A7792 support
> 
>  .../bindings/display/panel/panel-lvds.txt  | 119
>  .../devicetree/bindings/display/renesas,du.txt | 
> 12 +-
>  arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi |   3 +-
>  arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi |   3 +-
>  arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |   4 +
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c |   6 +-
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  83 +-
>  drivers/gpu/drm/rcar-du/rcar_du_group.c|  22 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c  |   4 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  17 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  31 -
>  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h  |   2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c  |  30 +++--
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h  |  13 +++
>  drivers/video/of_display_timing.c  |   6 +-
>  include/video/of_display_timing.h  |  15 +--
>  16 files changed, 295 insertions(+), 75 deletions(-)
>  create mode 100644
> Documentation/devicetree/bindings/display/panel/panel-lvds.txt

-- 
Regards,

Laurent Pinchart

[GIT PULL FOR renesas-drivers] R-Car DU M3-W support

[Laurent Pinchart]

Hi Geert,

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git drm/next/lvds

for you to fetch changes up to d2a726e6d677e4032595569b3e7cddefe638cd84:

  arm64: dts: r8a7795: salvator-x: Add DU LVDS output endpoint (2016-11-15 
02:39:36 +0200)


Koji Matsuoka (3):
  drm: rcar-du: Fix display timing controller parameter
  drm: rcar-du: Fix H/V sync signal polarity configuration
  drm: rcar-du: Fix LVDS start sequence on Gen3

Laurent Pinchart (13):
  video: of: Constify node argument to display timing functions
  drm: rcar-du: Constify node argument to rcar_du_lvds_connector_init()
  drm: rcar-du: Bring HDMI encoder comments in line with the driver
  drm: rcar-du: Remove test for impossible error condition
  drm: rcar-du: Remove memory allocation error message
  drm: rcar-du: Fix crash in encoder failure error path
  drm: rcar-du: Simplify and fix probe error handling
  drm: rcar-du: Add R8A7796 support
  drm: rcar-du: Fix dot clock routing configuration
  devicetree/bindings: display: Add bindings for LVDS panels
  drm: rcar-du: Add support for LVDS mode selection
  ARM: shmobile: dts: Switch to panel-lvds bindings for Mitsubishi panels
  arm64: dts: r8a7795: salvator-x: Add DU LVDS output endpoint

Sergei Shtylyov (1):
  drm: rcar-du: Add R8A7792 support

 .../bindings/display/panel/panel-lvds.txt  | 119 
 .../devicetree/bindings/display/renesas,du.txt |  12 +-
 arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi |   3 +-
 arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi |   3 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |   4 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  83 +-
 drivers/gpu/drm/rcar-du/rcar_du_group.c|  22 ++--
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c  |   4 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  17 ++-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  31 -
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h  |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c  |  30 +++--
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h  |  13 +++
 drivers/video/of_display_timing.c  |   6 +-
 include/video/of_display_timing.h  |  15 +--
 16 files changed, 295 insertions(+), 75 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/panel-lvds.txt

-- 
Regards,

Laurent Pinchart

[GIT PULL FOR renesas-drivers] R-Car DU M3-W support

[Laurent Pinchart]

Hi Geert,

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git drm/r8a7796/next

for you to fetch changes up to 3bd092b7a3dc1b2f82ac11c34114be4f996f7cbd:

  Merge branch 'drm/r8a7796/fcp' into drm/r8a7796/next (2016-11-15 03:35:09 
+0200)

I have split the patches in topic branches named drm/r8a7796/clk, 
drm/r8a7796/dt, drm/r8a7796/du and drm/r8a7796/fcp and have merged them all in 
drm/r8a7796/next. Please feel free to merge those topic branches instead if 
that's easier for you.


Laurent Pinchart (13):
  dt-bindings: media: renesas-fcp: Remove SoC-specific compatible strings
  arm64: dts: renesas: r8a7795: Remove FCP SoC-specific compatible strings
  arm64: dts: renesas: r8a7796: Add FCPF and FCPV instances
  arm64: dts: renesas: r8a7796: Add VSP instances
  arm64: dts: renesas: r8a7796: Add DU device to DT
  arm64: dts: renesas: r8a7796-salvator-x: Enable DU
  drm: rcar-du: Add R8A7796 device support
  clk: renesas: r8a7796: Add FCP clocks
  clk: renesas: r8a7796: Add VSP clocks
  clk: renesas: r8a7796: Add DU and LVDS clocks
  Merge branch 'drm/r8a7796/dt' into drm/r8a7796/next
  Merge branch 'drm/r8a7796/du' into drm/r8a7796/next
  Merge branch 'drm/r8a7796/fcp' into drm/r8a7796/next

 .../devicetree/bindings/display/renesas,du.txt |   4 +-
 .../devicetree/bindings/media/renesas,fcp.txt  |   8 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  24 ++--
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts |  48 +++
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   | 131 
 drivers/clk/renesas/r8a7796-cpg-mssr.c |  17 +++
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  25 
 7 files changed, 237 insertions(+), 20 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels

[Rob Herring]

On Mon, Oct 17, 2016 at 7:42 AM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
>> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
>> > On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
>> >> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
>> >>> LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>> >>> Multiple incompatible data link layers have been used over time to
>> >>> transmit image data to LVDS panels. This binding supports display
>> >>> panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
>> >>> specifications.
>> >>>
>> >>> Signed-off-by: Laurent Pinchart
>> >>> 
>> >>> ---
>> >>>
>> >>>  .../bindings/display/panel/panel-lvds.txt  | 119 ++
>> >>>  1 file changed, 119 insertions(+)
>> >>>  create mode 100644
>> >>>  Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
>> >>>
>> >>> diff --git
>> >>> a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> new file mode 100644
>> >>> index ..250861f2673e
>> >>> --- /dev/null
>> >>> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> @@ -0,0 +1,119 @@
>> >>> +Generic LVDS Panel
>> >>> +==
>> >>> +
>> >>> +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>> >>> Multiple
>> >>> +incompatible data link layers have been used over time to transmit
>> >>> image data
>> >>> +to LVDS panels. This bindings supports display panels compatible with
>> >>> the
>> >>> +following specifications.
>> >>> +
>> >>> +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
>> >>> February
>> >>> +1999 (Version 1.0), Japan Electronic Industry Development Association
>> >>> (JEIDA)
>> >>> +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
>> >>> +Semiconductor
>> >>> +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
>> >>> Video
>> >>> +Electronics Standards Association (VESA)
>> >>> +
>> >>> +Device compatible with those specifications have been marketed under
>> >>> the
>> >>> +FPD-Link and FlatLink brands.
>> >>> +
>> >>> +
>> >>> +Required properties:
>> >>> +- compatible: shall contain "panel-lvds"
>> >>
>> >> Maybe as a fallback, but on its own, no way.
>> >
>> > Which brings an interesting question: when designing generic DT bindings,
>> > what's the rule regarding
>
> Looks like I forgot part of the question. I meant to ask what is the rule
> regarding usage of more precise compatible strings ?

When in doubt, always have one. If there's any chance at all that s/w
will need to know or care, then we should have one.

> For instance (but perhaps not the best example), the input/rotary-encoder.txt
> bindings define a "rotary-encoder" compatible string, with no other bindings
> defining more precise compatible strings for the exact rotary encoder model.
> When it comes to panels I believe it makes sense to define model-specific
> compatible strings even if they're unused by drivers. I'm however wondering
> what the rule is there, and where those device-specific compatible strings
> should be defined. I'd like to avoid using one file per panel model as done
> today for the simple-panel bindings.

There's a few exceptions like this where there is not any sort of
model to base a compatible on. For example, a GPIO connected LED is
truly generic. The only way to have a more specific compatible would
be something with the board name in it.

Your case here is in the middle. It seems like it's generic and
passive, but perhaps power control is not. Rather than trying to
decide, we can just cover our ass and put both a generic and specific
compatible in.

>> Call it "simple" so I can easily NAK it. :)
>>
>> Define a generic structure, not a single binding trying to serve all.
>>
>> >> > +- width-mm: panel display width in millimeters
>> >> > +- height-mm: panel display height in millimeters
>> >>
>> >> This is already documented for all panels IIRC.
>> >
>> > Note that this DT binding has nothing to do with the simple-panel binding.
>> > It is instead similar to the panel-dpi and panel-dsi-cm bindings (which
>> > currently don't but should specify the panel size in DT). The LVDS panel
>> > driver will *not* include any panel-specific information such as size or
>> > timings, these are specified in DT.
>>
>> The panel bindings aren't really different. The biggest difference was
>> location in the tree, but we now generally allow panels to be either a
>> child of the LCD controller or connected with OF graph. We probably
>> need to work on restructuring the panel bindings a bit. We should have
>> an inheritance with a base panel binding of things like size, label,
>> graph, backlight, etc, then perhaps an interface specific bindings for
>> LVDS, DSI, and parallel, then a panel specific binding. With this the
>> panel specific binding is typic

[PATCH] ARM: shmobile: dts: Switch to panel-lvds bindings for Mitsubishi panels

[Laurent Pinchart]

The aa104xd12 and aa121td01 panels are LVDS panels, not DPI panels.
Use the correct DT bindings.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi | 3 ++-
 arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

Hello,

This patch is an example of how the panel-lvds bindings should be used for
display panels. It isn't meant to be merged upstream at the moment as the
bindings haven't been accepted yet but can already be used as both an example
and a test base for LVDS mode selection.

diff --git a/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi 
b/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
index 65cb50f0c29f..238d14bb0ebe 100644
--- a/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
+++ b/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
@@ -10,10 +10,11 @@
 
 / {
panel {
-   compatible = "mitsubishi,aa104xd12", "panel-dpi";
+   compatible = "mitsubishi,aa104xd12", "panel-lvds";
 
width-mm = <210>;
height-mm = <158>;
+   data-mapping = "jeida-18";
 
panel-timing {
/* 1024x768 @65Hz */
diff --git a/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi 
b/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi
index a07ebf8f6938..04aafd479775 100644
--- a/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi
+++ b/arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi
@@ -10,10 +10,11 @@
 
 / {
panel {
-   compatible = "mitsubishi,aa121td01", "panel-dpi";
+   compatible = "mitsubishi,aa121td01", "panel-lvds";
 
width-mm = <261>;
height-mm = <163>;
+   data-mapping = "jeida-18";
 
panel-timing {
/* 1280x800 @60Hz */
-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/2] Salvator-X: Add GPIO keys support

[Laurent Pinchart]

Hi Geert,

On Monday 14 Nov 2016 20:47:03 Geert Uytterhoeven wrote:
> On Mon, Nov 14, 2016 at 5:44 PM, Laurent Pinchart wrote:
> > On Monday 14 Nov 2016 14:47:00 Geert Uytterhoeven wrote:
> >> On Mon, Nov 14, 2016 at 2:41 PM, Laurent Pinchart wrote:
> >>> On Monday 14 Nov 2016 14:35:26 Geert Uytterhoeven wrote:
>  The main reason I haven't sent out a similar series yet is because the
>  GPIOs used for the 3 push buttons are shared with the 3 user LEDs. For
>  each of them, you have to choose at DT time if you want to use them as
>  buttons or as LEDs.
>  
>  On ULCB, the same issue is present. For those, we settled on 1 key and
>  2 LEDs...
>  
>  Looking forward to more comments...
> >>> 
> >>> In theory the GPIOs could be shared by the gpio-keys and LED drivers in
> >>> open- drain mode. I'm not sure the GPIO subsystem supports that though.
> >> 
> >> Been there, done that, cfr. "[RFD] Sharing GPIOs for input (buttons) and
> >> output (LEDs)". The result wasn't pretty...
> > 
> > Wasn't it ? Linus basically told you to use open-drain GPIOs and fix the
> > GPIO driver in case it can't read the value of GPIOs configured as output
> > in open- drain mode. If didn't shoot the idea down.
> 
> If I'm not mistaken, the R-Car GPIO block does not support open-drain GPIO.

Not as such, but we can switch between input and output low, which is 
basically open-drain.

> Even if it would support it, you cannot read the GPIO while actively
> pulling it down.

When actively driving it low you know the value is 0. Only when driving it 
open do you need to read the value back, and that's easily implemented as the 
hardware will be configured in input mode then.

> Hence you have to time-multiplex the GPIO to use both LEDs and buttons,
> through switching between pulling down and not pulling down (or between
> output and input, which is what I did).

No, if you want to use both, you should configure the I/O in open-drain, in 
which case you have two options:

- Turn the LED on by driving the I/O "high", meaning leaving it floating. The 
pull-up resistor will turn the MOSFET on, the LED will be lit. When the 
corresponding button is pressed the I/O will be connected to GND, turning the 
LED off, and signalling the input.

- Turn the LED off by driving the I/O low. Pressing the button won't have any 
effect. We need in this case to ignore the input value, which could be done by 
disabling the I/O interrupt (or just ignoring it).

> Apart from that, there's also the discrepancy between hardware description
> (the GPIO is connected to both buttons and LEDs, hence it should be
> described that way in DT)

Correct, this is where a framework change is needed if we want to allow both 
the GPIO keyboard and LED drivers to request the GPIO.

> and user policy (the user wants to use e.g. the first GPIO as a button, and
> the second GPIO as an LED).

That's easy to do, the user will just need to turn the first LED on, allowing 
full button operation on the I/O.

> If you have ideas to solve these 2  issues, I'm happy  to hear your
> thoughts!

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels

[Laurent Pinchart]

Hi Rob,

Ping ?

On Monday 17 Oct 2016 15:42:56 Laurent Pinchart wrote:
> On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
> > On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
> >> On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
> >>> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
>  LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>  Multiple incompatible data link layers have been used over time to
>  transmit image data to LVDS panels. This binding supports display
>  panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
>  specifications.
>  
>  Signed-off-by: Laurent Pinchart
>  
>  ---
>  
>   .../bindings/display/panel/panel-lvds.txt  | 119 
>   1 file changed, 119 insertions(+)
>   create mode 100644
>   Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
>  
>  diff --git
>  a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>  b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>  new file mode 100644
>  index ..250861f2673e
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>  @@ -0,0 +1,119 @@
>  +Generic LVDS Panel
>  +==
>  +
>  +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>  Multiple
>  +incompatible data link layers have been used over time to transmit
>  image data
>  +to LVDS panels. This bindings supports display panels compatible with
>  the
>  +following specifications.
>  +
>  +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
>  February
>  +1999 (Version 1.0), Japan Electronic Industry Development Association
>  (JEIDA)
>  +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95),
>  National
>  +Semiconductor
>  +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
>  Video
>  +Electronics Standards Association (VESA)
>  +
>  +Device compatible with those specifications have been marketed under
>  the
>  +FPD-Link and FlatLink brands.
>  +
>  +
>  +Required properties:
>  +- compatible: shall contain "panel-lvds"
> >>> 
> >>> Maybe as a fallback, but on its own, no way.
> >> 
> >> Which brings an interesting question: when designing generic DT
> >> bindings, what's the rule regarding
> 
> Looks like I forgot part of the question. I meant to ask what is the rule
> regarding usage of more precise compatible strings ?
> 
> For instance (but perhaps not the best example), the
> input/rotary-encoder.txt bindings define a "rotary-encoder" compatible
> string, with no other bindings defining more precise compatible strings for
> the exact rotary encoder model. When it comes to panels I believe it makes
> sense to define model-specific compatible strings even if they're unused by
> drivers. I'm however wondering what the rule is there, and where those
> device-specific compatible strings should be defined. I'd like to avoid
> using one file per panel model as done today for the simple-panel bindings.
> 
> > Call it "simple" so I can easily NAK it. :)
> > 
> > Define a generic structure, not a single binding trying to serve all.
> > 
> >>> > +- width-mm: panel display width in millimeters
> >>> > +- height-mm: panel display height in millimeters
> >>> 
> >>> This is already documented for all panels IIRC.
> >> 
> >> Note that this DT binding has nothing to do with the simple-panel
> >> binding. It is instead similar to the panel-dpi and panel-dsi-cm bindings
> >> (which currently don't but should specify the panel size in DT). The LVDS
> >> panel driver will *not* include any panel-specific information such as
> >> size or timings, these are specified in DT.
> > 
> > The panel bindings aren't really different. The biggest difference was
> > location in the tree, but we now generally allow panels to be either a
> > child of the LCD controller or connected with OF graph. We probably
> > need to work on restructuring the panel bindings a bit. We should have
> > an inheritance with a base panel binding of things like size, label,
> > graph, backlight, etc, then perhaps an interface specific bindings for
> > LVDS, DSI, and parallel, then a panel specific binding. With this the
> > panel specific binding is typically just a compatible string and which
> > inherited properties apply to it.
> 
> That sounds good to me, but we have multiple models for panel bindings.
> 
> As you mentioned panels can be referenced through an LCD controller node
> property containing a phandle to the panel node, or through OF graph. That's
> a situation we have today, and we need to keep supporting both (at least
> for existing panels, perhaps not for the new ones).
> 
> Another difference is how to express panel data such as size and timings.
> The simple-panel DT bind

[GIT PULL FOR renesas-drivers] VSP Partition algorithm improvements

[Kieran Bingham]

From: Kieran Bingham 

Hi Geert,

The following changes since commit 8bc55e5947b58dee3c8b126d7c303991ae0db130:

  tty: serial_core: Fix serial console crash on port shutdown (2016-10-25 
13:53:49 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git 
tags/vsp1/pa-improvements/v1

for you to fetch changes up to 97ec8cd22aae933399b84b1a84eedcc48ad35eb8:

  v4l: vsp1: Remove redundant context variables (2016-11-14 18:49:57 +)

This tag contains some improvements to the performance of the partition
algorithm by moving the calculations to the stream on calls, instead of
calculating each partition in every frame during interrupt context.


Kieran Bingham (4):
  v4l: vsp1: Implement partition algorithm restrictions
  v4l: vsp1: Move vsp1_video_pipeline_setup_partitions() function
  v4l: vsp1: Calculate partition sizes at stream start.
  v4l: vsp1: Remove redundant context variables

 drivers/media/platform/vsp1/vsp1_pipe.h  |  10 ++-
 drivers/media/platform/vsp1/vsp1_sru.c   |   7 +-
 drivers/media/platform/vsp1/vsp1_sru.h   |   1 +
 drivers/media/platform/vsp1/vsp1_video.c | 124 +++
 4 files changed, 89 insertions(+), 53 deletions(-)

[GIT PULL FOR renesas-drivers] VSP Writeback prototype

[Kieran Bingham]

From: Kieran Bingham 

Hi Geert,

The following changes since commit 8bc55e5947b58dee3c8b126d7c303991ae0db130:

  tty: serial_core: Fix serial console crash on port shutdown (2016-10-25 
13:53:49 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git 
tags/vsp1/writeback/v2

for you to fetch changes up to 7ce3d143d5c287e5786b3471c32112363bcbdca2:

  v4l: vsp1: Provide a writeback video device (2016-11-03 10:34:29 +)

This implementation of a writeback video node allows frames to be
captured from the display pipeline using standard V4L2 calls.


Kieran Bingham (2):
  Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
  v4l: vsp1: Provide a writeback video device

 drivers/media/platform/vsp1/vsp1.h   |   1 +
 drivers/media/platform/vsp1/vsp1_drm.c   |  19 
 drivers/media/platform/vsp1/vsp1_drv.c   |   5 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h  |   1 +
 drivers/media/platform/vsp1/vsp1_video.c | 161 ---
 drivers/media/platform/vsp1/vsp1_video.h |   5 +
 drivers/media/platform/vsp1/vsp1_wpf.c   |  19 +++-
 7 files changed, 193 insertions(+), 18 deletions(-)

Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support

[Geert Uytterhoeven]

Hi Rob,

On Mon, Nov 14, 2016 at 8:52 PM, Rob Herring  wrote:
> On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
>> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> > @@ -0,0 +1,136 @@

>> > +Example
>> > +
>> > +
>> > +SoC common dtsi file
>> > +
>> > +   drif00: rif@e6f4 {
>> > +   compatible = "renesas,r8a7795-drif",
>> > +"renesas,rcar-gen3-drif";
>> > +   reg = <0 0xe6f4 0 0x64>;
>> > +   interrupts = ;
>> > +   clocks = <&cpg CPG_MOD 515>;
>> > +   clock-names = "fck";
>> > +   dmas = <&dmac1 0x20>, <&dmac2 0x20>;
>> > +   dma-names = "rx", "rx";
>
> rx, rx? That doesn't make sense. While we don't explicitly disallow
> this, I'm thinking we should. I wonder if there's any case this is
> valid. If not, then a dtc check for this could be added.

The device can be used with either dmac1 or dmac2.
Which one is used is decided at run time, based on the availability of
DMA channels per DMAC, which is a limited resource.

>> > +   power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > +   status = "disabled";
>> > +   };
>> > +
>> > +   drif01: rif@e6f5 {
>> > +   compatible = "renesas,r8a7795-drif",
>> > +"renesas,rcar-gen3-drif";
>> > +   reg = <0 0xe6f5 0 0x64>;
>> > +   interrupts = ;
>> > +   clocks = <&cpg CPG_MOD 514>;
>> > +   clock-names = "fck";
>> > +   dmas = <&dmac1 0x22>, <&dmac2 0x22>;
>> > +   dma-names = "rx", "rx";
>> > +   power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > +   status = "disabled";
>> > +   };
>> > +
>> > +   drif0: rif@0 {
>> > +   compatible = "renesas,r8a7795-drif",
>> > +"renesas,rcar-gen3-drif";
>> > +   sub-channels = <&drif00>, <&drif01>;
>> > +   status = "disabled";
>> > +   };
>>
>> I'm afraid this really hurts my eyes, especially using the same compatible
>> string for both the channel and sub-channel nodes.
>>
>> We need to decide how to model the hardware in DT. Given that the two 
>> channels
>> are mostly independent having separate DT nodes makes sense to me. However, 
>> as
>> they share the clock and sync signals, somehow grouping them makes sense. I
>> see three ways to do so, and there might be more.
>>
>> 1. Adding an extra DT node for the channels group, with phandles to the two
>> channels. This is what you're proposing here.
>>
>> 2. Adding an extra DT node for the channels group, as a parent of the two
>> channels.
>>
>> 3. Adding phandles to the channels, pointing to each other, or possibly a
>> phandle from channel 0 pointing to channel 1.
>>
>> Neither of these options seem perfect to me. I don't like option 1 as the
>> group DT node really doesn't describe a hardware block. If we want to use a 
>> DT
>> node to convey group information, option 2 seems better to me. However, it
>> somehow abuses the DT parent-child model that is supposed to describe
>> relationships from a control bus point of view. Option 3 has the drawback of
>> not scaling properly, at least with phandles in both channels pointing to the
>> other one.
>>
>> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
>> solve all those problems :-)
>
> What's the purpose/need for grouping them?
>
> I'm fine with Option 2, though I want to make sure it is really needed.

Each half of a DRIF pair is basically an SPI slave controller without TX
capability, sharing clock and chip-select between the two halves.
Hence you can use either one half to receive 1 bit per clock pulse,
or both halves to receive 2 bits per clock pulse.
You cannot use both halves for independent operation due to the signal
sharing.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support

[Rob Herring]

On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
> Hi Ramesh,
> 
> Thank you for the patch.
> 
> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> > 
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and the
> > tuner device, which is registered as a sub-device, determines the receive
> > sample rate and format.
> > 
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF acts
> > as a slave device and the tuner device acts as a master transmitting the
> > samples. The driver allows asynchronous binding of a tuner device that
> > is registered as a v4l2 sub-device. The driver can learn about the tuner
> > it is interfaced with based on port endpoint properties of the device in
> > device tree. The V4L2 SDR device inherits the controls exposed by the
> > tuner device.
> > 
> > The device can also be configured to use either one or both of the data
> > pins at runtime based on the master (tuner) configuration.
> > 
> > Signed-off-by: Ramesh Shanmugasundaram
> >  ---
> >  .../devicetree/bindings/media/renesas,drif.txt |  136 ++
> >  drivers/media/platform/Kconfig |   25 +
> >  drivers/media/platform/Makefile|1 +
> >  drivers/media/platform/rcar_drif.c | 1574
> >  4 files changed, 1736 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
> > create mode 100644 drivers/media/platform/rcar_drif.c
> > 
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode
> > 100644
> > index 000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++-++-+
> > +| |-SCK--->|CLK  |
> > +|   Master|-SS>|SYNC  DRIFn (slave)  |
> > +| |-SD0--->|D0   |
> > +| |-SD1--->|D1   |
> > ++-++-+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 & drifn1).
> > +The sub-channels are like two individual channels in itself that share the
> > +common CLK & SYNC. Each sub-channel has it's own dedicated resources like
> > +irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's sub-channel
> > +as a separate node. The parent channel ties the sub-channels together with
> > +their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> > R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> > device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +-
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +-
> > +- port: child port node of a channel that defines the local and remote
> > +endpoints. The remote endpoint is assumed to be a tuner subdevice
> > +   endpoint.
> > +- renesas,syncmd   : sync mode
> > +0 (Frame start sync pulse mode. 1-bit width pulse
> > +   indicates start of a frame)
> >

Re: [PATCH 0/2] Salvator-X: Add GPIO keys support

[Geert Uytterhoeven]

Hi Laurent,

On Mon, Nov 14, 2016 at 5:44 PM, Laurent Pinchart
 wrote:
> On Monday 14 Nov 2016 14:47:00 Geert Uytterhoeven wrote:
>> On Mon, Nov 14, 2016 at 2:41 PM, Laurent Pinchart wrote:
>> > On Monday 14 Nov 2016 14:35:26 Geert Uytterhoeven wrote:
>> >> The main reason I haven't sent out a similar series yet is because the
>> >> GPIOs used for the 3 push buttons are shared with the 3 user LEDs. For
>> >> each of them, you have to choose at DT time if you want to use them as
>> >> buttons or as LEDs.
>> >>
>> >> On ULCB, the same issue is present. For those, we settled on 1 key and 2
>> >> LEDs...
>> >>
>> >> Looking forward to more comments...
>> >
>> > In theory the GPIOs could be shared by the gpio-keys and LED drivers in
>> > open- drain mode. I'm not sure the GPIO subsystem supports that though.
>>
>> Been there, done that, cfr. "[RFD] Sharing GPIOs for input (buttons) and
>> output (LEDs)". The result wasn't pretty...
>
> Wasn't it ? Linus basically told you to use open-drain GPIOs and fix the GPIO
> driver in case it can't read the value of GPIOs configured as output in open-
> drain mode. If didn't shoot the idea down.

If I'm not mistaken, the R-Car GPIO block does not support open-drain GPIO.
Even if it would support it, you cannot read the GPIO while actively
pulling it down.
Hence you have to time-multiplex the GPIO to use both LEDs and buttons,
through switching between pulling down and not pulling down (or between
output and input, which is what I did).

Apart from that, there's also the discrepancy between hardware description
(the GPIO is connected to both buttons and LEDs, hence it should be described
that way in DT) and user policy (the user wants to use e.g. the first GPIO as a
button, and the second GPIO as an LED).

If you have ideas to solve these 2  issues, I'm happy  to hear your thoughts!

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/5] media: i2c: max2175: Add MAX2175 support

[Rob Herring]

On Wed, Nov 09, 2016 at 03:44:41PM +, Ramesh Shanmugasundaram wrote:
> This patch adds driver support for MAX2175 chip. This is Maxim
> Integrated's RF to Bits tuner front end chip designed for software-defined
> radio solutions. This driver exposes the tuner as a sub-device instance
> with standard and custom controls to configure the device.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
>  .../devicetree/bindings/media/i2c/max2175.txt  |   61 +

It's preferred that bindings are a separate patch.

>  drivers/media/i2c/Kconfig  |4 +
>  drivers/media/i2c/Makefile |2 +
>  drivers/media/i2c/max2175/Kconfig  |8 +
>  drivers/media/i2c/max2175/Makefile |4 +
>  drivers/media/i2c/max2175/max2175.c| 1558 
> 
>  drivers/media/i2c/max2175/max2175.h|  108 ++
>  7 files changed, 1745 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt
>  create mode 100644 drivers/media/i2c/max2175/Kconfig
>  create mode 100644 drivers/media/i2c/max2175/Makefile
>  create mode 100644 drivers/media/i2c/max2175/max2175.c
>  create mode 100644 drivers/media/i2c/max2175/max2175.h
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt 
> b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> new file mode 100644
> index 000..69f0dad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> @@ -0,0 +1,61 @@
> +Maxim Integrated MAX2175 RF to Bits tuner
> +-
> +
> +The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
> +RF to Bits® front-end designed for software-defined radio solutions.
> +
> +Required properties:
> +
> +- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
> +- clocks: phandle to the fixed xtal clock.
> +- clock-names: name of the fixed xtal clock.
> +- port: child port node of a tuner that defines the local and remote
> +  endpoints. The remote endpoint is assumed to be an SDR device
> +  that is capable of receiving the digital samples from the tuner.
> +
> +Optional properties:
> +
> +- maxim,slave  : empty property indicates this is a slave of
> + another master tuner. This is used to define two
> + tuners in diversity mode (1 master, 1 slave). By
> + default each tuner is an individual master.
> +- maxim,refout-load-pF: load capacitance value (in pF) on reference

Please add 'pF' to property-units.txt.

> + output drive level. The possible load values are
> +  0pF (default - refout disabled)
> + 10pF
> + 20pF
> + 30pF
> + 40pF
> + 60pF
> + 70pF
> +- maxim,am-hiz : empty property indicates AM Hi-Z filter path is
> + selected for AM antenna input. By default this
> + filter path is not used.
> +
> +Example:
> +
> +
> +Board specific DTS file
> +
> +/* Fixed XTAL clock node */
> +maxim_xtal: maximextal {

clock {

> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <36864000>;
> +};
> +
> +/* A tuner device instance under i2c bus */
> +max2175_0: tuner@60 {
> + compatible = "maxim,max2175";
> + reg = <0x60>;
> + clocks = <&maxim_xtal>;
> + clock-names = "xtal";
> + maxim,refout-load-pF = <10>;
> +
> + port {
> + max2175_0_ep: endpoint {
> + remote-endpoint = <&slave_rx_v4l2_sdr_device>;

'v4l2' is not something that should appear in a DT.

> + };
> + };
> +
> +};

[PATCH v3 06/11] ARM: dts: r8a7791: Add device node for PRR

[Geert Uytterhoeven]

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Add to posted series,

v2:
  - New.
---
 arch/arm/boot/dts/r8a7791.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 091d7fb6ee7d53cc..4c50de2faef12301 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1485,6 +1485,11 @@
};
};
 
+   prr: chipid@ff44 {
+   compatible = "renesas,prr";
+   reg = <0 0xff44 0 4>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7791-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
1.9.1

[PATCH v3 07/11] ARM: dts: r8a7792: Add device node for PRR

[Geert Uytterhoeven]

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Add to posted series,

v2:
  - New.
---
 arch/arm/boot/dts/r8a7792.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index a75e0cd312c5ecdf..69789020cf39e95f 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -120,6 +120,11 @@
  IRQ_TYPE_LEVEL_LOW)>;
};
 
+   prr: chipid@ff44 {
+   compatible = "renesas,prr";
+   reg = <0 0xff44 0 4>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7792-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
1.9.1

[PATCH v3 10/11] arm64: dts: r8a7795: Add device node for PRR

[Geert Uytterhoeven]

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - No changes,

v2:
  - New.
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 681f54422375f4f7..a39a702b904da73c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -321,6 +321,11 @@
#power-domain-cells = <0>;
};
 
+   prr: chipid@fff00044 {
+   compatible = "renesas,prr";
+   reg = <0 0xfff00044 0 4>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7795-sysc";
reg = <0 0xe618 0 0x0400>;
-- 
1.9.1

[PATCH v3 04/11] ARM: dts: r8a7779: Add device node for PRR

[Geert Uytterhoeven]

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Add to posted series,

v2:
  - New.
---
 arch/arm/boot/dts/r8a7779.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 3005308a1807ca43..9d3bb74bd3f684d5 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -590,6 +590,11 @@
};
};
 
+   prr: chipid@ff44 {
+   compatible = "renesas,prr";
+   reg = <0xff44 4>;
+   };
+
sysc: system-controller@ffd85000 {
compatible = "renesas,r8a7779-sysc";
reg = <0xffd85000 0x0200>;
-- 
1.9.1

[PATCH v3 01/11] ARM: shmobile: Document DT bindings for Product Register

[Geert Uytterhoeven]

Add device tree binding documentation for the Product Register (PRR),
which provides product and revision information on most Renesas ARM
SoCs.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Rob Herring 
---
v3:
  - Add Acked-by,
  - Drop "renesas,cccr", as the CCCR is not a lone register, but part of
the HPB/APB block, which will need its own set of bindings,

v2:
  - New.
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index a1e94da0e322c8f4..1be9e8a7e2c43dfc 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -81,3 +81,21 @@ Boards:
 compatible = "renesas,sk-rzg1m", "renesas,r8a7743"
   - Wheat
 compatible = "renesas,wheat", "renesas,r8a7792"
+
+
+Most Renesas ARM SoCs have a Product Register that allows to retrieve SoC
+product and revision information.  If present, a device node for this register
+should be added.
+
+Required properties:
+  - compatible: Must be "renesas,prr".
+  - reg: Base address and length of the register block.
+
+
+Examples
+
+
+   prr: chipid@ff44 {
+   compatible = "renesas,prr";
+   reg = <0 0xff44 0 4>;
+   };
-- 
1.9.1

[PATCH v3 08/11] ARM: dts: r8a7793: Add device node for PRR

[Geert Uytterhoeven]

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Add to posted series,

v2:
  - New.
---
 arch/arm/boot/dts/r8a7793.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 629d3d60d1cd7168..a377dda177241da0 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1306,6 +1306,11 @@
};
};
 
+   prr: chipid@ff44 {
+   compatible = "renesas,prr";
+   reg = <0 0xff44 0 4>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7793-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
1.9.1

[PATCH v3 02/11] soc: renesas: Identify SoC and register with the SoC bus

[Geert Uytterhoeven]

Identify the SoC type and revision, and register this information with
the SoC bus, so it is available under /sys/devices/soc0/, and can be
checked where needed using soc_device_match().

Identification is done using the Product Register or Common Chip Code
Register, as declared in DT (PRR only for now), or using a hardcoded
fallback if missing.

Example:

Detected Renesas R-Car Gen2 r8a7791 ES1.0
...
# cat /sys/devices/soc0/{machine,family,soc_id,revision}
Koelsch
R-Car Gen2
r8a7791
ES1.0

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Re-add SoC families and family names,
  - Re-add RZ/A1H and R-Car M1A, not providing a revision,
  - On arm, move "select SOC_BUS" to ARCH_RENESAS again,
  - Drop "renesas,cccr" DT support, as the CCCR is not a lone register,
but part of the HPB/APB block, pending full DT bindings for HPB/APB,
  - Re-add verification of product IDs,
  - Re-add registering the SoC bus if the chip ID register is missing,
  - Revert APE6 fallback to CCCR (it has both), as it's a member of the
R-Mobile family,
  - Use of_match_node(..., of_root) instead of
of_find_matching_node_and_match(),
  - Mark structures __maybe_unused to avoid compiler warnings,

v2:
  - Drop SoC families and family names; use fixed "Renesas" instead,
  - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
devices with other SoCs,
  - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
M1A: not accessible from the ARM core?),
  - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
for SoCs that provide a chip ID register,
  - Build renesas-soc only if SOC_BUS is enabled,
  - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
available, else fall back to hardcoded addresses for compatibility
with existing DTBs,
  - Remove verification of product IDs; just print the ID instead,
  - Don't register the SoC bus if the chip ID register is missing,
  - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
both).
---
 arch/arm/mach-shmobile/Kconfig|   1 +
 arch/arm64/Kconfig.platforms  |   1 +
 drivers/soc/renesas/Makefile  |   2 +
 drivers/soc/renesas/renesas-soc.c | 257 ++
 4 files changed, 261 insertions(+)
 create mode 100644 drivers/soc/renesas/renesas-soc.c

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 6fbd9b7d2d67a18f..5e7b0503921e221f 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -41,6 +41,7 @@ menuconfig ARCH_RENESAS
select HAVE_ARM_TWD if SMP
select NO_IOPORT_MAP
select PINCTRL
+   select SOC_BUS
select ZONE_DMA if ARM_LPAE
 
 if ARCH_RENESAS
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 101794f5ce1008b7..b751c6891c6a51ed 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -143,6 +143,7 @@ config ARCH_RENESAS
select PM
select PM_GENERIC_DOMAINS
select RENESAS_IRQC
+   select SOC_BUS
help
  This enables support for the ARMv8 based Renesas SoCs.
 
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 9e0bb329594c4fca..1652df037955e0e6 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -1,3 +1,5 @@
+obj-$(CONFIG_SOC_BUS)  += renesas-soc.o
+
 obj-$(CONFIG_ARCH_R8A7743) += rcar-sysc.o r8a7743-sysc.o
 obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
 obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
diff --git a/drivers/soc/renesas/renesas-soc.c 
b/drivers/soc/renesas/renesas-soc.c
new file mode 100644
index ..330960312296f603
--- /dev/null
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -0,0 +1,257 @@
+/*
+ * Renesas SoC Identification
+ *
+ * Copyright (C) 2014-2016 Glider bvba
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+struct renesas_family {
+   const char name[16];
+   u32 reg;/* CCCR or PRR, if not in DT */
+};
+
+static const struct renesas_family fam_rcar_gen1 __initconst __maybe_unused = {
+   .name   = "R-Car Gen1",
+   .reg= 0xff44,   /* PRR (Product Register) */
+};
+
+static const struct renesas_family fam_rcar_gen2 __initconst __maybe_unused = {
+   .name   = "R-Car Gen2",
+   .reg= 0xff44,   /* PRR (Product Register) */
+};
+
+static const struct renesas_fa

[PATCH v3 05/11] ARM: dts: r8a7790: Add device node for PRR

[Geert Uytterhoeven]

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Add to posted series,

v2:
  - New.
---
 arch/arm/boot/dts/r8a7790.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index a946474be9cf1e6b..f554ef3c8096726a 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1471,6 +1471,11 @@
};
};
 
+   prr: chipid@ff44 {
+   compatible = "renesas,prr";
+   reg = <0 0xff44 0 4>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7790-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
1.9.1

[PATCH v3 00/11] soc: renesas: Identify SoC and register with the SoC bus

[Geert Uytterhoeven]

Hi Simon, Magnus,

Some Renesas SoCs may exist in different revisions, providing slightly
different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
(errate and quirks).  This needs to be catered for by drivers and/or
platform code.  The recently proposed soc_device_match() API is a good
fit to handle this.

This patch series implements the core infrastructure to provide SoC and
revision information through the SoC bus for Renesas ARM SoCs.

Changes compared to v2 (more details in the individual patches):
  - Add Acked-by,
  - Drop soc_device_match() core infrastructure, as this now exists in
its own immutable branch,
  - Re-add SoC families and family names,
  - Re-add RZ/A1H and R-Car M1A support, without revision info,
  - Drop "renesas,cccr" bindings and patches added CCCR devices nodeas,
as the CCCR is not a lone register, but part of the HPB/APB register
block. DT support for obtaining the CCCR register address from DT is
thus postponed, pending DT bindings for HPB/APB,
  - Include patches to add PRR device nodes for all relevant SoCs.

Changes compared to v1:
  - Add Acked-by,
  - New patches:
  - "[4/7] base: soc: Provide a dummy implementation of
   soc_device_match()",
  - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
  - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
(more similar patches available, I'm not yet spamming you all
 with them),
  - Drop SoC families and family names; use fixed "Renesas" instead,
  - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
devices with other SoCs,
  - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
M1A: not accessible from the ARM core?),
  - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
for SoCs that provide a chip ID register,
  - Build renesas-soc only if SOC_BUS is enabled,
  - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
available, else fall back to hardcoded addresses for compatibility
with existing DTBs,
  - Remove verification of product IDs; just print the ID instead,
  - Don't register the SoC bus if the chip ID register is missing,
  - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
both).

Dependencies:
  - Core soc_device_match() infrastructure, available from signed tag
soc-device-match-tag1 in
    git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git,
  - Tag renesas-devel-20161114-v4.9-rc5 in Simon's renesas repository.

Tested on (machine, family, soc_id, optional revision):
Genmai, RZ/A, r7s72100
APE6EVM, R-Mobile, r8a73a4, ES1.0
armadillo 800 eva, R-Mobile, r8a7740, ES2.0
bockw, R-Car Gen1, r8a7778
marzen, R-Car Gen1, r8a7779, ES1.0
Lager, R-Car Gen2, r8a7790, ES1.0
Koelsch, R-Car Gen2, r8a7791, ES1.0
Porter, R-Car Gen2, r8a7791, ES3.0
Blanche, R-Car Gen2, r8a7792, ES1.1
Gose, R-Car Gen2, r8a7793, ES1.0
Alt, R-Car Gen2, r8a7794, ES1.0
Renesas Salvator-X board based on r8a7795, R-Car Gen3, r8a7795, ES1.0
Renesas Salvator-X board based on r8a7795, R-Car Gen3, r8a7795, ES1.1
Renesas Salvator-X board based on r8a7796, R-Car Gen3, r8a7796, ES1.0
KZM-A9-GT, SH-Mobile, sh73a0, ES2.0

For your convenience, this series is also available in the
topic/renesas-soc-id-v3 branch of my renesas-drivers git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git

As this is a dependency for driver updates for R-Car H3 ES2.0 (HDMI,
Ethernet, clock, pinctrl, ...), it would be good if this would be in
v4.10.

Thanks for merging soc-device-match-tag1, and applying this series on
top!

Geert Uytterhoeven (11):
  ARM: shmobile: Document DT bindings for Product Register
  soc: renesas: Identify SoC and register with the SoC bus
  ARM: dts: r8a73a4: Add device node for PRR
  ARM: dts: r8a7779: Add device node for PRR
  ARM: dts: r8a7790: Add device node for PRR
  ARM: dts: r8a7791: Add device node for PRR
  ARM: dts: r8a7792: Add device node for PRR
  ARM: dts: r8a7793: Add device node for PRR
  ARM: dts: r8a7794: Add device node for PRR
  arm64: dts: r8a7795: Add device node for PRR
  arm64: dts: r8a7796: Add device node for PRR

 Documentation/devicetree/bindings/arm/shmobile.txt |  18 ++
 arch/arm/boot/dts/r8a73a4.dtsi |   5 +
 arch/arm/boot/dts/r8a7779.dtsi |   5 +
 arch/arm/boot/dts/r8a7790.dtsi |   5 +
 arch/arm/boot/dts/r8a7791.dtsi |   5 +
 arch/arm/boot/dts/r8a7792.dtsi |   5 +
 arch/arm/boot/dts/r8a7793.dtsi |   5 +
 arch/arm/boot/dts/r8a7794.dtsi |   5 +
 arch/arm/mach-shmobile/Kconfig |   1 +
 arch/arm64/Kconfig.platforms   |   1 +
 arch/a

[PATCH v3 03/11] ARM: dts: r8a73a4: Add device node for PRR

[Geert Uytterhoeven]

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Drop CCCR, as it is not a lone register, but part of the HPB/APB
block,

v2:
  - New.
---
 arch/arm/boot/dts/r8a73a4.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index ca8672778fe067e1..53183ffe04c11c11 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -751,6 +751,11 @@
};
};
 
+   prr: chipid@ff44 {
+   compatible = "renesas,prr";
+   reg = <0 0xff44 0 4>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,sysc-r8a73a4", "renesas,sysc-rmobile";
reg = <0 0xe618 0 0x8000>, <0 0xe6188000 0 0x8000>;
-- 
1.9.1

[PATCH v3 09/11] ARM: dts: r8a7794: Add device node for PRR

[Geert Uytterhoeven]

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Add to posted series,

v2:
  - New.
---
 arch/arm/boot/dts/r8a7794.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 364b4aa8d1c1aa28..63dc7f29d216c32e 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1377,6 +1377,11 @@
};
};
 
+   prr: chipid@ff44 {
+   compatible = "renesas,prr";
+   reg = <0 0xff44 0 4>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7794-sysc";
reg = <0 0xe618 0 0x0200>;
-- 
1.9.1

[PATCH v3 11/11] arm64: dts: r8a7796: Add device node for PRR

[Geert Uytterhoeven]

Add a device node for the Product Register, which provides SoC product
and revision information.

Signed-off-by: Geert Uytterhoeven 
---
v3:
  - Add to posted series,

v2:
  - New.
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 9599f5691099054b..41a050d2f1925552 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -243,6 +243,11 @@
#power-domain-cells = <0>;
};
 
+   prr: chipid@fff00044 {
+   compatible = "renesas,prr";
+   reg = <0 0xfff00044 0 4>;
+   };
+
sysc: system-controller@e618 {
compatible = "renesas,r8a7796-sysc";
reg = <0 0xe618 0 0x0400>;
-- 
1.9.1

Re: [PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20

[Hans Verkuil]

On 11/14/2016 05:20 PM, Ramesh Shanmugasundaram wrote:
> Hi Hans,
> 
> Thanks for the review comments.
> 
>> Subject: Re: [PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20
>>
>> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
>>> This patch adds support for the three new SDR formats. These formats
>>> were prefixed with "sliced" indicating I data constitutes the top half
>>> and Q data constitutes the bottom half of the received buffer.
>>
>> The standard terminology for video formats is "planar". I am leaning
>> towards using that here as well.
>>
>> Any opinions on this?
> 
> Shall I rename the formats as "PC16", "PC18" & "PC20"?

Sounds reasonable to me!

Hans

> For formats that do IQ IQ IQ... I shall use the regular formats "CUXX" when I 
> introduce them.
> 
> Thanks,
> Ramesh
> 
>>
>>  Hans
>>
>>>
>>> V4L2_SDR_FMT_SCU16BE - 14-bit complex (I & Q) unsigned big-endian
>>> sample inside 16-bit. V4L2 FourCC: SC16
>>>
>>> V4L2_SDR_FMT_SCU18BE - 16-bit complex (I & Q) unsigned big-endian
>>> sample inside 18-bit. V4L2 FourCC: SC18
>>>
>>> V4L2_SDR_FMT_SCU20BE - 18-bit complex (I & Q) unsigned big-endian
>>> sample inside 20-bit. V4L2 FourCC: SC20
>>>
>>> Signed-off-by: Ramesh Shanmugasundaram
>>> 
>>> ---
>>>  drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
>>>  include/uapi/linux/videodev2.h   | 3 +++
>>>  2 files changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> index 181381d..d36b386 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> @@ -1207,6 +1207,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
>> *fmt)
>>> case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
>>> case V4L2_SDR_FMT_CS14LE:   descr = "Complex S14LE"; break;
>>> case V4L2_SDR_FMT_RU12LE:   descr = "Real U12LE"; break;
>>> +   case V4L2_SDR_FMT_SCU16BE:  descr = "Sliced Complex U16BE"; break;
>>> +   case V4L2_SDR_FMT_SCU18BE:  descr = "Sliced Complex U18BE"; break;
>>> +   case V4L2_SDR_FMT_SCU20BE:  descr = "Sliced Complex U20BE"; break;
>>> case V4L2_TCH_FMT_DELTA_TD16:   descr = "16-bit signed deltas"; break;
>>> case V4L2_TCH_FMT_DELTA_TD08:   descr = "8-bit signed deltas"; break;
>>> case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data";
>> break;
>>> diff --git a/include/uapi/linux/videodev2.h
>>> b/include/uapi/linux/videodev2.h index 4364ce6..34a9c30 100644
>>> --- a/include/uapi/linux/videodev2.h
>>> +++ b/include/uapi/linux/videodev2.h
>>> @@ -666,6 +666,9 @@ struct v4l2_pix_format {
>>>  #define V4L2_SDR_FMT_CS8  v4l2_fourcc('C', 'S', '0', '8') /*
>> complex s8 */
>>>  #define V4L2_SDR_FMT_CS14LE   v4l2_fourcc('C', 'S', '1', '4') /*
>> complex s14le */
>>>  #define V4L2_SDR_FMT_RU12LE   v4l2_fourcc('R', 'U', '1', '2') /*
>> real u12le */
>>> +#define V4L2_SDR_FMT_SCU16BE v4l2_fourcc('S', 'C', '1', '6') /*
>> sliced complex u16be */
>>> +#define V4L2_SDR_FMT_SCU18BE v4l2_fourcc('S', 'C', '1', '8') /*
>> sliced complex u18be */
>>> +#define V4L2_SDR_FMT_SCU20BE v4l2_fourcc('S', 'C', '2', '0') /*
>> sliced complex u20be */
>>>
>>>  /* Touch formats - used for Touch devices */
>>>  #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 16-
>> bit signed deltas */
>>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 0/2] Salvator-X: Add GPIO keys support

[Laurent Pinchart]

Hi Geert,

On Monday 14 Nov 2016 14:47:00 Geert Uytterhoeven wrote:
> On Mon, Nov 14, 2016 at 2:41 PM, Laurent Pinchart wrote:
> > On Monday 14 Nov 2016 14:35:26 Geert Uytterhoeven wrote:
> >> The main reason I haven't sent out a similar series yet is because the
> >> GPIOs used for the 3 push buttons are shared with the 3 user LEDs. For
> >> each of them, you have to choose at DT time if you want to use them as
> >> buttons or as LEDs.
> >> 
> >> On ULCB, the same issue is present. For those, we settled on 1 key and 2
> >> LEDs...
> >> 
> >> Looking forward to more comments...
> > 
> > In theory the GPIOs could be shared by the gpio-keys and LED drivers in
> > open- drain mode. I'm not sure the GPIO subsystem supports that though.
> 
> Been there, done that, cfr. "[RFD] Sharing GPIOs for input (buttons) and
> output (LEDs)". The result wasn't pretty...

Wasn't it ? Linus basically told you to use open-drain GPIOs and fix the GPIO 
driver in case it can't read the value of GPIOs configured as output in open-
drain mode. If didn't shoot the idea down.

-- 
Regards,

Laurent Pinchart

[PATCH 3/4] drm: rcar-du: Fix H/V sync signal polarity configuration

[Laurent Pinchart]

From: Koji Matsuoka 

The VSL and HSL bits in the DSMR register set the corresponding
horizontal and vertical sync signal polarity to active high. The code
got it the wrong way around, fix it.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index aca26eed93b1..a2ec6d8796a0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -149,8 +149,8 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? OTAR2 : OTAR, 0);
 
/* Signal polarities */
-   value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? 0 : DSMR_VSL)
- | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? 0 : DSMR_HSL)
+   value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0)
+ | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)
  | DSMR_DIPM_DISP | DSMR_CSPM;
rcar_du_crtc_write(rcrtc, DSMR, value);
 
-- 
Regards,

Laurent Pinchart

[PATCH 0/4] Renesas R-Car DU fixes

[Laurent Pinchart]

Hello,

This series contains four fixes for the R-Car DU driver, all backported or
inspired by the R-Car Gen3 BSP.

Please see individual patches for details.

Koji Matsuoka (3):
  drm: rcar-du: Fix display timing controller parameter
  drm: rcar-du: Fix H/V sync signal polarity configuration
  drm: rcar-du: Fix LVDS start sequence on Gen3

Laurent Pinchart (1):
  drm: rcar-du: Fix dot clock routing configuration

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  6 +++---
 drivers/gpu/drm/rcar-du/rcar_du_group.c   | 22 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 15 ---
 3 files changed, 24 insertions(+), 19 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH 4/4] drm: rcar-du: Fix LVDS start sequence on Gen3

[Laurent Pinchart]

From: Koji Matsuoka 

According to the latest revision of the datasheet, the LVDS I/O pins
must be enabled before starting the PLL. Fix it.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index b74105a80a6e..e3a4985f6f3f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -104,7 +104,14 @@ static void rcar_du_lvdsenc_start_gen3(struct 
rcar_du_lvdsenc *lvds,
 
rcar_lvds_write(lvds, LVDPLLCR, pllcr);
 
-   /* Turn the PLL on, set it to LVDS normal mode, wait for the startup
+   /* Turn all the channels on. */
+   rcar_lvds_write(lvds, LVDCR1,
+   LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
+   LVDCR1_CHSTBY_GEN3(1) | LVDCR1_CHSTBY_GEN3(0) |
+   LVDCR1_CLKSTBY_GEN3);
+
+   /*
+* Turn the PLL on, set it to LVDS normal mode, wait for the startup
 * delay and turn the output on.
 */
lvdcr0 = LVDCR0_PLLON;
@@ -117,12 +124,6 @@ static void rcar_du_lvdsenc_start_gen3(struct 
rcar_du_lvdsenc *lvds,
 
lvdcr0 |= LVDCR0_LVRES;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   /* Turn all the channels on. */
-   rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
-   LVDCR1_CHSTBY_GEN3(1) | LVDCR1_CHSTBY_GEN3(0) |
-   LVDCR1_CLKSTBY_GEN3);
 }
 
 static int rcar_du_lvdsenc_start(struct rcar_du_lvdsenc *lvds,
-- 
Regards,

Laurent Pinchart

[PATCH 2/4] drm: rcar-du: Fix display timing controller parameter

[Laurent Pinchart]

From: Koji Matsuoka 

There is a bug in the setting of the DES (Display Enable Signal)
register. This current setting occurs 1 dot left shift. The DES
register should be set minus one value about the specifying value
with H/W specification. This patch corrects it.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7316fc7fa0bd..aca26eed93b1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -172,7 +172,7 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
mode->crtc_vsync_start - 1);
rcar_du_crtc_write(rcrtc, VCR,  mode->crtc_vtotal - 1);
 
-   rcar_du_crtc_write(rcrtc, DESR,  mode->htotal - mode->hsync_start);
+   rcar_du_crtc_write(rcrtc, DESR,  mode->htotal - mode->hsync_start - 1);
rcar_du_crtc_write(rcrtc, DEWR,  mode->hdisplay);
 }
 
-- 
Regards,

Laurent Pinchart

[PATCH 1/4] drm: rcar-du: Fix dot clock routing configuration

[Laurent Pinchart]

Dot clock routing is setup through different registers depending on the
DU generation. The code has been designed for Gen2 and hasn't been
updated since. This works thanks to good reset default value, but isn't
very safe. Fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_group.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 33b2fc53da3e..64738fca96d0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -105,16 +105,20 @@ static void rcar_du_group_setup(struct rcar_du_group 
*rgrp)
if (rcar_du_has(rgrp->dev, RCAR_DU_FEATURE_EXT_CTRL_REGS)) {
rcar_du_group_setup_defr8(rgrp);
 
-   /* Configure input dot clock routing. We currently hardcode the
-* configuration to routing DOTCLKINn to DUn.
+   /*
+* Configure input dot clock routing. We currently hardcode the
+* configuration to routing DOTCLKINn to DUn. Register fields
+* depend on the DU generation, but the resulting value is 0 in
+* all cases.
+*
+* On Gen2 a single register in the first group controls dot
+* clock selection for all channels, while on Gen3 dot clocks
+* are setup through per-group registers, only available when
+* the group has two channels.
 */
-   rcar_du_group_write(rgrp, DIDSR, DIDSR_CODE |
-   DIDSR_LCDS_DCLKIN(2) |
-   DIDSR_LCDS_DCLKIN(1) |
-   DIDSR_LCDS_DCLKIN(0) |
-   DIDSR_PDCS_CLK(2, 0) |
-   DIDSR_PDCS_CLK(1, 0) |
-   DIDSR_PDCS_CLK(0, 0));
+   if ((rcdu->info->gen < 3 && rgrp->index == 0) ||
+   (rcdu->info->gen == 3 &&  rgrp->num_crtcs > 1))
+   rcar_du_group_write(rgrp, DIDSR, DIDSR_CODE);
}
 
if (rcdu->info->gen >= 3)
-- 
Regards,

Laurent Pinchart

RE: [PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20

[Ramesh Shanmugasundaram]

Hi Hans,

Thanks for the review comments.

> Subject: Re: [PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20
> 
> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds support for the three new SDR formats. These formats
> > were prefixed with "sliced" indicating I data constitutes the top half
> > and Q data constitutes the bottom half of the received buffer.
> 
> The standard terminology for video formats is "planar". I am leaning
> towards using that here as well.
> 
> Any opinions on this?

Shall I rename the formats as "PC16", "PC18" & "PC20"?
For formats that do IQ IQ IQ... I shall use the regular formats "CUXX" when I 
introduce them.

Thanks,
Ramesh

> 
>   Hans
> 
> >
> > V4L2_SDR_FMT_SCU16BE - 14-bit complex (I & Q) unsigned big-endian
> > sample inside 16-bit. V4L2 FourCC: SC16
> >
> > V4L2_SDR_FMT_SCU18BE - 16-bit complex (I & Q) unsigned big-endian
> > sample inside 18-bit. V4L2 FourCC: SC18
> >
> > V4L2_SDR_FMT_SCU20BE - 18-bit complex (I & Q) unsigned big-endian
> > sample inside 20-bit. V4L2 FourCC: SC20
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > 
> > ---
> >  drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
> >  include/uapi/linux/videodev2.h   | 3 +++
> >  2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 181381d..d36b386 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1207,6 +1207,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> *fmt)
> > case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
> > case V4L2_SDR_FMT_CS14LE:   descr = "Complex S14LE"; break;
> > case V4L2_SDR_FMT_RU12LE:   descr = "Real U12LE"; break;
> > +   case V4L2_SDR_FMT_SCU16BE:  descr = "Sliced Complex U16BE"; break;
> > +   case V4L2_SDR_FMT_SCU18BE:  descr = "Sliced Complex U18BE"; break;
> > +   case V4L2_SDR_FMT_SCU20BE:  descr = "Sliced Complex U20BE"; break;
> > case V4L2_TCH_FMT_DELTA_TD16:   descr = "16-bit signed deltas"; break;
> > case V4L2_TCH_FMT_DELTA_TD08:   descr = "8-bit signed deltas"; break;
> > case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data";
> break;
> > diff --git a/include/uapi/linux/videodev2.h
> > b/include/uapi/linux/videodev2.h index 4364ce6..34a9c30 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -666,6 +666,9 @@ struct v4l2_pix_format {
> >  #define V4L2_SDR_FMT_CS8  v4l2_fourcc('C', 'S', '0', '8') /*
> complex s8 */
> >  #define V4L2_SDR_FMT_CS14LE   v4l2_fourcc('C', 'S', '1', '4') /*
> complex s14le */
> >  #define V4L2_SDR_FMT_RU12LE   v4l2_fourcc('R', 'U', '1', '2') /*
> real u12le */
> > +#define V4L2_SDR_FMT_SCU16BE v4l2_fourcc('S', 'C', '1', '6') /*
> sliced complex u16be */
> > +#define V4L2_SDR_FMT_SCU18BE v4l2_fourcc('S', 'C', '1', '8') /*
> sliced complex u18be */
> > +#define V4L2_SDR_FMT_SCU20BE v4l2_fourcc('S', 'C', '2', '0') /*
> sliced complex u20be */
> >
> >  /* Touch formats - used for Touch devices */
> >  #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 16-
> bit signed deltas */
> >

RE: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support

[Ramesh Shanmugasundaram]

Hi Hans,

Thanks for the review comments.

> Subject: Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
> 
> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3
> SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and
> > the tuner device, which is registered as a sub-device, determines the
> > receive sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF
> > acts as a slave device and the tuner device acts as a master
> > transmitting the samples. The driver allows asynchronous binding of a
> > tuner device that is registered as a v4l2 sub-device. The driver can
> > learn about the tuner it is interfaced with based on port endpoint
> > properties of the device in device tree. The V4L2 SDR device inherits
> > the controls exposed by the tuner device.
> >
> > The device can also be configured to use either one or both of the
> > data pins at runtime based on the master (tuner) configuration.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > 
> > ---
> >  .../devicetree/bindings/media/renesas,drif.txt |  136 ++
> >  drivers/media/platform/Kconfig |   25 +
> >  drivers/media/platform/Makefile|1 +
> >  drivers/media/platform/rcar_drif.c | 1574
> 
> >  4 files changed, 1736 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/media/renesas,drif.txt
> >  create mode 100644 drivers/media/platform/rcar_drif.c
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > new file mode 100644
> > index 000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++-++-+
> > +| |-SCK--->|CLK  |
> > +|   Master|-SS>|SYNC  DRIFn (slave)  |
> > +| |-SD0--->|D0   |
> > +| |-SD1--->|D1   |
> > ++-++-+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 &
> drifn1).
> > +The sub-channels are like two individual channels in itself that
> > +share the common CLK & SYNC. Each sub-channel has it's own dedicated
> > +resources like irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's
> > +sub-channel as a separate node. The parent channel ties the
> > +sub-channels together with their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +-
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +-
> > +- port: child port node of a channel that defines the local and remote
> > +endpoints. The remote endpoint is assumed to be a tuner
> subdevice
> > +   endpoint.
> > +- renesas,syncmd   : sync mode
> > +0 (Frame start sync pulse mode. 1-bit width pulse
> > +   indicates start of a frame

Re: [PATCH v2 09/11] ARM: shmobile: document SK-RZG1E board

[Rob Herring]

On Sat, Nov 05, 2016 at 01:02:25AM +0300, Sergei Shtylyov wrote:
> Document the SK-RZG1E device tree bindings, listing it as a supported board.
> 
> This allows to use checkpatch.pl to validate .dts files referring to the
> SK-RZG1E board.
> 
> Signed-off-by: Sergei Shtylyov 
> Reviewed-by: Geert Uytterhoeven 
> 
> ---
> Changes in version 2:
> - fixed the subject;
> - added Geert's tag.
> 
>  Documentation/devicetree/bindings/arm/shmobile.txt |2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH v2 03/11] ARM: shmobile: r8a7745: basic SoC support

[Rob Herring]

On Sat, Nov 05, 2016 at 12:49:55AM +0300, Sergei Shtylyov wrote:
> Add minimal support for the RZ/G1E (R8A7745) SoC.
> 
> Signed-off-by: Sergei Shtylyov 
> Reviewed-by: Geert Uytterhoeven 
> 
> ---
> Changes in version 2:
> - added Geert's tag;
> - refreshed the patch.
> 
>  Documentation/devicetree/bindings/arm/shmobile.txt |2 ++
>  arch/arm/mach-shmobile/Kconfig |4 
>  arch/arm/mach-shmobile/setup-rcar-gen2.c   |1 +
>  3 files changed, 7 insertions(+)

Acked-by: Rob Herring 

RE: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20

[Ramesh Shanmugasundaram]

Hello Laurent, Antti, Hans,

> Subject: Re: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
> 
> On 11/11/2016 02:57 PM, Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Friday 11 Nov 2016 14:53:58 Hans Verkuil wrote:
> >> On 11/10/2016 09:08 AM, Laurent Pinchart wrote:
> >>> Antti, Hans, ping ? Please see below.
> >>>
> >>> On Friday 04 Nov 2016 09:23:29 Ramesh Shanmugasundaram wrote:
> > On 11/02/2016 10:58 PM, Laurent Pinchart wrote:
> >> On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
> > On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
> >> This patch adds documentation for the three new SDR formats
> >>
> >> V4L2_SDR_FMT_SCU16BE
> >> V4L2_SDR_FMT_SCU18BE
> >> V4L2_SDR_FMT_SCU20BE
> >>>
> >>> [snip]
> >>>
> >> +
> >> +   -  start + 0:
> >> +
> >> +   -  I'\ :sub:`0[D13:D6]`
> >> +
> >> +   -  I'\ :sub:`0[D5:D0]`
> >> +
> >> +-  .. row 2
> >> +
> >> +   -  start + buffer_size/2:
> >> +
> >> +   -  Q'\ :sub:`0[D13:D6]`
> >> +
> >> +   -  Q'\ :sub:`0[D5:D0]`
> >
> > The format looks planar, does it use one V4L2 plane (as does
> > NV12) or two V4L2 planes (as does NV12M) ? Same question for
> > the other formats.
> 
>  Thank you for bringing up this topic. This is one of the key
>  design dilemma.
> 
>  The I & Q data for these three SDR formats comes from two
>  different DMA channels and hence two separate pointers -> we
>  could say it is
>  v4l2 multi- planar. Right now, I am making it look like a
>  single plane by presenting the data in one single buffer ptr.
> 
>  For e.g. multi-planar SC16 format would look something like
>  this
> 
>  <32bits-->
>  <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0
>  + 0
>  <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0
>  + 4 ...
>  <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1
>  + 0
>  <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1
>  + 4
> 
>  My concerns are
> 
>  1) These formats are not a standard as the video "Image Formats".
>  These formats are possible when we use DRIF + MAX2175
> combination.
>  If we interface with a different tuner vendor, the above
>  format(s) MAY/MAY NOT be re-usable. We do not know at this
>  point. This is the main open item for discussion in the cover
> letter.
> >>
> >> If the formats are really device-specific then they should be
> >> documented accordingly and not made generic.
> >>
>  2) MPLANE support within V4L2 seems specific to video. Please
>  correct me if this is wrong interpretation.
> 
>  - struct v4l2_format contains v4l2_sdr_format and
>  v4l2_pix_format_mplane as members of union. Should I create a
>  new v4l2_sdr_format_mplane? If I have to use
>  v4l2_pix_format_mplane most of the video specific members would
>  be unused (it would be similar to using v4l2_pix_format itself
> instead of v4l2_sdr_format)?
> >>
> >> I have no answer to that question as I'm not familiar with SDR.
> >> Antti, you've added v4l2_sdr_format to the API, what's your
> >> opinion ? Hans, as you've acked the patch, your input would be
> appreciated as well.
> >
> > If I understood correctly this hardware provides I and Q samples
> > via different channels and driver now combines those channels as a
> > sequential IQ sample pairs.
> 
>  The driver combines the two buffer ptrs and present as one single
> buffer.
>  For a buffer of size 200
> 
>  ptr + 0   : I I I I ... I
>  ptr + 100 : Q Q Q Q ... Q
> 
> > I have never seen any other than hw which provides IQ IQ IQ IQ ...
> IQ.
> 
>  There are some modes where this h/w combo can also do IQ IQ IQ
> pattern.
>  Those modes are not added in the RFC patchset.
> 
> > This is
> > I I I I ... I
> > Q Q Q Q ... Q
> > I am not very familiar with planars, but it sounds like it is
> > correct approach. So I think should be added rather than emulate
> > packet sequential format.
> 
>  My understanding of V4L2 MPLANE constructs is limited to a quick
>  code read only. At this point MPLANE support seems specific to
>  video. SDR is defined as separate format like v4l2_pix_format.
>  Questions would be - should we define new SDR_MPLANE? or merge SDR
>  format with pix format & reuse existing MPLANE with some SDR
>  extensions (if possible)? These seem big design decisions. 

Re: [PATCH v2 02/11] soc: renesas: rcar-sysc: add R8A7745 support

[Rob Herring]

On Sat, Nov 05, 2016 at 12:46:13AM +0300, Sergei Shtylyov wrote:
> Add support for RZ/G1E (R8A7745) SoC power areas to the R-Car SYSC driver.
> 
> Based on the original (and large) patch by Dmitry Shifrin
> .
> 
> Signed-off-by: Sergei Shtylyov 
> Reviewed-by: Geert Uytterhoeven 
> 
> ---
> Changes in version 2:
> - added Geert's tag.
> 
>  Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt |1 

Acked-by: Rob Herring 

>  drivers/soc/renesas/Makefile  |1 
>  drivers/soc/renesas/r8a7745-sysc.c|   32 
> ++
>  drivers/soc/renesas/rcar-sysc.c   |3 
>  drivers/soc/renesas/rcar-sysc.h   |1 
>  5 files changed, 38 insertions(+)

RE: [PATCH 2/5] media: i2c: max2175: Add MAX2175 support

[Ramesh Shanmugasundaram]

Hi Hans,

Thank you for the review comments.

> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds driver support for MAX2175 chip. This is Maxim
> > Integrated's RF to Bits tuner front end chip designed for
> > software-defined radio solutions. This driver exposes the tuner as a
> > sub-device instance with standard and custom controls to configure the
> device.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > 
> > ---
> >  .../devicetree/bindings/media/i2c/max2175.txt  |   61 +
> >  drivers/media/i2c/Kconfig  |4 +
> >  drivers/media/i2c/Makefile |2 +
> >  drivers/media/i2c/max2175/Kconfig  |8 +
> >  drivers/media/i2c/max2175/Makefile |4 +
> >  drivers/media/i2c/max2175/max2175.c| 1558
> 
> >  drivers/media/i2c/max2175/max2175.h|  108 ++
> >  7 files changed, 1745 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/media/i2c/max2175.txt
> >  create mode 100644 drivers/media/i2c/max2175/Kconfig  create mode
> > 100644 drivers/media/i2c/max2175/Makefile
> >  create mode 100644 drivers/media/i2c/max2175/max2175.c
> >  create mode 100644 drivers/media/i2c/max2175/max2175.h
> >
> 
> 
> 
> > diff --git a/drivers/media/i2c/max2175/max2175.c
> > b/drivers/media/i2c/max2175/max2175.c
> > new file mode 100644
> > index 000..ec45b52
> > --- /dev/null
> > +++ b/drivers/media/i2c/max2175/max2175.c
> > @@ -0,0 +1,1558 @@
> 
> 
> 
> > +/* Read/Write bit(s) on top of regmap */ static int
> > +max2175_read(struct max2175 *ctx, u8 idx, u8 *val) {
> > +   u32 regval;
> > +   int ret = regmap_read(ctx->regmap, idx, ®val);
> > +
> > +   if (ret)
> > +   v4l2_err(ctx->client, "read ret(%d): idx 0x%02x\n", ret, idx);
> > +
> > +   *val = regval;
> 
> Does regmap_read initialize regval even if it returns an error? If not,
> then I would initialize regval to 0 to prevent *val being uninitialized.

Agreed.

> 
> > +   return ret;
> > +}
> > +
> > +static int max2175_write(struct max2175 *ctx, u8 idx, u8 val) {
> > +   int ret = regmap_write(ctx->regmap, idx, val);
> > +
> > +   if (ret)
> > +   v4l2_err(ctx->client, "write ret(%d): idx 0x%02x val
> 0x%02x\n",
> > +ret, idx, val);
> > +   return ret;
> > +}
> > +
> > +static u8 max2175_read_bits(struct max2175 *ctx, u8 idx, u8 msb, u8
> > +lsb) {
> > +   u8 val;
> > +
> > +   if (max2175_read(ctx, idx, &val))
> > +   return 0;
> > +
> > +   return max2175_get_bitval(val, msb, lsb); }
> > +
> > +static bool max2175_read_bit(struct max2175 *ctx, u8 idx, u8 bit) {
> > +   return !!max2175_read_bits(ctx, idx, bit, bit); }
> > +
> > +static int max2175_write_bits(struct max2175 *ctx, u8 idx,
> > +u8 msb, u8 lsb, u8 newval)
> > +{
> > +   int ret = regmap_update_bits(ctx->regmap, idx, GENMASK(msb, lsb),
> > +newval << lsb);
> > +
> > +   if (ret)
> > +   v4l2_err(ctx->client, "wbits ret(%d): idx 0x%02x\n", ret,
> idx);
> > +
> > +   return ret;
> > +}
> > +
> > +static int max2175_write_bit(struct max2175 *ctx, u8 idx, u8 bit, u8
> > +newval) {
> > +   return max2175_write_bits(ctx, idx, bit, bit, newval); }
> > +
> > +/* Checks expected pattern every msec until timeout */ static int
> > +max2175_poll_timeout(struct max2175 *ctx, u8 idx, u8 msb, u8 lsb,
> > +   u8 exp_bitval, u32 timeout_ms)
> > +{
> > +   unsigned int val;
> > +
> > +   return regmap_read_poll_timeout(ctx->regmap, idx, val,
> > +   (max2175_get_bitval(val, msb, lsb) == exp_bitval),
> > +   1000, timeout_ms * 1000);
> > +}
> > +
> > +static int max2175_poll_csm_ready(struct max2175 *ctx) {
> > +   int ret;
> > +
> > +   ret = max2175_poll_timeout(ctx, 69, 1, 1, 0, 50);
> > +   if (ret)
> > +   v4l2_err(ctx->client, "csm not ready\n");
> > +
> > +   return ret;
> > +}
> > +
> > +#define MAX2175_IS_BAND_AM(ctx)\
> > +   (max2175_read_bits(ctx, 5, 1, 0) == MAX2175_BAND_AM)
> > +
> > +#define MAX2175_IS_BAND_VHF(ctx)   \
> > +   (max2175_read_bits(ctx, 5, 1, 0) == MAX2175_BAND_VHF)
> > +
> > +#define MAX2175_IS_FM_MODE(ctx)\
> > +   (max2175_read_bits(ctx, 12, 5, 4) == 0)
> > +
> > +#define MAX2175_IS_FMHD_MODE(ctx)  \
> > +   (max2175_read_bits(ctx, 12, 5, 4) == 1)
> > +
> > +#define MAX2175_IS_DAB_MODE(ctx)   \
> > +   (max2175_read_bits(ctx, 12, 5, 4) == 2)
> > +
> > +static int max2175_band_from_freq(u32 freq) {
> > +   if (freq >= 144000 && freq <= 2610)
> > +   return MAX2175_BAND_AM;
> > +   else if (freq >= 6500 && freq <= 10800)
> > +   return MAX2175_BAND_FM;
> > +   else
> 
> No need for these 'else' keywords.

Agreed.

> 
> > +   return MAX2175_BAND_VHF;
> > +}
> > +
> > +static int max2175_update_i2s_mode(struct max2175 *ctx, u32 rx_mode,
> > +  u32 i2s_m

Re: [PATCH 00/10] Renesas R8A7795/Salvator-X HDMI output

[Ulrich Hecht]

On Mon, Nov 14, 2016 at 11:16 AM, Geert Uytterhoeven
 wrote:
> Hi Uli,
>
> On Fri, Nov 11, 2016 at 6:07 PM, Ulrich Hecht
>  wrote:
>> This implements HDMI output support for the Renesas R8A7795 (H3) SoC and
>> Salvator-X board.  It is based on mainline v4.9-rc4 and depends on Geert's
>> "[PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus"
>> series.
[...]
> Is this safe to add to next renesas-drivers release?

I think it is.

CU
Uli

Re: [PATCH 0/2] Salvator-X: Add GPIO keys support

[Geert Uytterhoeven]

Hi Laurent,

On Mon, Nov 14, 2016 at 2:41 PM, Laurent Pinchart
 wrote:
> On Monday 14 Nov 2016 14:35:26 Geert Uytterhoeven wrote:
>> The main reason I haven't sent out a similar series yet is because the GPIOs
>> used for the 3 push buttons are shared with the 3 user LEDs. For each of
>> them, you have to choose at DT time if you want to use them as buttons or
>> as LEDs.
>>
>> On ULCB, the same issue is present. For those, we settled on 1 key and 2
>> LEDs...
>>
>> Looking forward to more comments...
>
> In theory the GPIOs could be shared by the gpio-keys and LED drivers in open-
> drain mode. I'm not sure the GPIO subsystem supports that though.

Been there, done that, cfr. "[RFD] Sharing GPIOs for input (buttons) and
output (LEDs)". The result wasn't pretty...

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 0/2] Salvator-X: Add GPIO keys support

[Laurent Pinchart]

Hi Geert,

On Monday 14 Nov 2016 14:35:26 Geert Uytterhoeven wrote:
> On Mon, Nov 14, 2016 at 2:07 PM, Laurent Pinchart wrote:
> > This simple series adds GPIO keys support to both the H3- and M3-W-based
> > Salvator-X boards. Please see individual patches for details.
> 
> Thanks for your series!
> 
> The main reason I haven't sent out a similar series yet is because the GPIOs
> used for the 3 push buttons are shared with the 3 user LEDs. For each of
> them, you have to choose at DT time if you want to use them as buttons or
> as LEDs.
> 
> On ULCB, the same issue is present. For those, we settled on 1 key and 2
> LEDs...
> 
> Looking forward to more comments...

In theory the GPIOs could be shared by the gpio-keys and LED drivers in open-
drain mode. I'm not sure the GPIO subsystem supports that though.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/2] Salvator-X: Add GPIO keys support

[Geert Uytterhoeven]

Hi Laurent,

On Mon, Nov 14, 2016 at 2:07 PM, Laurent Pinchart
 wrote:
> This simple series adds GPIO keys support to both the H3- and M3-W-based
> Salvator-X boards. Please see individual patches for details.

Thanks for your series!

The main reason I haven't sent out a similar series yet is because the GPIOs
used for the 3 push buttons are shared with the 3 user LEDs. For each of them,
you have to choose at DT time if you want to use them as buttons or as LEDs.

On ULCB, the same issue is present. For those, we settled on 1 key and 2
LEDs...

Looking forward to more comments...

Gr{oetje,eeting}s,

Geert

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

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

[PATCH 1/2] arm64: dts: r8a7795: salvator-x: Add GPIO keys support

[Laurent Pinchart]

The Salvator-X board as a 4 lines DIP switch and 3 push buttons
connected to SoC GPIOs, meant to be used as general-purpose test keys.
Add a corresponding node in DT, mapping (semi-randomly) the DIP switch
to keys 1-4 and the push buttons to keys A-C.

Signed-off-by: Laurent Pinchart 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index bcaf4008d32d..ef3511cab367 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -34,6 +34,7 @@
 /dts-v1/;
 #include "r8a7795.dtsi"
 #include 
+#include 
 
 / {
model = "Renesas Salvator-X board based on r8a7795";
@@ -56,6 +57,63 @@
reg = <0x0 0x4800 0x0 0x3800>;
};
 
+   keys {
+   compatible = "gpio-keys";
+
+   pinctrl-0 = <&keys_pins>;
+   pinctrl-names = "default";
+
+   key-1 {
+   gpios = <&gpio5 17 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW4-1";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-2 {
+   gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW4-2";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-3 {
+   gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW4-3";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-4 {
+   gpios = <&gpio5 23 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW4-4";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-a {
+   gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "TSW0";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-b {
+   gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "TSW1";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-c {
+   gpios = <&gpio6 13 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "TSW2";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   };
+
x12_clk: x12_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -256,6 +314,11 @@
function = "du";
};
 
+   keys_pins: keys {
+   pins = "GP_5_17", "GP_5_20", "GP_5_22";
+   bias-pull-up;
+   };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
-- 
Regards,

Laurent Pinchart

[PATCH 2/2] arm64: dts: r8a7796: salvator-x: Add GPIO keys support

[Laurent Pinchart]

The Salvator-X board as a 4 lines DIP switch and 3 push buttons
connected to SoC GPIOs, meant to be used as general-purpose test keys.
Add a corresponding node in DT, mapping (semi-randomly) the DIP switch
to keys 1-4 and the push buttons to keys A-C.

Signed-off-by: Laurent Pinchart 
---
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index f35e96ca7d60..8e511fab880c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -11,6 +11,7 @@
 /dts-v1/;
 #include "r8a7796.dtsi"
 #include 
+#include 
 
 / {
model = "Renesas Salvator-X board based on r8a7796";
@@ -31,6 +32,63 @@
reg = <0x0 0x4800 0x0 0x7800>;
};
 
+   keys {
+   compatible = "gpio-keys";
+
+   pinctrl-0 = <&keys_pins>;
+   pinctrl-names = "default";
+
+   key-1 {
+   gpios = <&gpio5 17 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW4-1";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-2 {
+   gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW4-2";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-3 {
+   gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW4-3";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-4 {
+   gpios = <&gpio5 23 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW4-4";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-a {
+   gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "TSW0";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-b {
+   gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "TSW1";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-c {
+   gpios = <&gpio6 13 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "TSW2";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   };
+
reg_1p8v: regulator0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
@@ -116,6 +174,11 @@
function = "i2c2";
};
 
+   keys_pins: keys {
+   pins = "GP_5_17", "GP_5_20", "GP_5_22";
+   bias-pull-up;
+   };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
-- 
Regards,

Laurent Pinchart

[PATCH 0/2] Salvator-X: Add GPIO keys support

[Laurent Pinchart]

Hello,

This simple series adds GPIO keys support to both the H3- and M3-W-based
Salvator-X boards. Please see individual patches for details.

Laurent Pinchart (2):
  arm64: dts: r8a7795: salvator-x: Add GPIO keys support
  arm64: dts: r8a7796: salvator-x: Add GPIO keys support

 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 63 ++
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 63 ++
 2 files changed, 126 insertions(+)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/2] mmc: tmio: remove SDIO from TODO list

[Simon Horman]

On Sun, Nov 13, 2016 at 03:29:12PM +0100, Wolfram Sang wrote:
> We surely have SDIO support by now :)
> 
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

Re: [PATCH 1/2] mmc: tmio: fix wrong bitmask for SDIO irqs

[Simon Horman]

On Sun, Nov 13, 2016 at 03:29:11PM +0100, Wolfram Sang wrote:
> Commit 7729c7a232a953 ("mmc: tmio: Provide separate interrupt handlers")
> refactored the sdio irq handler and wrongly used the mask for SD irqs,
> not for SDIO irqs. This doesn't really matter in practice because both
> values keep the only interrupt we are interested in. But still, this is
> wrong and wants to be fixed.
> 
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

> ---
>  drivers/mmc/host/tmio_mmc_pio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
> index dbc3cb14f3321b..2b04e6e87192c7 100644
> --- a/drivers/mmc/host/tmio_mmc_pio.c
> +++ b/drivers/mmc/host/tmio_mmc_pio.c
> @@ -741,7 +741,7 @@ static void tmio_mmc_sdio_irq(int irq, void *devid)
>   return;
>  
>   status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
> - ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdcard_irq_mask;
> + ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdio_irq_mask;
>  
>   sdio_status = status & ~TMIO_SDIO_MASK_ALL;
>   if (pdata->flags & TMIO_MMC_SDIO_STATUS_QUIRK)
> -- 
> 2.9.3
> 

Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus

[Arnd Bergmann]

On Monday, November 14, 2016 11:51:15 AM CET Geert Uytterhoeven wrote:
> On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann  wrote:
> > On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> >> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann  wrote:
> >> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> >>   - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> >> available, else fall back to hardcoded addresses for compatibility
> >> >> with existing DTBs,
> 
> >> > It does seem wrong to have a device node for a specific register though.
> >> > Shouldn't the node be for the block of registers that these are inside
> >> > of?
> >>
> >> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> >> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
> >
> > It just seems odd to have it at address 0xff44 when all the other
> > devices are at page-aligned addresses. Do you mean that accessing
> > 0xff40 or 0xff48 will result in a bus-level exception for a
> > missing register and just 0xff44 is actually valid for access,
> > or is it just the only thing that is documented?
> 
> For PRR, all other registers in the page read as all zeroes on all SoCs that
> have it. So it really is a lone register.

Ok.

> >> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, 
> >> which
> >> we further don't touch at all.
> >> On R-Car Gen2, it's not documented, but does exist.
> >
> > This is where the family names would come in handy ;-) I now have
> > no idea which chip(s) you are referring to.
> 
> SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
> R-Car Gen2 are r8a779[0-4].
> 
> > If you know the name of the register block, just put it into DT with
> > that name. The driver can trivially add the right offset.
> 
> CCCR is different. The amount of registers that read as non-zero depends a lot
> on the actual SoC.
> 
> HPB/APB is gonna need real DT bindings, which needs some more investigation.
> Hence if you don't mind, I'd like to postpone that part, which only affects
> the older SoCs. And I'll drop the "renesas,cccr" binding.
> 
> For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
> most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
> waiting for this support. So I'd like to have that dependency in v4.10.

Ok, sounds good.

> >> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> >> Hence I always need to look at the root nodes.
> >
> > Not sure what that would protect you from. Could you have a renesas,cccr
> 
> Looks like you forgot to finish your sentence?

Yes, and I forgot what I was going to say there now. It's probably covered
by what we discussed above.

Arnd

Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus

[Geert Uytterhoeven]

Hi Arnd,

On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann  wrote:
> On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann  wrote:
>> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> >> v2:
>> >>   - Drop SoC families and family names; use fixed "Renesas" instead,
>> >
>> > I think I'd rather have seen the family names left in there, but it's
>> > not important, so up to you.
>>
>> They're not useful for matching, as family names may change anytime, and 
>> don't
>> always say much about the hardware capabilities.
>> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
>> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
>> SuperH.
>>
>> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>
> I think the marketing names are much more useful for humans looking
> at the sysfs files than the kernel doing matching on, but both use
> cases are important.

OK, I'll re-add the family names for humans reading sysfs.

>> >>   - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> >> available, else fall back to hardcoded addresses for compatibility
>> >> with existing DTBs,

>> > It does seem wrong to have a device node for a specific register though.
>> > Shouldn't the node be for the block of registers that these are inside
>> > of?
>>
>> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
>> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
>
> It just seems odd to have it at address 0xff44 when all the other
> devices are at page-aligned addresses. Do you mean that accessing
> 0xff40 or 0xff48 will result in a bus-level exception for a
> missing register and just 0xff44 is actually valid for access,
> or is it just the only thing that is documented?

For PRR, all other registers in the page read as all zeroes on all SoCs that
have it. So it really is a lone register.

>> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
>> we further don't touch at all.
>> On R-Car Gen2, it's not documented, but does exist.
>
> This is where the family names would come in handy ;-) I now have
> no idea which chip(s) you are referring to.

SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
R-Car Gen2 are r8a779[0-4].

> If you know the name of the register block, just put it into DT with
> that name. The driver can trivially add the right offset.

CCCR is different. The amount of registers that read as non-zero depends a lot
on the actual SoC.

HPB/APB is gonna need real DT bindings, which needs some more investigation.
Hence if you don't mind, I'd like to postpone that part, which only affects
the older SoCs. And I'll drop the "renesas,cccr" binding.

For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
waiting for this support. So I'd like to have that dependency in v4.10.

>> >>   - Don't register the SoC bus if the chip ID register is missing,
>> >
>> > Why? My objection was to hardcoding the register, not to registering
>> > the device? I think I'd rather see the device registered with an
>> > empty revision string.
>>
>> If there's no chip ID register, there's no reason to use soc_device_match(),
>> as we can always look at a compatible value. All SoCs listed in this driver
>> have a chip ID register.
>
> But you may still have user space tools looking into sysfs, e.g. to
> figure out how to install a kernel that the boot loader can find,
> or which hardware specific distro packages to install.
>
>> if you want me to register the soc_bus for  those SoCs regardless, I want to
>> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
>> registers ;-)
>
> Right. Just don't encode too much knowledge about the SoCs into the
> driver, so we are prepared for adding new ones: We should still look
> for the registers in DT on all chips.

OK, will re-add.

>> >> +static int __init renesas_soc_init(void)
>> >> +{
>> >> +   struct soc_device_attribute *soc_dev_attr;
>> >> +   const struct of_device_id *match;
>> >> +   void __iomem *chipid = NULL;
>> >> +   struct soc_device *soc_dev;
>> >> +   struct device_node *np;
>> >> +   unsigned int product;
>> >> +
>> >> +   np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> >> +   if (!np)
>> >> +   return -ENODEV;
>> >> +
>> >> +   of_node_put(np);
>> >> +
>> >> +   /* Try PRR first, then CCCR, then hardcoded fallback */
>> >> +   np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> >> +   if (!np)
>> >> +   np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> >> +   if (np) {
>> >> +   chipid = of_iomap(np, 0);
>> >> +   of_node_put(np);
>> >> +   } else if (match->data) {
>> >> +   chipid = ioremap((uintptr_t)match->d

Re: [LTSI-dev] [GIT/RFC PULL LTSI-4.9] Renesas SoCs and Drivers to next-20161028

[Simon Horman]

On Mon, Nov 14, 2016 at 10:16:52AM +0100, Greg KH wrote:
> On Mon, Nov 14, 2016 at 10:03:44AM +0100, Simon Horman wrote:
> > Hi,
> > 
> > ** This series is for informational purposes only! **
> > 
> > This series is comprised of backports to v4.9-rc3 of the following
> > components to their standard as of next-20161028:
> > 
> > * gen3  (ARM64 SoC Integration)
> > * mach-shmobile (ARM32 SoC Integration)
> > * rcar-du   (driver)
> > * rcar-snd  (driver)
> > * vsp1  (driver)
> > 
> > 
> > It is intended as a dry-run for backporting components used
> > by Renesas SoCs from v4.10 and beyond to v4.9, an activity that
> > I anticipate carrying out in the event that the next LTSI release
> > is to be based on v4.9.
> > 
> > In posting this work I am not implying anything about
> > decisions on the base of the LTSI release will be.
> 
> Very nice to see!
> 
> And yes, I'm hoping that 4.9 will be the next LTSI release, as it is
> looking good from my side to make 4.9 the next LTS kernel release.  If
> you see anything that might be a problem with 4.9 for your platforms,
> please let me know.

Thanks Greg,

That is good to know.

I will double check but I don't see any problems at this time.

Re: [PATCH 00/10] Renesas R8A7795/Salvator-X HDMI output

[Geert Uytterhoeven]

Hi Uli,

On Fri, Nov 11, 2016 at 6:07 PM, Ulrich Hecht
 wrote:
> This implements HDMI output support for the Renesas R8A7795 (H3) SoC and
> Salvator-X board.  It is based on mainline v4.9-rc4 and depends on Geert's
> "[PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus"
> series.
>
> It fixes two major issues in the previous RFC series:
>
> 1. It uses soc_device_match() to distinguish chip revisions instead of
> accessing the product register directly.
> 2. It describes the Gen3 HDMI encoder devices in a sane manner in the device
> tree, which also eliminates many contortions in the driver code.
>
> The "drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support" patch has
> been updated to version 6, and some minor non-essential parts (such as
> support for additional pixel formats) have been split off, to be addressed
> later.
>
> For testing, use the defconfig and enable CONFIG_VIDEO_RENESAS_VSP1,
> CONFIG_DRM_RCAR_VSP and CONFIG_DRM_DW_HDMI.

Thanks for your series!

Is this safe to add to next renesas-drivers release?

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCHv3 1/6] pinctrl: sh-pfc: Do not unconditionally support PIN_CONFIG_BIAS_DISABLE

[Geert Uytterhoeven]

On Sat, Nov 12, 2016 at 5:04 PM, Niklas Söderlund
 wrote:
> pin it dose not know about.

I'll fix up s/dose/does/ when applying ;-)

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCHv3 3/6] pinctrl: sh-pfc: r8a7795: Simplify get bias logic

[Geert Uytterhoeven]

On Sat, Nov 12, 2016 at 5:04 PM, Niklas Söderlund
 wrote:
> The last else statement is missing braces and there indentation level
> can be reduced.
>
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [LTSI-dev] [GIT/RFC PULL LTSI-4.9] Renesas SoCs and Drivers to next-20161028

[Greg KH]

On Mon, Nov 14, 2016 at 10:03:44AM +0100, Simon Horman wrote:
> Hi,
> 
> ** This series is for informational purposes only! **
> 
> This series is comprised of backports to v4.9-rc3 of the following
> components to their standard as of next-20161028:
> 
> * gen3  (ARM64 SoC Integration)
> * mach-shmobile (ARM32 SoC Integration)
> * rcar-du   (driver)
> * rcar-snd  (driver)
> * vsp1  (driver)
> 
> 
> It is intended as a dry-run for backporting components used
> by Renesas SoCs from v4.10 and beyond to v4.9, an activity that
> I anticipate carrying out in the event that the next LTSI release
> is to be based on v4.9.
> 
> In posting this work I am not implying anything about
> decisions on the base of the LTSI release will be.

Very nice to see!

And yes, I'm hoping that 4.9 will be the next LTSI release, as it is
looking good from my side to make 4.9 the next LTS kernel release.  If
you see anything that might be a problem with 4.9 for your platforms,
please let me know.

thanks,

greg k-h

[GIT/RFC PULL LTSI-4.9] Renesas SoCs and Drivers to next-20161028

[Simon Horman]

Hi,

** This series is for informational purposes only! **

This series is comprised of backports to v4.9-rc3 of the following
components to their standard as of next-20161028:

* gen3  (ARM64 SoC Integration)
* mach-shmobile (ARM32 SoC Integration)
* rcar-du   (driver)
* rcar-snd  (driver)
* vsp1  (driver)


It is intended as a dry-run for backporting components used
by Renesas SoCs from v4.10 and beyond to v4.9, an activity that
I anticipate carrying out in the event that the next LTSI release
is to be based on v4.9.

In posting this work I am not implying anything about
decisions on the base of the LTSI release will be.


I have tested for build regressions on a wide range of defconfigs
on a wide range of architectures.


There are 70 patches.

The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30:

  Linux 4.9-rc3 (2016-10-29 13:52:02 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git 
tags/backport/v4.9-rc3/snapshot-to-next-20161028-flattened

for you to fetch changes up to 881007870eeb7b93fef7408a0e5e6504848c0a5a:

  [media] v4l: vsp1: Add support for capture and output in HSV formats 
(2016-11-14 09:52:13 +0100)


LTSI-v4.9 Early Preparation for Renesas SoCs

Base:
* v4.9-rc3

Backports of the following components to their standard as of next-20161028:
* gen3  (ARM64 SoC Integration)
* mach-shmobile (ARM32 SoC Integration)
* rcar-du   (driver)
* rcar-snd  (driver)
* vsp1  (driver)


Chris Brandt (5):
  ARM: dts: r7s72100: add mmcif clock to device tree
  ARM: dts: r7s72100: add mmcif to device tree
  ARM: dts: r7s72100: add sdhi clock to device tree
  ARM: dts: r7s72100: add sdhi to device tree
  ARM: dts: rskrza1: add sdhi1 DT support

Chris Wilson (1):
  drm: Add reference counting to drm_atomic_state

Geert Uytterhoeven (14):
  arm64: dts: r8a7796: salvator-x: Populate EXTALR
  ARM: dts: r8a7790: Correct SCIFB reg properties to cover all registers
  ARM: dts: r8a7791: Correct SCIFB reg properties to cover all registers
  ARM: dts: r8a7793: Correct SCIFB reg properties to cover all registers
  ARM: dts: r8a7794: Correct SCIFB reg properties to cover all registers
  ARM: dts: r8a7794: Fix W=1 dtc warnings
  ARM: shmobile: Sort Kconfig selections
  ARM: shmobile: r8a7794/alt: Add board part number to DT bindings
  ARM: shmobile: r8a7793/gose: Add board part number to DT bindings
  ARM: dts: emev2: Remove skeleton.dtsi inclusion
  ARM: dts: r8a7778: Remove skeleton.dtsi inclusion
  ARM: dts: r8a7779: Remove skeleton.dtsi inclusion
  ARM: dts: r8a7740: Remove skeleton.dtsi inclusion
  ARM: dts: sh73a0: Remove skeleton.dtsi inclusion

Hans Verkuil (1):
  ARM: dts: koelsch: add HDMI input

Iyappan Subramanian (1):
  arm64: xgene: defconfig: Enable Standby GPIO

Kuninori Morimoto (18):
  ASoC: rsnd: remove duplicate define of rsnd_dvc_of_node()
  ASoC: rsnd: amend .probe/.remove call for DPCM
  ASoC: rsnd: add rsnd_mod_next() for for_each_rsnd_mod_xxx()
  ASoC: rsnd: use for_each_rsnd_mod_xxx() on rsnd_dai_call()
  ASoC: rsnd: use for_each_rsnd_mod_xxx() on rsnd_rdai_continuance_probe()
  ASoC: rsnd: add rsnd_parse_of_node() and integrate rsnd_xxx_of_node
  ASoC: rsnd: remove non DT support for DMA
  ASoC: rsnd: don't use devm_request_irq() for SSI
  ASoC: rsnd: remove rsnd_dma_detach()
  ASoC: rsnd: don't call unneeded of_node_put() on dma.c
  ASoC: rsnd: add nolock_start/stop callback
  ASoC: rsnd: depends on OF
  ASoC: rsnd: enable COMPILE_TEST
  ASoC: rsnd: remove "Gen2 only" comment
  ASoC: rsnd: rsnd_reg cleanup for SSIU
  ASoC: rsnd: fixup SCU_SYS_STATUSx access
  ASoC: rsnd: clear SSI_SYS_STATUSx every time
  ASoC: rsnd: enable SRC sync even FIN = FOUT

Laurent Pinchart (6):
  arm64: dts: r8a7795: salvator-x: Add DU LVDS output endpoint
  arm64: dts: r8a7795: Remove FCP SoC-specific compatible strings
  ARM: shmobile: Consolidate R8A7743 and R8A779[234] machine definitions
  ARM: dts: r8a7779: Fix DU reg property
  ARM: dts: r8a7779: marzen: Configure pinmuxing for the DU0 input clock
  [media] v4l: vsp1: Add support for capture and output in HSV formats

Magnus Damm (1):
  arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules

Niklas Söderlund (1):
  ARM: shmobile: defconfig: Enable CONFIG_CGROUPS

Ricardo Ribalda Delgado (2):
  [media] videodev2.h Add HSV formats
  [media] videodev2.h Add HSV encoding

Sergei Shtylyov (5):
  ARM: dts: wheat: add DU support
  ARM: dts: r8a7792: add MSIOF clocks
  ARM: dts: r8a7792: add MSIOF support
  ARM: shmobile: r8a7743: basic SoC support
  ARM: shmobile: document SK-RZ

Re: [git pull] clk: renesas: Updates for v4.10 (take one)

[Geert Uytterhoeven]

Hi Stephen,

On Fri, Nov 11, 2016 at 12:35 AM, Stephen Boyd  wrote:
> On 11/07, Geert Uytterhoeven wrote:
>> clk: renesas: Updates for v4.10 (take one)
>>
>>   - SYS-DMAC, (H)SCIF, I2C, DRIF, and graphics related clocks for R-Car
>> M3-W,
>>   - Minor fixes and cleanups.
>>
>> Thanks for pulling!
>> 
>> Geert Uytterhoeven (4):
>>   clk: renesas: cpg-mssr: Always use readl()/writel()
>>   clk: renesas: rcar-gen3-cpg: Always use readl()/writel()
>>   clk: renesas: cpg-mssr: Fix inverted debug check
>
> Hm.. I already applied this one to clk-next. If you're going to
> apply patches can you please indicate if they've been picked up
> and/or not send them To: Mike and I, please?

Sorry, I'll be more clear in the future.

I believe this is not a blocker for pulling, is it?

Thanks!

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCHv4] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 driver

[Geert Uytterhoeven]

On Sat, Nov 12, 2016 at 1:29 PM, Niklas Söderlund
 wrote:
> +Example:
> +
> +/* SoC properties */
> +
> +csi20: csi2@fea8 {
> +compatible = "renesas,r8a7795-csi2";

7795

> +reg = <0 0xfea8 0 0x1>;
> +interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
> +clocks = <&cpg CPG_MOD 714>;
> +power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;

7796

You'd better match the SoC part numbers ;-)

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