mbox series

[0/5] rcar-vin: Support suspend and resume

Message ID 20201015231408.2399933-1-niklas.soderlund+renesas@ragnatech.se (mailing list archive)
Headers show
Series rcar-vin: Support suspend and resume | expand

Message

Niklas Söderlund Oct. 15, 2020, 11:14 p.m. UTC
Hi,

This series add suspend and resume support directly to R-Car VIN and 
indirectly to R-Car CSI-2 and other subdevices in the VIN capture 
pipeline. The capture pipeline is stopped when suspending and started 
when resuming, all while retaining the buffers provided from user-space.  
This makes the start and stop of the pipeline transparent from an 
application point of view.

As the pipeline is switched off subdevices that poweroff themself when 
not in use (such as R-Car CSI-2) are also switched off and are 
indirectly serviced by the suspend support in VIN.

This work is based on-top of the media-tree and is tested on both R-Car 
Gen2 and Gen3 without any regressions.

Niklas Söderlund (5):
  rcar-vin: Use scratch buffer when not in running state
  rcar-vin: Remove handling of user-space buffers when stopping
  rcar-vin: Cache the CSI-2 channel selection value
  rcar-vin: Break out hardware start and stop to new methods
  rcar-vin: Add support for suspend and resume

 drivers/media/platform/rcar-vin/rcar-core.c |  51 ++++++++
 drivers/media/platform/rcar-vin/rcar-dma.c  | 129 +++++++++++---------
 drivers/media/platform/rcar-vin/rcar-vin.h  |  15 ++-
 3 files changed, 131 insertions(+), 64 deletions(-)

Comments

Geert Uytterhoeven Oct. 16, 2020, 7:06 a.m. UTC | #1
Hi Niklas,

On Fri, Oct 16, 2020 at 4:01 AM Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
> This series add suspend and resume support directly to R-Car VIN and
> indirectly to R-Car CSI-2 and other subdevices in the VIN capture
> pipeline. The capture pipeline is stopped when suspending and started
> when resuming, all while retaining the buffers provided from user-space.
> This makes the start and stop of the pipeline transparent from an
> application point of view.
>
> As the pipeline is switched off subdevices that poweroff themself when
> not in use (such as R-Car CSI-2) are also switched off and are
> indirectly serviced by the suspend support in VIN.

Thanks for your series!

> This work is based on-top of the media-tree and is tested on both R-Car
> Gen2 and Gen3 without any regressions.

FTR: did you test on Gen3 with both s2idle and s2ram, the latter powering
off the SoC?

Gr{oetje,eeting}s,

                        Geert
Niklas Söderlund Oct. 16, 2020, 10:46 a.m. UTC | #2
Hi Geert,

On 2020-10-16 09:06:20 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Fri, Oct 16, 2020 at 4:01 AM Niklas Söderlund
> <niklas.soderlund+renesas@ragnatech.se> wrote:
> > This series add suspend and resume support directly to R-Car VIN and
> > indirectly to R-Car CSI-2 and other subdevices in the VIN capture
> > pipeline. The capture pipeline is stopped when suspending and started
> > when resuming, all while retaining the buffers provided from user-space.
> > This makes the start and stop of the pipeline transparent from an
> > application point of view.
> >
> > As the pipeline is switched off subdevices that poweroff themself when
> > not in use (such as R-Car CSI-2) are also switched off and are
> > indirectly serviced by the suspend support in VIN.
> 
> Thanks for your series!
> 
> > This work is based on-top of the media-tree and is tested on both R-Car
> > Gen2 and Gen3 without any regressions.
> 
> FTR: did you test on Gen3 with both s2idle and s2ram, the latter powering
> off the SoC?

I have only been able to test it with s2idle. My issue is that s2ram 
fails to reconnect the Ethernet (ravb) and I use nfsroot. If I instead 
use a initramfs I can resume from s2ram but I don't have the setup to 
test capture in that environment.

My procedure for s2idle that works with nfsroot is,

    # path=$(find /sys -path '/sys/devices/platform/*/ttySC0/power/wakeup')
    # echo enabled > $path
    # echo N > /sys/module/printk/parameters/console_suspend
    # echo s2idle > /sys/power/mem_slee
    # echo mem > /sys/power/state
    ** Wait a while and then wakeup using the console **
    #

