Re: [PATCH 01/10] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Simon Horman]

On Mon, Jan 15, 2018 at 08:59:38AM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Monday, 15 January 2018 08:55:29 EET Simon Horman wrote:
> > On Fri, Jan 12, 2018 at 03:29:48PM +0200, Laurent Pinchart wrote:
> > > On Friday, 12 January 2018 12:13:18 EET Geert Uytterhoeven wrote:
> > >> On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote:
> > >>> The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
> > >>> corresponding device tree bindings.
> > >>> 
> > >>> Signed-off-by: Laurent Pinchart
> > >>> 
> > >>> 
> > >>> --- /dev/null
> > >>> +++
> > >>> b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > >>> @@ -0,0 +1,54 @@
> > >>> +Renesas R-Car LVDS Encoder
> > >>> +==
> > >>> +
> > >>> +These DT bindings describe the LVDS encoder embedded in the Renesas
> > >>> R-Car Gen2 +and Gen3 SoCs.
> > >>> +
> > >>> +Required properties:
> > >>> +
> > >>> +- compatible : Shall contain one of
> > >>> +  - "renesas,lvds-r8a7743" for R8A7790 (R-Car RZ/G1M) compatible LVDS
> > >>> encoders
> > >>> +  - "renesas,lvds-r8a7790" for R8A7790 (R-Car H2) compatible LVDS
> > >>> encoders
> > >>> +  - "renesas,lvds-r8a7791" for R8A7791 (R-Car M2-W) compatible LVDS
> > >>> encoders
> > >>> +  - "renesas,lvds-r8a7793" for R8A7791 (R-Car M2-N) compatible LVDS
> > >>> encoders
> > >>> +  - "renesas,lvds-r8a7795" for R8A7795 (R-Car H3) compatible LVDS
> > >>> encoders
> > >>> +  - "renesas,lvds-r8a7796" for R8A7796 (R-Car M3-W) compatible LVDS
> > >>> encoders
> > >> 
> > >> As this is a new binding, please use "renesas,-lvds".
> > > 
> > > I've recently been thinking that we made the wrong choice, -
> > > would be better in my opinion as it aligns with -, but it's
> > > too late to change that, so I'll change the order here.
> > 
> > My recollection is that in the beginning we had a bit of a mixture but
> > leaned towards -, which made sense in my opinion. However, after
> > some discussion it was agreed that the best-practice for upstream was to
> > use -. Unless that situation has changed lets stock with using
> > - for new bindings.
> 
> Sure, that was my plan, and it seems I failed to explain it clearly. I too 
> believe that - would be better, but as we have standardized on -
>  and as there's no strong reason to reconsider that decision at the 
> moment, the next version of this patch will use -. It was a mistake 
> in v1, not an attempt to change what we had agreed on.

Thanks, it seems that we are in complete agreement.

> > >> BTW, would it make sense to use "renesas,-du" for the new DU
> > >> binding, too? Or have you reserved that for the future version that will
> > >> have a one-to-one mapping between device nodes and DU channels? ;-)
> > > 
> > > It's a good idea, let's reserve it for that evolution. If it ever happens
> > > ;-)
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver

[Simon Horman]

On Mon, Jan 15, 2018 at 09:00:59AM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Monday, 15 January 2018 08:57:48 EET Simon Horman wrote:
> > On Fri, Jan 12, 2018 at 03:48:25PM +0200, Laurent Pinchart wrote:
> > > On Friday, 12 January 2018 11:47:03 EET Geert Uytterhoeven wrote:
> > >> On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote:
> > >>> This patch series addresses a design mistake that dates back from the
> > >>> initial DU support. Support for the LVDS encoders, which are IP cores
> > >>> separate from the DU, was bundled in the DU driver. Worse, both the DU
> > >>> and LVDS were described through a single DT node.
> > >>> 
> > >>> To fix the, patches 01/10 and 02/10 define new DT bindings for the
> > >>> LVDS encoders, and deprecate their description inside the DU bindings.
> > >>> To retain backward compatibility with existing DT, patch 03/10 then
> > >>> patches the device tree at runtime to convert the legacy bindings to the
> > >>> new ones.
> > >> 
> > >> Looks like we will have to postpone the R-Car Gen2 Modern DT flag day
> > >> again by a few kernel releases?
> > > 
> > > Why so ? We don't have to drop support for all legacy DT bindings at the
> > > same time, do we ? We can switch to the new-style clock bindings on Gen2
> > > already, and drop the legacy LVDS bindings later.
> > 
> > To clarify, after this patchset.
> > * Old DTs work with old and new kernels.
> > * New DTs require new kernels.
> 
> That's correct. I've tested old DTs with new kernels successfully on Lager, 
> Salvator-X (both H3 ES1.x and M3-W) and Salvator-XS.

Thanks, no objections to this approach from my side.

Re: [PATCH 05/10] ARM: dts: porter: Fix HDMI output routing

[Simon Horman]