My procedure for s2ram that does _not_ work with nfsroot (but do with 
initramfs). Both tests are done on a M3-N.

    # echo N > /sys/module/printk/parameters/console_suspend
    # echo on > /sys/bus/i2c/drivers/bd9571mwv/*/bd9571mwv-regulator*/backup_mode
    ** flipp SW23 off **
    # echo mem > /sys/power/state
    [  347.096336] PM: suspend entry (deep)
    [  347.104251] Filesystems sync: 0.003 seconds
    [  347.123751] Freezing user space processes ... (elapsed 0.007 seconds) done.
    [  347.138760] OOM killer disabled.
    [  347.142099] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
    [  347.167466] ravb e6800000.ethernet eth0: Link is Down
    [  347.440549] Disabling non-boot CPUs ...
    [  347.448805] CPU1: shutdown
    [  347.451731] psci: CPU1 killed (polled 0 ms)
    ** Waits 30+ seconds then switch SW23 on **
    INFO:    ARM GICv2 driver initialized
    NOTICE:  BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.2.0.6
    NOTICE:  BL2: PRR is R-Car M3N Ver.1.0
    NOTICE:  BL2: Board is Salvator-XS Rev.1.0
    NOTICE:  BL2: Boot device is HyperFlash(160MHz)
    NOTICE:  BL2: LCM state is CM
    NOTICE:  AVS setting succeeded. DVFS_SetVID=0x53
    NOTICE:  BL2: DDR3200(rev.0.40)
    NOTICE:  BL2: [WARM_BOOT]
    NOTICE:  BL2: DRAM Split is OFF
    NOTICE:  BL2: QoS is default setting(rev.0.09)
    NOTICE:  BL2: DRAM refresh interval 1.95 usec
    NOTICE:  BL2: Periodic Write DQ Training
    NOTICE:  BL2: CH0: 400000000 - 47fffffff, 2 GiB
    NOTICE:  BL2: FDT at 0xe6322508
    NOTICE:  BL2: v2.3(release):v2.3-188-g9935047b2086faa3
    NOTICE:  BL2: Built : 23:31:02, Jun 18 2020
    NOTICE:  BL2: Normal boot
    INFO:    BL2: Doing platform setup
    [  347.461237] Enabling non-boot CPUs ...
    [  347.465551] Detected PIPT I-cache on CPU1
    [  347.465611] CPU1: Booted secondary processor 0x0000000001 [0x411fd073]
    [  347.468691] CPU1 is up
    [  347.607806] usb usb2: root hub lost power or was reset
    [  347.613594] usb usb1: root hub lost power or was reset
    [  347.767713] usb usb4: root hub lost power or was reset
    [  347.773424] usb usb3: root hub lost power or was reset
    [  347.775223] libphy: ravb_mii: probed
    [  347.782808] mdio_bus e6800000.ethernet-ffffffff: MDIO device at address 0 is missing.
    [  347.794508] ravb e6800000.ethernet eth0: failed to connect PHY
    [  347.802223] PM: dpm_run_callback(): ravb_resume+0x0/0x190 returns -2
    [  347.808739] PM: Device e6800000.ethernet failed to resume: error -2
    [  347.929701] ata1: link resume succeeded after 1 retries
    [  347.989934] OOM killer enabled.
    [  347.993184] Restarting tasks ... done.
    [  348.004321] PM: suspend exit
    [  348.039400] ata1: SATA link down (SStatus 0 SControl 300)
    [  529.376515] nfs: server 10.0.1.1 not responding, still trying
    [  529.376702] nfs: server 10.0.1.1 not responding, still trying
    [  529.385628] nfs: server 10.0.1.1 not responding, still trying
    ** Board never reaches user-space **

Is there a known fix for this?

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
Geert Uytterhoeven Oct. 16, 2020, 11:26 a.m. UTC | #3
Hi Niklas,