On Fri, Jan 12, 2018 at 02:58:53AM +0200, Laurent Pinchart wrote:
> The HDMI encoder is connected to the RGB output of the DU, which is
> port@0, not port@1. Fix the incorrect DT description.
> 
> Signed-off-by: Laurent Pinchart 

Should this have the following tag?

Fixes: c5af8a4248d3 ("ARM: dts: porter: add DU DT support")

If so, is it a fix to apply for v4.15 or a more regular patch
to apply for v4.16?

Re: [PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver

[Laurent Pinchart]

Hi Simon,

On Monday, 15 January 2018 08:57:48 EET Simon Horman wrote:
> On Fri, Jan 12, 2018 at 03:48:25PM +0200, Laurent Pinchart wrote:
> > On Friday, 12 January 2018 11:47:03 EET Geert Uytterhoeven wrote:
> >> On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote:
> >>> This patch series addresses a design mistake that dates back from the
> >>> initial DU support. Support for the LVDS encoders, which are IP cores
> >>> separate from the DU, was bundled in the DU driver. Worse, both the DU
> >>> and LVDS were described through a single DT node.
> >>> 
> >>> To fix the, patches 01/10 and 02/10 define new DT bindings for the
> >>> LVDS encoders, and deprecate their description inside the DU bindings.
> >>> To retain backward compatibility with existing DT, patch 03/10 then
> >>> patches the device tree at runtime to convert the legacy bindings to the
> >>> new ones.
> >> 
> >> Looks like we will have to postpone the R-Car Gen2 Modern DT flag day
> >> again by a few kernel releases?
> > 
> > Why so ? We don't have to drop support for all legacy DT bindings at the
> > same time, do we ? We can switch to the new-style clock bindings on Gen2
> > already, and drop the legacy LVDS bindings later.
> 
> To clarify, after this patchset.
> * Old DTs work with old and new kernels.
> * New DTs require new kernels.

That's correct. I've tested old DTs with new kernels successfully on Lager, 
Salvator-X (both H3 ES1.x and M3-W) and Salvator-XS.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 01/10] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Laurent Pinchart]

Hi Simon,

On Monday, 15 January 2018 08:55:29 EET Simon Horman wrote:
> On Fri, Jan 12, 2018 at 03:29:48PM +0200, Laurent Pinchart wrote:
> > On Friday, 12 January 2018 12:13:18 EET Geert Uytterhoeven wrote:
> >> On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote:
> >>> The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
> >>> corresponding device tree bindings.
> >>> 
> >>> Signed-off-by: Laurent Pinchart
> >>> 
> >>> 
> >>> --- /dev/null
> >>> +++
> >>> b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> >>> @@ -0,0 +1,54 @@
> >>> +Renesas R-Car LVDS Encoder
> >>> +==
> >>> +
> >>> +These DT bindings describe the LVDS encoder embedded in the Renesas
> >>> R-Car Gen2 +and Gen3 SoCs.
> >>> +
> >>> +Required properties:
> >>> +
> >>> +- compatible : Shall contain one of
> >>> +  - "renesas,lvds-r8a7743" for R8A7790 (R-Car RZ/G1M) compatible LVDS
> >>> encoders
> >>> +  - "renesas,lvds-r8a7790" for R8A7790 (R-Car H2) compatible LVDS
> >>> encoders
> >>> +  - "renesas,lvds-r8a7791" for R8A7791 (R-Car M2-W) compatible LVDS
> >>> encoders
> >>> +  - "renesas,lvds-r8a7793" for R8A7791 (R-Car M2-N) compatible LVDS
> >>> encoders
> >>> +  - "renesas,lvds-r8a7795" for R8A7795 (R-Car H3) compatible LVDS
> >>> encoders
> >>> +  - "renesas,lvds-r8a7796" for R8A7796 (R-Car M3-W) compatible LVDS
> >>> encoders
> >> 
> >> As this is a new binding, please use "renesas,-lvds".
> > 
> > I've recently been thinking that we made the wrong choice, -
> > would be better in my opinion as it aligns with -, but it's
> > too late to change that, so I'll change the order here.
> 
> My recollection is that in the beginning we had a bit of a mixture but
> leaned towards -, which made sense in my opinion. However, after
> some discussion it was agreed that the best-practice for upstream was to
> use -. Unless that situation has changed lets stock with using
> - for new bindings.

Sure, that was my plan, and it seems I failed to explain it clearly. I too 
believe that - would be better, but as we have standardized on -
 and as there's no strong reason to reconsider that decision at the 
moment, the next version of this patch will use -. It was a mistake 
in v1, not an attempt to change what we had agreed on.

> >> BTW, would it make sense to use "renesas,-du" for the new DU
> >> binding, too? Or have you reserved that for the future version that will
> >> have a one-to-one mapping between device nodes and DU channels? ;-)
> > 
> > It's a good idea, let's reserve it for that evolution. If it ever happens
> > ;-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver

[Simon Horman]

On Fri, Jan 12, 2018 at 03:48:25PM +0200, Laurent Pinchart wrote:
> Hi Geert,
> 
> On Friday, 12 January 2018 11:47:03 EET Geert Uytterhoeven wrote:
> > On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote:
> > > This patch series addresses a design mistake that dates back from the
> > > initial DU support. Support for the LVDS encoders, which are IP cores
> > > separate from the DU, was bundled in the DU driver. Worse, both the DU
> > > and LVDS were described through a single DT node.
> > > 
> > > To fix the, patches 01/10 and 02/10 define new DT bindings for the LVDS
> > > encoders, and deprecate their description inside the DU bindings. To
> > > retain backward compatibility with existing DT, patch 03/10 then patches
> > > the device tree at runtime to convert the legacy bindings to the new ones.
> > 
> > Looks like we will have to postpone the R-Car Gen2 Modern DT flag day
> > again by a few kernel releases?
> 
> Why so ? We don't have to drop support for all legacy DT bindings at the same 
> time, do we ? We can switch to the new-style clock bindings on Gen2 already, 
> and drop the legacy LVDS bindings later.

To clarify, after this patchset.
* Old DTs work with old and new kernels.
* New DTs require new kernels.

Re: [PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver

[Simon Horman]

On Fri, Jan 12, 2018 at 02:58:48AM +0200, Laurent Pinchart wrote:
> Hello,
> 
> This patch series addresses a design mistake that dates back from the initial
> DU support. Support for the LVDS encoders, which are IP cores separate from
> the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
> described through a single DT node.
> 
> To fix the, patches 01/10 and 02/10 define new DT bindings for the LVDS
> encoders, and deprecate their description inside the DU bindings. To retain
> backward compatibility with existing DT, patch 03/10 then patches the device
> tree at runtime to convert the legacy bindings to the new ones.
> 
> With the DT side addressed, patch 04/10 then converts the LVDS support code to
> a separate bridge driver. After a small fix to the Porter board device tree in
> patch 05/10, patches 06/10 to 10/10 then update all the device tree sources to
> the new LVDS encoders bindings.
> 
> I decided to go for live DT patching in patch 03/10 because implementing
> support for both the legacy and new bindings in the driver would have been
> very intrusive, and prevented further cleanups. I'm in a way both proud and 
> ashamed of that patch that I would call a neat and dirty hack. It was fun to
> write perhaps in a similar way that one would enjoy researching and developing
> proof-of-concepts for security holes: they're good and bad at the same time.
> 
> Anyway, with this philosophical considerations aside, there were a few
> shortcomings in the OF API that I worked around with local code in the driver.
> If anyone is interested in performing similar live DT patching I think we
> could move some of the code to the OF core. For instance I was surprised
> to not find a device node lookup by path function that would start at a
> given node instead of the root of the live device tree, and had to write
> rcar_du_of_find_node_by_path(). Utility functions to add or modify properties
> or to rename nodes could similarly be added.
> 
> Laurent Pinchart (10):
>   dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
>   dt-bindings: display: renesas: Deprecate LVDS support in the DU
> bindings
>   drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
>   drm: rcar-du: Convert LVDS encoder code to bridge driver
>   ARM: dts: porter: Fix HDMI output routing
>   ARM: dts: r8a7790: Convert to new LVDS DT bindings
>   ARM: dts: r8a7791: Convert to new LVDS DT bindings
>   ARM: dts: r8a7793: Convert to new LVDS DT bindings
>   arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
>   arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings

I understand that there will be a v2 to address review of the non DTS
patches. I am marking the DTS patches as "Changes Requested" as they
are dependent on the bindings patches from my PoV.

Re: [PATCH v5 0/9] Renesas Capture Engine Unit (CEU) V4L2 driver

[jacopo mondi]

Hello Hans,

On Fri, Jan 12, 2018 at 04:27:50PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Friday, 12 January 2018 16:04:00 EET Jacopo Mondi wrote:
> > Hello,
> >(hopefully) last round for CEU driver.
> >
> > Changelog is quite thin, I have updated CEU driver MODULE_LICENSE to match
> > SPDX identifier, added Rob's and Laurent's Reviewed-by tags to bindings, and
> > made variables of "struct ceu_data" type static in the driver.
> >
> > All of the patches are now Reviewed/Acked. Time to have this series
> > included?
>
> Yes please !
>
> Hans, could you pick this up ?

Hans, since this series contains changes for the SH architecture as
well, and SH maintainers have prove to be somehow unreachable, could
you please consider to have the whole series being merged thorough
your tree?

Thanks
   j

>
> > v4->v5:
> > - Added Rob's and Laurent's Reviewed-by tag to DT bindings
> > - Change CEU driver module license to "GPL v2" to match SPDX identifier as
> >   suggested by Philippe Ombredanne
> > - Make struct ceu_data static as suggested by Laurent and add his
> >   Reviewed-by to CEU driver.
> >
> > v3->v4:
> > - Drop generic fallback compatible string "renesas,ceu"
> > - Addressed Laurent's comments on [3/9]
> >   - Fix error messages on irq get/request
> >   - Do not leak ceudev if irq_get fails
> >   - Make irq_mask a const field
> >
> > v2->v3:
> > - Improved DT bindings removing standard properties (pinctrl- ones and
> >   remote-endpoint) not specific to this driver and improved description of
> >   compatible strings
> > - Remove ov772x's xlkc_rate property and set clock rate in Migo-R board file
> > - Made 'xclk' clock private to ov772x driver in Migo-R board file
> > - Change 'rstb' GPIO active output level and changed ov772x and tw9910
> > drivers accordingly as suggested by Fabio
> > - Minor changes in CEU driver to address Laurent's comments
> > - Moved Migo-R setup patch to the end of the series to silence 0-day bot
> > - Renamed tw9910 clock to 'xti' as per video decoder manual
> > - Changed all SPDX identifiers to GPL-2.0 from previous GPL-2.0+
> >
> > v1->v2:
> >  - DT
> >  -- Addressed Geert's comments and added clocks for CEU to mstp6 clock
> > source -- Specified supported generic video iterfaces properties in
> > dt-bindings and simplified example
> >
> >  - CEU driver
> >  -- Re-worked interrupt handler, interrupt management, reset(*) and capture
> > start operation
> >  -- Re-worked querycap/enum_input/enum_frameintervals to fix some
> > v4l2_compliance failures
> >  -- Removed soc_camera legacy operations g/s_mbus_format
> >  -- Update to new notifier implementation
> >  -- Fixed several comments from Hans, Laurent and Sakari
> >
> >  - Migo-R
> >  -- Register clocks and gpios for sensor drivers in Migo-R setup
> >  -- Updated sensors (tw9910 and ov772x) drivers headers and drivers to close
> > remarks from Hans and Laurent:
> >  --- Removed platform callbacks and handle clocks and gpios from sensor
> > drivers --- Remove g/s_mbus_config operations
> >
> > Jacopo Mondi (9):
> >   dt-bindings: media: Add Renesas CEU bindings
> >   include: media: Add Renesas CEU driver interface
> >   v4l: platform: Add Renesas CEU driver
> >   ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
> >   v4l: i2c: Copy ov772x soc_camera sensor driver
> >   media: i2c: ov772x: Remove soc_camera dependencies
> >   v4l: i2c: Copy tw9910 soc_camera sensor driver
> >   media: i2c: tw9910: Remove soc_camera dependencies
> >   arch: sh: migor: Use new renesas-ceu camera driver
> >
> >  .../devicetree/bindings/media/renesas,ceu.txt  |   81 +
> >  arch/arm/boot/dts/r7s72100.dtsi|   15 +-
> >  arch/sh/boards/mach-migor/setup.c  |  225 ++-
> >  arch/sh/kernel/cpu/sh4a/clock-sh7722.c |2 +-
> >  drivers/media/i2c/Kconfig  |   20 +
> >  drivers/media/i2c/Makefile |2 +
> >  drivers/media/i2c/ov772x.c | 1181 ++
> >  drivers/media/i2c/tw9910.c | 1039 
> >  drivers/media/platform/Kconfig |9 +
> >  drivers/media/platform/Makefile|1 +
> >  drivers/media/platform/renesas-ceu.c   | 1648 +
> >  include/media/drv-intf/renesas-ceu.h   |   26 +
> >  include/media/i2c/ov772x.h |6 +-
> >  include/media/i2c/tw9910.h |9 +
> >  14 files changed, 4133 insertions(+), 131 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> >  create mode 100644 drivers/media/i2c/ov772x.c
> >  create mode 100644 drivers/media/i2c/tw9910.c
> >  create mode 100644 drivers/media/platform/renesas-ceu.c
> >  create mode 100644 include/media/drv-intf/renesas-ceu.h
>
> --
> Regards,
>
> Laurent Pinchart
>

Re: [PATCH 01/10] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Simon Horman]