On Fri, Oct 16, 2020 at 12:46 PM Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
> On 2020-10-16 09:06:20 +0200, Geert Uytterhoeven wrote:
> > On Fri, Oct 16, 2020 at 4:01 AM Niklas Söderlund
> > <niklas.soderlund+renesas@ragnatech.se> wrote:
> > > This series add suspend and resume support directly to R-Car VIN and
> > > indirectly to R-Car CSI-2 and other subdevices in the VIN capture
> > > pipeline. The capture pipeline is stopped when suspending and started
> > > when resuming, all while retaining the buffers provided from user-space.
> > > This makes the start and stop of the pipeline transparent from an
> > > application point of view.
> > >
> > > As the pipeline is switched off subdevices that poweroff themself when
> > > not in use (such as R-Car CSI-2) are also switched off and are
> > > indirectly serviced by the suspend support in VIN.
> >
> > Thanks for your series!
> >
> > > This work is based on-top of the media-tree and is tested on both R-Car
> > > Gen2 and Gen3 without any regressions.
> >
> > FTR: did you test on Gen3 with both s2idle and s2ram, the latter powering
> > off the SoC?
>
> I have only been able to test it with s2idle. My issue is that s2ram
> fails to reconnect the Ethernet (ravb) and I use nfsroot. If I instead
> use a initramfs I can resume from s2ram but I don't have the setup to
> test capture in that environment.

>     [  347.775223] libphy: ravb_mii: probed
>     [  347.782808] mdio_bus e6800000.ethernet-ffffffff: MDIO device at address 0 is missing.
>     [  347.794508] ravb e6800000.ethernet eth0: failed to connect PHY
>     [  347.802223] PM: dpm_run_callback(): ravb_resume+0x0/0x190 returns -2
>     [  347.808739] PM: Device e6800000.ethernet failed to resume: error -2
>     [  347.929701] ata1: link resume succeeded after 1 retries
>     [  347.989934] OOM killer enabled.
>     [  347.993184] Restarting tasks ... done.
>     [  348.004321] PM: suspend exit
>     [  348.039400] ata1: SATA link down (SStatus 0 SControl 300)
>     [  529.376515] nfs: server 10.0.1.1 not responding, still trying
>     [  529.376702] nfs: server 10.0.1.1 not responding, still trying
>     [  529.385628] nfs: server 10.0.1.1 not responding, still trying
>     ** Board never reaches user-space **
>
> Is there a known fix for this?

Please try cherry-picking commit 77972b55fb9d35d4 ("Revert "ravb: Fixed
to be able to unload modules"") from v5.9.

Gr{oetje,eeting}s,

                        Geert
Niklas Söderlund Oct. 16, 2020, 12:23 p.m. UTC | #4
Hi Geert,

On 2020-10-16 13:26:25 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Fri, Oct 16, 2020 at 12:46 PM Niklas Söderlund
> <niklas.soderlund+renesas@ragnatech.se> wrote:
> > On 2020-10-16 09:06:20 +0200, Geert Uytterhoeven wrote:
> > > On Fri, Oct 16, 2020 at 4:01 AM Niklas Söderlund
> > > <niklas.soderlund+renesas@ragnatech.se> wrote:
> > > > This series add suspend and resume support directly to R-Car VIN and
> > > > indirectly to R-Car CSI-2 and other subdevices in the VIN capture
> > > > pipeline. The capture pipeline is stopped when suspending and started
> > > > when resuming, all while retaining the buffers provided from user-space.
> > > > This makes the start and stop of the pipeline transparent from an
> > > > application point of view.
> > > >
> > > > As the pipeline is switched off subdevices that poweroff themself when
> > > > not in use (such as R-Car CSI-2) are also switched off and are
> > > > indirectly serviced by the suspend support in VIN.
> > >
> > > Thanks for your series!
> > >
> > > > This work is based on-top of the media-tree and is tested on both R-Car
> > > > Gen2 and Gen3 without any regressions.
> > >
> > > FTR: did you test on Gen3 with both s2idle and s2ram, the latter powering
> > > off the SoC?
> >
> > I have only been able to test it with s2idle. My issue is that s2ram
> > fails to reconnect the Ethernet (ravb) and I use nfsroot. If I instead
> > use a initramfs I can resume from s2ram but I don't have the setup to
> > test capture in that environment.
> 
> >     [  347.775223] libphy: ravb_mii: probed
> >     [  347.782808] mdio_bus e6800000.ethernet-ffffffff: MDIO device at address 0 is missing.
> >     [  347.794508] ravb e6800000.ethernet eth0: failed to connect PHY
> >     [  347.802223] PM: dpm_run_callback(): ravb_resume+0x0/0x190 returns -2
> >     [  347.808739] PM: Device e6800000.ethernet failed to resume: error -2
> >     [  347.929701] ata1: link resume succeeded after 1 retries
> >     [  347.989934] OOM killer enabled.
> >     [  347.993184] Restarting tasks ... done.
> >     [  348.004321] PM: suspend exit
> >     [  348.039400] ata1: SATA link down (SStatus 0 SControl 300)
> >     [  529.376515] nfs: server 10.0.1.1 not responding, still trying
> >     [  529.376702] nfs: server 10.0.1.1 not responding, still trying
> >     [  529.385628] nfs: server 10.0.1.1 not responding, still trying
> >     ** Board never reaches user-space **
> >
> > Is there a known fix for this?
> 
> Please try cherry-picking commit 77972b55fb9d35d4 ("Revert "ravb: Fixed
> to be able to unload modules"") from v5.9.