On Fri, Jan 12, 2018 at 03:29:48PM +0200, Laurent Pinchart wrote:
> Hi Geert,
> 
> On Friday, 12 January 2018 12:13:18 EET Geert Uytterhoeven wrote:
> > On Fri, Jan 12, 2018 at 1:58 AM, Laurent Pinchart wrote:
> > > The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
> > > corresponding device tree bindings.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > 
> > > 
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > > @@ -0,0 +1,54 @@
> > > +Renesas R-Car LVDS Encoder
> > > +==
> > > +
> > > +These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
> > > Gen2 +and Gen3 SoCs.
> > > +
> > > +Required properties:
> > > +
> > > +- compatible : Shall contain one of
> > > +  - "renesas,lvds-r8a7743" for R8A7790 (R-Car RZ/G1M) compatible LVDS
> > > encoders
> > > +  - "renesas,lvds-r8a7790" for R8A7790 (R-Car H2) compatible LVDS
> > > encoders
> > > +  - "renesas,lvds-r8a7791" for R8A7791 (R-Car M2-W) compatible LVDS
> > > encoders
> > > +  - "renesas,lvds-r8a7793" for R8A7791 (R-Car M2-N) compatible LVDS
> > > encoders
> > > +  - "renesas,lvds-r8a7795" for R8A7795 (R-Car H3) compatible LVDS
> > > encoders
> > > +  - "renesas,lvds-r8a7796" for R8A7796 (R-Car M3-W) compatible LVDS
> > > encoders
> > 
> > As this is a new binding, please use "renesas,-lvds".
> 
> I've recently been thinking that we made the wrong choice, - would 
> be 
> better in my opinion as it aligns with -, but it's too late to 
> change that, so I'll change the order here.

My recollection is that in the beginning we had a bit of a mixture but
leaned towards -, which made sense in my opinion. However, after
some discussion it was agreed that the best-practice for upstream was to
use -. Unless that situation has changed lets stock with using
- for new bindings.

> > BTW, would it make sense to use "renesas,-du" for the new DU binding,
> > too? Or have you reserved that for the future version that will have a
> > one-to-one mapping between device nodes and DU channels? ;-)
> 
> It's a good idea, let's reserve it for that evolution. If it ever happens ;-)
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH] ARM: dts: iwg22m: Enable cmt0

[Simon Horman]

On Thu, Jan 11, 2018 at 08:59:39PM +, Fabrizio Castro wrote:
> This patch enables cmt0 support from within the iwg22m SoM dtsi.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Thanks, applied.

Re: [PATCH] ARM: dts: iwg20m: Enable cmt0

[Simon Horman]

On Thu, Jan 11, 2018 at 08:59:38PM +, Fabrizio Castro wrote:
> This patch enables cmt0 support from within the iwg20m SoM dtsi.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Thanks, applied.

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Rafael J. Wysocki]

On Sun, Jan 14, 2018 at 10:48 AM, Geert Uytterhoeven
 wrote:
> Hi Rafael,
>
> On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki  wrote:
>> On Friday, January 12, 2018 3:31:09 PM CET Geert Uytterhoeven wrote:
>>> On Fri, Jan 12, 2018 at 2:00 PM, Rafael J. Wysocki  
>>> wrote:
>>> > This comes from the recent discussion/testing effort that ensued after my
>>> > pm_runtime_force_suspend|resume() changes proposal:
>>> >
>>> > https://marc.info/?t=15149777204=1=2
>>> >
>>> > Patch [1/2] basically is https://patchwork.kernel.org/patch/10152873/ 
>>> > rebased
>>> > on top of the current linux-next branch of the linux-pm.git tree (the 
>>> > relevant
>>> > part should be there in the linux-next tree proper ATM).  It applies on 
>>> > top
>>> > of https://patchwork.kernel.org/patch/10156077/ which should apply to the 
>>> > Linus'
>>> > tree cleanly.
>>> >
>>> > Patch [2/2] is a resend of https://patchwork.kernel.org/patch/10142047/ 
>>> > with
>>> > a very minor changelog modification and the R-b tag from Ulf.
>>> >
>>> > Geert, if possible, please test this on the Renesas systems that had the
>>> > problem with https://patchwork.kernel.org/patch/10142047/ previously and 
>>> > let
>>> > me know if you still see issues.
>>>
>>> I've tested this on two very similar systems: Salvator-XS with R-Car H3 
>>> ES2.0,
>>> and Salvator-X with R-Car M3-W ES1.0.
>>>
>>> On the M3-based system, everything seems to work fine.
>>
>> Good.
>>
>>> On the H3-based system, the serial console (the /dev/ttySC0 device, not 
>>> kernel
>>> serial output) is dead after resume from s2ram, with and without
>>> no_console_suspend.
>>>
>>> With no_console_suspend, I see:
>>>
>>> ttySC ttySC0: 1 input overrun(s)
>>>
>>> after typing on the serial console, so it looks like an interrupt problem.
>>>
>>> This issue seems to be caused by patch [1/2]. But I have no idea what's
>>> really happening, and why the two systems behave differently.
>
> Could be a firmware issue, too.
> While the kernel images are identical, the ARM trusted firmware configs aren't
> (same version, though).
>
> I'll do some more investigation...

OK, thanks!

It also would be good to know the topology of the device hierarchy and
how that maps to the domains on the failing system (and which UART
clocks are operated by genpd).

>> Well, that's not dramatic.
>>
>> Let's make a deal that we'll fix this on top of [1/2].
>
> ;-)
>
>> Which driver is this BTW?  sh-sci?  That one doesn't even support runtime
>> PM, confusingly enough.
>
> Yes, sh-sci. It does make pm_runtime_*() calls.

Hmm.  I overlooked that part.