Thanks that did the trick!

Unfortunately it revealed a new problem related to capturing after a 
s2ram, the ADV7482 does not support s2ram and when it gets reset it no 
longer is possible to communicate to it over i2c. This in turn breaks 
the VIN s2ram test as of course it can not resume capture if it can't 
talk to the ADV7482.

I reproduced this issue directly on top of v5.9. I'm not streaming at 
the time of s2ram. The test is to read the video standard reported by 
the AFE subdevice provided by the ADV7482 before and after s2ram. As 
shown it does not respond after a s2ram but unbind/bind it forcing it to 
reinit itself solves the issue.

Test case:

    # subdev=$(grep -l "adv748x 4-0070 afe" /sys/class/video4linux/*/name | sed 's#.*video4linux\(.*\)/name#/dev\1#g')
    # v4l2-ctl --get-detected-standard -d $subdev
    # echo N > /sys/module/printk/parameters/console_suspend
    # echo on > /sys/bus/i2c/drivers/bd9571mwv/*/bd9571mwv-regulator*/backup_mode 
    ** flipp SW23 off **
    # echo mem > /sys/power/state
    ** Waits 30+ seconds then switch SW23 on ** 
    # subdev=$(grep -l "adv748x 4-0070 afe" /sys/class/video4linux/*/name | sed 's#.*video4linux\(.*\)/name#/dev\1#g')
    # v4l2-ctl --get-detected-standard -d $subdev
    # echo 4-0070 > /sys/bus/i2c/drivers/adv748x/unbind
    # echo 4-0070 > /sys/bus/i2c/drivers/adv748x/bind
    # subdev=$(grep -l "adv748x 4-0070 afe" /sys/class/video4linux/*/name | sed 's#.*video4linux\(.*\)/name#/dev\1#g')
    # v4l2-ctl --get-detected-standard -d $subdev