This is sort of unusual, because the driver doesn't provide any
runtime PM callbacks, but still it does provided system suspend ones.
It looks like the idea is to never put it into runtime suspend if any
ports are enabled and always put it into runtime suspend otherwise.

Which one is the case in your testing?  Is the port disabled or
enabled during system-wide suspend?

> And of course there's uart_ops.pm, which is driven from serial_core...

What does this point to for that particular device?

[PATCH 1/3] extcon: int3496: don't use GPIOF_* with gpiod_get_direction

[Wolfram Sang]

The documentation was wrong, gpiod_get_direction() returns 0/1 instead
of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
("gpio: correct docs about return value of gpiod_get_direction"). Now,
fix this user (until a better, system-wide solution is in place). This
also means we can drop the deprecated use of 'linux/gpio.h'. Yay!

Signed-off-by: Wolfram Sang 
---
Only build tested!

 drivers/extcon/extcon-intel-int3496.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/extcon/extcon-intel-int3496.c 
b/drivers/extcon/extcon-intel-int3496.c
index c8691b5a9cb00c..256a25e511671d 100644
--- a/drivers/extcon/extcon-intel-int3496.c
+++ b/drivers/extcon/extcon-intel-int3496.c
@@ -20,7 +20,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -112,7 +112,7 @@ static int int3496_probe(struct platform_device *pdev)
ret = PTR_ERR(data->gpio_usb_id);
dev_err(dev, "can't request USB ID GPIO: %d\n", ret);
return ret;
-   } else if (gpiod_get_direction(data->gpio_usb_id) != GPIOF_DIR_IN) {
+   } else if (gpiod_get_direction(data->gpio_usb_id) != 1) {
dev_warn(dev, FW_BUG "USB ID GPIO not in input mode, fixing\n");
gpiod_direction_input(data->gpio_usb_id);
}
-- 
2.11.0

[PATCH 0/3] tree-wide: don't use GPIOF_* with gpiod_get_direction

[Wolfram Sang]

The documentation was wrong, gpiod_get_direction() returns 0/1 instead of the
GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 ("gpio: correct
docs about return value of gpiod_get_direction"). Now, fix the users who got it
as wrong as I did when developing bus recovery for the R-Car I2C driver.

We get rid of two users of 'linux/gpio.h' this way :)

Only build tested due to no hardware.


Wolfram Sang (3):
  extcon: int3496: don't use GPIOF_* with gpiod_get_direction
  serial: mxs-auart: don't use GPIOF_* with gpiod_get_direction
  backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

 drivers/extcon/extcon-intel-int3496.c | 4 ++--
 drivers/tty/serial/mxs-auart.c| 3 +--
 drivers/video/backlight/pwm_bl.c  | 6 +++---
 3 files changed, 6 insertions(+), 7 deletions(-)

-- 
2.11.0

[PATCH 3/3] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Wolfram Sang]

The documentation was wrong, gpiod_get_direction() returns 0/1 instead
of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
("gpio: correct docs about return value of gpiod_get_direction"). Now,
fix this user (until a better, system-wide solution is in place).

Signed-off-by: Wolfram Sang 
---
Only build tested!

 drivers/video/backlight/pwm_bl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1c2289ddd555a6..0fa7d2bd0e4811 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device 
*pdev)
 
/*
 * If the GPIO is not known to be already configured as output, that
-* is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL,
-* change the direction to output and set the GPIO as active.
+* is, if gpiod_get_direction returns either 1 or -EINVAL, change the
+* direction to output and set the GPIO as active.
 * Do not force the GPIO to active when it was already output as it
 * could cause backlight flickering or we would enable the backlight too
 * early. Leave the decision of the initial backlight state for later.
 */
if (pb->enable_gpio &&
-   gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
+   gpiod_get_direction(pb->enable_gpio) != 0)
gpiod_direction_output(pb->enable_gpio, 1);
 
pb->power_supply = devm_regulator_get(>dev, "power");
-- 
2.11.0

[PATCH 2/3] serial: mxs-auart: don't use GPIOF_* with gpiod_get_direction

[Wolfram Sang]

The documentation was wrong, gpiod_get_direction() returns 0/1 instead
of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
("gpio: correct docs about return value of gpiod_get_direction"). Now,
fix this user (until a better, system-wide solution is in place). This
also means we can drop the deprecated use of 'linux/gpio.h'. Yay!

Signed-off-by: Wolfram Sang 
---
Only build tested!

 drivers/tty/serial/mxs-auart.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 5b470406bf9d67..079dc47aa142d8 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -40,7 +40,6 @@
 
 #include 
 
-#include 
 #include 
 #include 
 #include 
@@ -1597,7 +1596,7 @@ static int mxs_auart_init_gpios(struct mxs_auart_port *s, 
struct device *dev)
 
for (i = 0; i < UART_GPIO_MAX; i++) {
gpiod = mctrl_gpio_to_gpiod(s->gpios, i);
-   if (gpiod && (gpiod_get_direction(gpiod) == GPIOF_DIR_IN))
+   if (gpiod && (gpiod_get_direction(gpiod) == 1))
s->gpio_irq[i] = gpiod_to_irq(gpiod);
else
s->gpio_irq[i] = -EINVAL;
-- 
2.11.0

[PATCH 0/2] sh_eth: simplify TSU initialization

[Sergei Shtylyov]

Hello!

Here's a set of 2 patches against DaveM's 'net-next.git' repo. With those,
I'm somewhat simplifying the TSU init code in the driver probe() method...

[1/2] sh_eth: gather all TSU init code in one place
[2/2] sh_eth: get Ether port # only when needed

MBR, Sergei

[PATCH 2/2] sh_eth: get Ether port # only when needed

[Sergei Shtylyov]

The dual-port Ether configurations always have a shared TSU to e.g. pass
the packets between those  ports.  With the  TSU init. code gathered under
the single *if*, we now can only get the port # from 'platform_device::id'
only when we actually  need it  (and not recalculate it each time)...

Signed-off-by: Sergei Shtylyov 

---
 drivers/net/ethernet/renesas/sh_eth.c |   13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -3125,7 +3125,7 @@ static int sh_eth_drv_probe(struct platf
const struct platform_device_id *id = platform_get_device_id(pdev);
struct sh_eth_private *mdp;
struct net_device *ndev;
-   int ret, devno;
+   int ret;
 
/* get base addr */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -3137,10 +3137,6 @@ static int sh_eth_drv_probe(struct platf
pm_runtime_enable(>dev);
pm_runtime_get_sync(>dev);
 
-   devno = pdev->id;
-   if (devno < 0)
-   devno = 0;
-
ret = platform_get_irq(pdev, 0);
if (ret < 0)
goto out_release;
@@ -3223,6 +3219,7 @@ static int sh_eth_drv_probe(struct platf
}
 
if (mdp->cd->tsu) {
+   int port = pdev->id < 0 ? 0 : pdev->id % 2;
struct resource *rtsu;
 
rtsu = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -3234,7 +3231,7 @@ static int sh_eth_drv_probe(struct platf
/* We can only request the  TSU region  for the first port
 * of the two  sharing this TSU for the probe to succeed...
 */
-   if (devno % 2 == 0 &&
+   if (port == 0 &&
!devm_request_mem_region(>dev, rtsu->start,
 resource_size(rtsu),
 dev_name(>dev))) {
@@ -3250,11 +3247,11 @@ static int sh_eth_drv_probe(struct platf
ret = -ENOMEM;
goto out_release;
}
-   mdp->port = devno % 2;
+   mdp->port = port;
ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER;
 
/* Need to init only the first port of the two sharing a TSU */
-   if (devno % 2 == 0) {
+   if (port == 0) {
if (mdp->cd->chip_reset)
mdp->cd->chip_reset(ndev);
 

[PATCH 1/2] sh_eth: gather all TSU init code in one place

[Sergei Shtylyov]

The  sh_eth_cpu_data::chip_reset() method  always resets using ARSTR and
this register is always located at the start of the  TSU register region.
Therefore, we can  only call  this method if we know TSU is there and thus
simplify  the probing code a  bit...

Signed-off-by: Sergei Shtylyov 

---
 drivers/net/ethernet/renesas/sh_eth.c |   12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -3222,7 +3222,6 @@ static int sh_eth_drv_probe(struct platf
eth_hw_addr_random(ndev);
}
 
-   /* ioremap the TSU registers */
if (mdp->cd->tsu) {
struct resource *rtsu;
 
@@ -3243,6 +3242,7 @@ static int sh_eth_drv_probe(struct platf
ret = -EBUSY;
goto out_release;
}
+   /* ioremap the TSU registers */
mdp->tsu_addr = devm_ioremap(>dev, rtsu->start,
 resource_size(rtsu));
if (!mdp->tsu_addr) {
@@ -3252,14 +3252,12 @@ static int sh_eth_drv_probe(struct platf
}
mdp->port = devno % 2;
ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER;
-   }
 
-   /* Need to init only the first port of the two sharing a TSU */
-   if (devno % 2 == 0) {
-   if (mdp->cd->chip_reset)
-   mdp->cd->chip_reset(ndev);
+   /* Need to init only the first port of the two sharing a TSU */
+   if (devno % 2 == 0) {
+   if (mdp->cd->chip_reset)
+   mdp->cd->chip_reset(ndev);
 
-   if (mdp->cd->tsu) {
/* TSU init (Init only)*/
sh_eth_tsu_init(mdp);
}

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Geert Uytterhoeven]

Hi Rafael,

On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki  wrote:
> On Friday, January 12, 2018 3:31:09 PM CET Geert Uytterhoeven wrote:
>> On Fri, Jan 12, 2018 at 2:00 PM, Rafael J. Wysocki  
>> wrote:
>> > This comes from the recent discussion/testing effort that ensued after my
>> > pm_runtime_force_suspend|resume() changes proposal:
>> >
>> > https://marc.info/?t=15149777204=1=2
>> >
>> > Patch [1/2] basically is https://patchwork.kernel.org/patch/10152873/ 
>> > rebased
>> > on top of the current linux-next branch of the linux-pm.git tree (the 
>> > relevant
>> > part should be there in the linux-next tree proper ATM).  It applies on top
>> > of https://patchwork.kernel.org/patch/10156077/ which should apply to the 
>> > Linus'
>> > tree cleanly.
>> >
>> > Patch [2/2] is a resend of https://patchwork.kernel.org/patch/10142047/ 
>> > with
>> > a very minor changelog modification and the R-b tag from Ulf.
>> >
>> > Geert, if possible, please test this on the Renesas systems that had the
>> > problem with https://patchwork.kernel.org/patch/10142047/ previously and 
>> > let
>> > me know if you still see issues.
>>
>> I've tested this on two very similar systems: Salvator-XS with R-Car H3 
>> ES2.0,
>> and Salvator-X with R-Car M3-W ES1.0.
>>
>> On the M3-based system, everything seems to work fine.
>
> Good.
>
>> On the H3-based system, the serial console (the /dev/ttySC0 device, not 
>> kernel
>> serial output) is dead after resume from s2ram, with and without
>> no_console_suspend.
>>
>> With no_console_suspend, I see:
>>
>> ttySC ttySC0: 1 input overrun(s)
>>
>> after typing on the serial console, so it looks like an interrupt problem.
>>
>> This issue seems to be caused by patch [1/2]. But I have no idea what's
>> really happening, and why the two systems behave differently.

Could be a firmware issue, too.
While the kernel images are identical, the ARM trusted firmware configs aren't
(same version, though).

I'll do some more investigation...

> Well, that's not dramatic.
>
> Let's make a deal that we'll fix this on top of [1/2].

;-)

> Which driver is this BTW?  sh-sci?  That one doesn't even support runtime
> PM, confusingly enough.

Yes, sh-sci. It does make pm_runtime_*() calls.
And of course there's uart_ops.pm, which is driven from serial_core...

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: Kernel 4.14 test results on porter

[Liu, Wenlong]

Hi,

Sorry, I got a mistake in my previous mail.
MMC can be used normally in kernel 4.14 on porter, so just ignore the issue:1 
in my pre-mail.
Thanks.

The test results report in the pre-mail is correct.
Now, I have two questions,
1. Benchmark.netpipe failed, error msg as below:
   ...
   Send and receive buffers are 16384 and 87380 bytes
   (A bug in Linux doubles the requested buffer sizes)
   Using a perturbation value of 2
   ...
   I didn't know much about it, so could someone tell me if it's a real bug?
2. About the BSP drivers tests[1], those tests can be used on porter?

Thanks.

[1] https://github.com/Jinzai-solution/SALVATOR_SHELL

Best regards
Liu

> -Original Message-
> From: fuego-boun...@lists.linuxfoundation.org
> [mailto:fuego-boun...@lists.linuxfoundation.org] On Behalf Of Liu,
> Wenlong
> Sent: Friday, January 12, 2018 3:50 PM
> To: linux-renesas-soc@vger.kernel.org
> Cc: fu...@lists.linuxfoundation.org
> Subject: [Fuego] Kernel 4.14 test results on porter
> 
> Hi, friends
> 
> Porter board has been used for evaluations and product development, and
> so did we.
> I have done some tests and validation on the porter with the 4.14 kernel
> recently.
> Glad to expand this test results to Renesas Kernel Team.
> I also CCed the Fuego Team, because the latest Fuego was used to do such
> a overall test and I also want to share the test results to them.
> 
> The following tests have been done:
> 1. Functional.LTP: syscalls fs fsx dio io mm ipc math nptl pty admin_tools
> timers commands sched crashme 2. Most Functional tests in Fuego
> 3. BSP drivers tests
> 
> According to test log, it seems that there no big issue, but:
> 1. In order to boot successfully, I have to use the nfs or sdx as the 
> rootfs(it
> seems that the mmc can't be used).
> 2. Benchmark.netpipe failed, error msg as below:
>...
>Send and receive buffers are 16384 and 87380 bytes
>(A bug in Linux doubles the requested buffer sizes)
>Using a perturbation value of 2
>...
> 
> For the drivers test, I have checked this repository[1].
> The BSP driver tests have been done on porter, but there are many failed
> cases than I thought.
> It seems that those configurations and tests are not very clear to me yet.
> So, who can tell me how to do those tests properly on porter?
> (@Fuego, maybe those BSP driver tests could also be added into Fuego in
> the future)
> 
> --
> The test result format of the attachment is same with the shared report
> of Khiem-san before. Thanks.
> 
> Thanks.
> 
> [1] https://github.com/Jinzai-solution/SALVATOR_SHELL
> 
> Best regards
> Liu
> 
>