Output:

    # subdev=$(grep -l "adv748x 4-0070 afe" /sys/class/video4linux/*/name | sed 's#.*video4linux\(.*\)/name#/dev\1#g')
    # echo $subdev
    /dev/v4l-subdev20
    # v4l2-ctl --get-detected-standard -d $subdev
    Video Standard = 0x000000ff
	    PAL-B/B1/G/H/I/D/D1/K
    # echo N > /sys/module/printk/parameters/console_suspend 
    # echo on > /sys/bus/i2c/drivers/bd9571mwv/*/bd9571mwv-regulator*/backup_mode
    # echo mem > /sys/power/state
    [  477.555286] PM: suspend entry (deep)
    [  477.560233] Filesystems sync: 0.000 seconds
    [  477.572660] Freezing user space processes ... (elapsed 0.002 seconds) done.
    [  477.575590] OOM killer disabled.
    [  477.575598] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
    [  477.587659] ravb e6800000.ethernet eth0: Link is Down
    [  477.857405] Disabling non-boot CPUs ...
    [  477.863418] CPU1: shutdown
    [  477.866275] psci: CPU1 killed (polled 0 ms)
    INFO:    ARM GICv2 driver initialized
    NOTICE:  BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.2.0.6
    NOTICE:  BL2: PRR is R-Car M3N Ver.1.0
    NOTICE:  BL2: Board is Salvator-XS Rev.1.0
    NOTICE:  BL2: Boot device is HyperFlash(160MHz)
    NOTICE:  BL2: LCM state is CM
    NOTICE:  AVS setting succeeded. DVFS_SetVID=0x53
    NOTICE:  BL2: DDR3200(rev.0.40)
    NOTICE:  BL2: [WARM_BOOT]
    NOTICE:  BL2: DRAM Split is OFF
    NOTICE:  BL2: QoS is default setting(rev.0.09)
    NOTICE:  BL2: DRAM refresh interval 1.95 usec
    NOTICE:  BL2: Periodic Write DQ Training
    NOTICE:  BL2: CH0: 400000000 - 47fffffff, 2 GiB
    NOTICE:  BL2: FDT at 0xe6322508
    NOTICE:  BL2: v2.3(release):v2.3-188-g9935047b2086faa3
    NOTICE:  BL2: Built : 23:31:02, Jun 18 2020
    NOTICE:  BL2: Normal boot
    INFO:    BL2: Doing platform setup
    [  477.872578] Enabling non-boot CPUs ...
    [  477.876839] Detected PIPT I-cache on CPU1
    [  477.876897] CPU1: Booted secondary processor 0x0000000001 [0x411fd073]
    [  477.878379] CPU1 is up
    [  478.019935] usb usb2: root hub lost power or was reset
    [  478.025283] usb usb1: root hub lost power or was reset
    [  478.171928] usb usb4: root hub lost power or was reset
    [  478.178011] usb usb3: root hub lost power or was reset
    [  478.217119] Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=e6800000.ethernet-ffffffff:00, irq=197)
    [  478.341930] ata1: link resume succeeded after 1 retries
    [  478.403262] OOM killer enabled.
    [  478.406730] Restarting tasks ... done.
    [  478.417250] PM: suspend exit
    [  478.451992] ata1: SATA link down (SStatus 0 SControl 300)
    [  485.716683] ravb e6800000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
    # subdev=$(grep -l "adv748x 4-0070 afe" /sys/class/video4linux/*/name | sed 's#.*video4linux\(.*\)/name#/dev\1#g')
    # v4l2-ctl --get-detected-standard -d $subdev
    [  502.753723] adv748x 4-0070: error reading 63, 02
    [  502.866437] adv748x 4-0070: error reading 63, 02
    VIDIOC_QUERYSTD: failed: No such device or address
    # echo 4-0070 > /sys/bus/i2c/drivers/adv748x/unbind
    # echo 4-0070 > /sys/bus/i2c/drivers/adv748x/bind
    [  511.830105] adv748x 4-0070: Endpoint /soc/i2c@e66d8000/video-receiver@70/port@7/endpoint on port 7
    [  511.839766] adv748x 4-0070: Endpoint /soc/i2c@e66d8000/video-receiver@70/port@8/endpoint on port 8
    [  511.849682] adv748x 4-0070: Endpoint /soc/i2c@e66d8000/video-receiver@70/port@a/endpoint on port 10
    [  511.859509] adv748x 4-0070: Endpoint /soc/i2c@e66d8000/video-receiver@70/port@b/endpoint on port 11
    [  511.870845] adv748x 4-0070: chip found @ 0xe0 revision 2143
    # subdev=$(grep -l "adv748x 4-0070 afe" /sys/class/video4linux/*/name | sed 's#.*video4linux\(.*\)/name#/dev\1#g')
    # v4l2-ctl --get-detected-standard -d $subdev
    Video Standard = 0x000000ff
	    PAL-B/B1/G/H/I/D/D1/K
    #

I think this issue needs to be resolved before I can truly verify the 
operation of this series post s2ram. Do you think this series should be 
held until then or does it bring enough value (s2idle) while not 
introducing any regressions? s2ram is just as broken before as after :-)

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
Geert Uytterhoeven Oct. 16, 2020, 12:39 p.m. UTC | #5
Hi,

On Fri, Oct 16, 2020 at 2:23 PM Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
> On 2020-10-16 13:26:25 +0200, Geert Uytterhoeven wrote:
> > On Fri, Oct 16, 2020 at 12:46 PM Niklas Söderlund
> > <niklas.soderlund+renesas@ragnatech.se> wrote:
> > > On 2020-10-16 09:06:20 +0200, Geert Uytterhoeven wrote:
> > > > On Fri, Oct 16, 2020 at 4:01 AM Niklas Söderlund
> > > > <niklas.soderlund+renesas@ragnatech.se> wrote:
> > > > > This series add suspend and resume support directly to R-Car VIN and
> > > > > indirectly to R-Car CSI-2 and other subdevices in the VIN capture
> > > > > pipeline. The capture pipeline is stopped when suspending and started
> > > > > when resuming, all while retaining the buffers provided from user-space.
> > > > > This makes the start and stop of the pipeline transparent from an
> > > > > application point of view.
> > > > >
> > > > > As the pipeline is switched off subdevices that poweroff themself when
> > > > > not in use (such as R-Car CSI-2) are also switched off and are
> > > > > indirectly serviced by the suspend support in VIN.
> > > >
> > > > Thanks for your series!
> > > >
> > > > > This work is based on-top of the media-tree and is tested on both R-Car
> > > > > Gen2 and Gen3 without any regressions.
> > > >
> > > > FTR: did you test on Gen3 with both s2idle and s2ram, the latter powering
> > > > off the SoC?
> > >
> > > I have only been able to test it with s2idle. My issue is that s2ram
> > > fails to reconnect the Ethernet (ravb) and I use nfsroot. If I instead
> > > use a initramfs I can resume from s2ram but I don't have the setup to
> > > test capture in that environment.
> >
> > >     [  347.775223] libphy: ravb_mii: probed
> > >     [  347.782808] mdio_bus e6800000.ethernet-ffffffff: MDIO device at address 0 is missing.
> > >     [  347.794508] ravb e6800000.ethernet eth0: failed to connect PHY
> > >     [  347.802223] PM: dpm_run_callback(): ravb_resume+0x0/0x190 returns -2
> > >     [  347.808739] PM: Device e6800000.ethernet failed to resume: error -2
> > >     [  347.929701] ata1: link resume succeeded after 1 retries
> > >     [  347.989934] OOM killer enabled.
> > >     [  347.993184] Restarting tasks ... done.
> > >     [  348.004321] PM: suspend exit
> > >     [  348.039400] ata1: SATA link down (SStatus 0 SControl 300)
> > >     [  529.376515] nfs: server 10.0.1.1 not responding, still trying
> > >     [  529.376702] nfs: server 10.0.1.1 not responding, still trying
> > >     [  529.385628] nfs: server 10.0.1.1 not responding, still trying
> > >     ** Board never reaches user-space **
> > >
> > > Is there a known fix for this?
> >
> > Please try cherry-picking commit 77972b55fb9d35d4 ("Revert "ravb: Fixed
> > to be able to unload modules"") from v5.9.
>
> Thanks that did the trick!

Glad to hear that!

> Unfortunately it revealed a new problem related to capturing after a
> s2ram, the ADV7482 does not support s2ram and when it gets reset it no
> longer is possible to communicate to it over i2c. This in turn breaks
> the VIN s2ram test as of course it can not resume capture if it can't
> talk to the ADV7482.
>
> I reproduced this issue directly on top of v5.9. I'm not streaming at
> the time of s2ram. The test is to read the video standard reported by
> the AFE subdevice provided by the ADV7482 before and after s2ram. As
> shown it does not respond after a s2ram but unbind/bind it forcing it to
> reinit itself solves the issue.

I guess the pesky adv7482 needs its secondary addresses to be reprogrammed
in its resume handler?

> I think this issue needs to be resolved before I can truly verify the
> operation of this series post s2ram. Do you think this series should be
> held until then or does it bring enough value (s2idle) while not
> introducing any regressions? s2ram is just as broken before as after :-)

Well, my main worry is that it would hide a so far unknown s2ram resume
issue in the rcar-vin driver.  I've seen too many  "Add suspend/resume"
commits yielding drivers where suspend/resume still didn't work
afterwards.

Gr{oetje,eeting}s,

                        Geert